[nSLUG] TLS/HTTPS

George N. White III gnwiii at gmail.com
Thu Apr 18 09:47:43 ADT 2019


On Thu, 18 Apr 2019 at 02:58, Mike Spencer <mspencer at tallships.ca> 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
<http://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
<https://www.ssllabs.com/ssltest/index.html> that will generate a report
for a server's
configuration.   There are openssl examples
<https://www.feistyduck.com/library/openssl-cookbook/online/ch-testing-with-openssl.html>
:

$ 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
Location: http://sailthru.com
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
<https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.1.0/com.ibm.mq.doc/sy10630_.htm>
has
overviews of SSL and TLS.
These have many options, and IBM refers to the FIPS requirements.
Mozilla Server Side TLS
<https://wiki.mozilla.org/Security/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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nslug.ns.ca/pipermail/nslug/attachments/20190418/c5bdc831/attachment-0001.html>


More information about the nSLUG mailing list