TLS/HTTPS

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

TLS/HTTPS

Mike Spencer

I'm encountering web sites that a browser won't talk to.  Variously,
there's a report of a crypto mismatch or the remote site just closes
the connection.

Browsers both claim to support TLS 1.2.

Are sites already requiring TLS 1.3? Or do some implementations use
differing crypto protocols unsupported by others? Or something else?

Is there a way, short of deciphering a packet sniffer's output (such
as Wireshark) to get a report on what, exactly, happens in the setup
negotiation for HTTPS?  wget(1) will report the HTTP headers but not what
happens in the security setup phase.

Is there a way to beat this up, understand what's going on, without
reading a slew of RFCs?

- Mike

PS:

I know, I know, "Do you have the latest browser available?"  No, I
don't.  Every new version implements something I don't want that I
have to try to disable or disables something I rely on forcing a
work-around or abject submission.  I just learned about the "ping"
attribute for anchor tags, one more thing to filter.

--
Michael Spencer                  Nova Scotia, Canada       .~.
                                                           /V\
[hidden email]                                     /( )\
http://home.tallships.ca/mspencer/                        ^^-^^
_______________________________________________
nSLUG mailing list
[hidden email]
http://nslug.ns.ca/mailman/listinfo/nslug
Reply | Threaded
Open this post in threaded view
|

Re: TLS/HTTPS

Joel Maxuel
I have encountered the reverse problem with modern browsers.  Firefox and chromium (and derivatives) don't like, or refuse to do TLS 1.0 at this point (Firefox needs a few security options flipped to resolve this, chromium has no workaround AFAIK).

FWIW, I do have a use case for this, and no, it's not for anything outside my house, and for the times I use that browser otherwise, JavaScript operates under a short whitelist.

Browsers change behaviour (Chrome has since moved or removed this detail however if you can find the right version of any of the popular ones):
https://security.stackexchange.com/questions/19096/how-to-determine-if-a-browser-is-using-an-ssl-or-tls-connection#19097  

Example, slashdot now forwards HTTP traffic to HTTPS with "TLS 1.2, AES with 256 bit encryption (High); ECDH_P384 with 256 bit exchange".

Alternatively, you can share (if comfortable in doing so) a couple websites that you suspect have changed their base security settings (and we can look at the HTTPS details).

--
Cheers,
Joel Maxuel

"One should strive to achieve, not sit in bitter regret."
 - Ronan Harris / Mark Jackson


On Thu, Apr 18, 2019 at 2:58 AM Mike Spencer <[hidden email]> wrote:

I'm encountering web sites that a browser won't talk to.  Variously,
there's a report of a crypto mismatch or the remote site just closes
the connection.

Browsers both claim to support TLS 1.2.

Are sites already requiring TLS 1.3? Or do some implementations use
differing crypto protocols unsupported by others? Or something else?

Is there a way, short of deciphering a packet sniffer's output (such
as Wireshark) to get a report on what, exactly, happens in the setup
negotiation for HTTPS?  wget(1) will report the HTTP headers but not what
happens in the security setup phase.

Is there a way to beat this up, understand what's going on, without
reading a slew of RFCs?

- Mike

PS:

I know, I know, "Do you have the latest browser available?"  No, I
don't.  Every new version implements something I don't want that I
have to try to disable or disables something I rely on forcing a
work-around or abject submission.  I just learned about the "ping"
attribute for anchor tags, one more thing to filter.

--
Michael Spencer                  Nova Scotia, Canada       .~.
                                                           /V\
[hidden email]                                     /( )\
http://home.tallships.ca/mspencer/                        ^^-^^
_______________________________________________
nSLUG mailing list
[hidden email]
http://nslug.ns.ca/mailman/listinfo/nslug

_______________________________________________
nSLUG mailing list
[hidden email]
http://nslug.ns.ca/mailman/listinfo/nslug
Reply | Threaded
Open this post in threaded view
|

Re: TLS/HTTPS

George N. White III
In reply to this post by Mike Spencer
On Thu, 18 Apr 2019 at 02:58, Mike Spencer <[hidden email]> wrote:

I'm encountering web sites that a browser won't talk to.  Variously,
there's a report of a crypto mismatch or the remote site just closes
the connection.

WIth current Google Chrome, I just got:

Attackers might be trying to steal your information from s.engadget.com (for example, passwords, messages or credit cards). Learn more

NET::ERR_CERT_DATE_INVALID

Subject: s.engadget.com

Issuer: Let's Encrypt Authority X3

Expires on: 16 Apr 2019

Current date: 18 Apr 2019

PEM encoded chain:

-----BEGIN CERTIFICATE-----

[...]

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

[...]

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

[...]

-----END CERTIFICATE-----


Firefox gave:

Warning: Potential Security Risk Ahead

Firefox detected an issue and did not continue to s.engadget.com. The website is either misconfigured or your computer clock is set to the wrong time.

It\u2019s likely the website\u2019s certificate is expired, which prevents Firefox from connecting securely. If you visit this site, attackers could try to steal information like your passwords, emails, or credit card details.
 

Browsers both claim to support TLS 1.2.

Are sites already requiring TLS 1.3? Or do some implementations use
differing crypto protocols unsupported by others? Or something else?

