HTTPS Watch - Hackdot

Re:HTTPS Watch by ggreer on Sunday January 18, 2015 @06:17PM (#8909396)

The current ratings seem too simplistic and strict. I think a better rating system would be:

1. None. Not listening on https.

2. Bad. Invalid cert or broken cipher suites.

3. Ok. Valid cert and good cipher suites, but no redirection to https.

4. Good. Http redirects to https.

5. Great. Redirects to https and sets HSTS header.

6. Amazing. In browser HSTS preload lists.

It may make sense to change the criteria as sites improve, but that list seems sane today. I'd also recommend using letter grades (A+, A, B, C, D, F), but that might cause confusion with SSL Labs[1].

1. https://www.ssllabs.com/ssltest/

[ Parent | on HN ]

Re:HTTPS Watch by dogma1138 on Sunday January 18, 2015 @08:36PM (#8909833)

There is much more to HTTPS than just ciphers and HSTS, i would personally use the following rating.

1 None - No HTTPS Support/Invalid certificate/Broken or vulnerable cipher or protocols (POODLE, SSLv2 etc'.) Cookies not set as 'SECURE'.

2 Poor - Valid certificate, weak or anonymous cipher suits, none standard ciphers. Site serves mixed content. Any certificate issues like SHA1/MD5 signatures, low rated CA's, lack of revocation lists etc.

3 Good - Fully validated cert and chain, including revocation lists, supports only secure cipher suits with forward secrecy. HTTP-HTTPS redirection or HSTS, all cookies are set as 'SECURE'. No mixed content.

[ Parent | on HN ]

Re:HTTPS Watch by nsgi on Monday January 19, 2015 @04:00AM (#8911051)

I think the main problem is mixed content. Wikipedia has excellent HTTPS support, but would be listed as mediocre because it isn't the default (I've heard this is due to it needing to be accessible in countries like China). The New York Times (and many other sites) is unusable in HTTPS but has the same classification.

[ Parent | on HN ]

Re:HTTPS Watch by daigoba66 on Sunday January 18, 2015 @07:38PM (#8909663)

So depending on the application and use case, it may be acceptable to not accept connections on port 80. I still think setting the HSTS header is important, but the redirect isn't (always important).

[ Parent | on HN ]

Re:HTTPS Watch by ggreer on Sunday January 18, 2015 @08:09PM (#8909763)

Redirecting to HTTPS is heavily encouraged by the HSTS spec.[1] Clients are just as easily man-in-the-middled if you refuse connections on port 80. The middleman can connect to your HTTPS and use it to send valid (though maliciously corrupted) HTTP responses to the client.

There's only one way to ensure clients aren't MitM'ed on first connect: Go to https://hstspreload.appspot.com/ and submit your site to Chrome's HSTS preload list. Firefox slurps Chrome's list from time to time. The lists are shipped with browser updates, so the whole process takes months.

1. http://tools.ietf.org/html/rfc6797#section-7.2

[ Parent | on HN ]