A couple years ago Obama ordered public facing US .gov sites to use https.   The NASA site I was using 
was configured to require ciphers that only becase avaiable after 2014, so Ubuntu 14.04 and CentOS 6 
users were unable to connect to the site with the base versions.  Updating to current browser versions
let us view web pages but command-line tools needed a new (locally compiled) gnutls library. 
 

Is there a way, short of deciphering a packet sniffer's output (such
as Wireshark) to get a report on what, exactly, happens in the setup
negotiation for HTTPS?  wget(1) will report the HTTP headers but not what
happens in the security setup phase.

There are sites like ssllabs ssltest that will generate a report for a server's
configuration.   There are openssl examples:

$ openssl s_client -connect s.engadget.com:443
 CONNECTED(00000003)
---
Certificate chain
 0 s:/C=US/L=Default City/O=Default Company Ltd/CN=null.invalid
   i:/C=US/L=Default City/O=Default Company Ltd/CN=null.invalid
---
Server certificate
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
subject=/C=US/L=Default City/O=Default Company Ltd/CN=null.invalid
issuer=/C=US/L=Default City/O=Default Company Ltd/CN=null.invalid
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2332 bytes and written 431 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: 72B391BC410EFB1A8F19ED77EF00FAC8FA19EC560C638247E5DEA9F1020ADBE6
    Session-ID-ctx:
    Master-Key: 29C96261EA0ACCF18238AFFD7CB1D4BA1BE12EEDA512F2193F8F940A25F282BF217F599FFEE777F8F1276C527D0EB7B1
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
[...]
    Start Time: 1555587749
    Timeout   : 300 (sec)
    Verify return code: 18 (self signed certificate)
---
HEAD / HTTP/1.0      <<<<<<<<<<<<<<<<<<<<<<< I typed this

HTTP/1.1 302 Found
Date: Thu, 18 Apr 2019 11:51:03 GMT
Server: Apache
Connection: close
Content-Type: text/html; charset=UTF-8

closed


Is there a way to beat this up, understand what's going on, without
reading a slew of RFCs?

RFC's cover lots of details that maay not appy to your use case, so it is
best to start with overviews and use RFC's when you need more detail.

It may help to start with UNIX Network Programming (Richard Stevens), but
my copy is from 1990 and doesn't address current "secure" protocols.

IBM Knowledge Center Cryptographic Protocols has overviews of SSL and TLS.
These have many options, and IBM refers to the FIPS requirements.
Mozilla Server Side TLS recommends https server configurations that many 
sites use, but there are also lots of badly configured sites.
 
- Mike

PS:

I know, I know, "Do you have the latest browser available?"  No, I
don't.  Every new version implements something I don't want that I
have to try to disable or disables something I rely on forcing a
work-around or abject submission.  I just learned about the "ping"
attribute for anchor tags, one more thing to filter.

Many people have virtual machines dedicated to particular browsers.
I run Ubuntu 16.04 because that is what the NASA people who develop
the software use had until recently (they are moving to 18.04).   I installed
Fedora Server (now at version 29) in a headless configuration and use
"ssh -AY ip_of_vm" in a terminal start a browser that displays on the
host.   This works well on a 2007 system with 8G RAM (2G for the VM).

--
George N. White III


_______________________________________________
nSLUG mailing list
[hidden email]
http://nslug.ns.ca/mailman/listinfo/nslug
Reply | Threaded
Open this post in threaded view
|

Re: TLS/HTTPS

Ben Armstrong-2
Hah! Looks like they have a borked certbot ...

On Thu, Apr 18, 2019 at 9:47 AM George N. White III <[hidden email]> wrote:

> On Thu, 18 Apr 2019 at 02:58, Mike Spencer <[hidden email]> wrote:
>> I'm encountering web sites that a browser won't talk to.  Variously,
>> there's a report of a crypto mismatch or the remote site just closes
>> the connection.
>
> WIth current Google Chrome, I just got:
>
> Attackers might be trying to steal your information from s.engadget.com (for example, passwords, messages or credit cards). Learn more
> NET::ERR_CERT_DATE_INVALID
>
> Subject: s.engadget.com
> Issuer: Let's Encrypt Authority X3
> Expires on: 16 Apr 2019
> Current date: 18 Apr 2019

I initially didn't get the error. On repeats I probably hit a
different system in their content delivery network that still has the
broken certbot.

There was a recent change in the security of the Let's Encrypt service
that rendered older methods of handshake with it invalid & required
administrator intervention to fix at the server end of things. The
typical fix for it is to simply update your certbot version. I've
already done this for some of the servers I admin (including the nslug
server, if I recall correctly ... though maybe I'm misremembering and
that one was already OK). It looks like some subset of their CDN
(Content Delivery Network) has older certbot versions and therefore
are no longer renewing their certs since 16-Apr because Let's Encrypt
no longer wants to talk to them until their certbot version is
upgraded to use an acceptable, secure version of the cert renewal
protocol.

Ben
_______________________________________________
nSLUG mailing list
[hidden email]
http://nslug.ns.ca/mailman/listinfo/nslug
Reply | Threaded
Open this post in threaded view
|

Re: TLS/HTTPS

Rory-9
On Thu, 2019-04-18 at 10:26 -0300, Ben Armstrong wrote:
> Hah! Looks like they have a borked certbot ...
>

I almost got caught with this myself :)  Took the opportunity to switch
to the DNS method which is probably safer anyway.


_______________________________________________
nSLUG mailing list
[hidden email]
http://nslug.ns.ca/mailman/listinfo/nslug