3 ms·

It is an excellent tool. For a bit more background I found [1] (from 2016) quite insightful. In addition here are a few notes that I collected using it, no cri

It is an excellent tool. For a bit more background I found [1] (from 2016) quite insightful. In addition here are a few notes that I collected using it, no criticism - just (hopefully) constructive feedback: - The SSH (H not L) Observatory part seems to be broken for a long time (months at least). Not exactly sure what it was supposed to do anyway and how useful it would have been. - I find the nomenclature for the Compatibility Level a bit unfortunate. As far as I understand, the highly secure and practically useful configurations recommended by Mozilla and elsewhere, all end up classified as Intermediate. The more desirable sounding Modern seems to be unachievable for any real world site. I'd love to see counterexamples if I'm wrong. - It seems not to be very actively maintained since its main (and original?) author April King left Mozilla. About a half a year ago I filed an issue where the Observatory scan hung forever for certain sites [2], but apparently no one ever looked at it. (Maybe it is not an issue with the Observatory, but I think I wrote a decent report and hoped for some feedback). [1] https://pokeinthe.io/2016/08/25/observatory-by-mozilla-a-new-tool/ https://pokeinthe.io/2016/08/25/observatory-by-mozilla-a-new... [2] https://github.com/mozilla/http-observatory-website/issues/244 https://github.com/mozilla/http-observatory-website/issues/2...

ff317 5y ago
> The more desirable sounding Modern seems to be unachievable for any real world site. I'd love to see counterexamples if I'm wrong. I'd agree that the description of "M" in https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations https://wiki.mozilla.org/Security/Server_Side_TLS#Recommende... is unrealistic for a site with a large and diverse audience, so far. The primary issue is that it requires turning off TLSv1.2. Wikipedia is a good example of "about as Modern as you can get in the real world with a big global audience". It's a little stricter than "Intermediate", but doesn't quite meet the "Modern" description. The key items there are that Wikipedia still supports TLSv1.2 (but only with TLSv1.3-like ciphers) and it still supports dual cert compatibility (ECDSA+RSA). The RSA support is likely to be on chopping block Soon, as the only real use-case for RSA in this config is to support ancient installs of the last-known-good version of Chrome (49) on WinXP SP3, but Wikipedia will likely have to continue supporting TLSv1.2 for quite some time. In any case, though, Wikipedia still gets an "M" rating in the check, so either the description is wrong or the check is buggy: https://observatory.mozilla.org/analyze/en.wikipedia.org#tls https://observatory.mozilla.org/analyze/en.wikipedia.org#tls
- tialaramex 5y ago
  Today TLS 1.2 support is less worrying than it might have been so long as your TLS 1.3 implementation is competent. TLS 1.3 downgrade protection means that most downgrade attack avenues aren't viable. In earlier versions the downgrade protection was pretty flimsy so it's more of a worry that a server offering TLS 1.0 through TLS 1.2 could be vulnerable to downgrade and then a TLS 1.0-only attack works on clients that could have done TLS 1.2 but were downgraded. Nobody's halfway decent TLS 1.3 client will allow that, if you try to downgrade it, the client gives up instead. Denial of service was always possible, but downgrade needn't be. Most of this is actual design work in TLS 1.3 but a fair amount is simply willpower from major clients like web browsers. Deciding that OK, if you insist on downgrading the protocol we would rather tell the user the site is inaccessible than allow that.

ff317 5y ago

> The more desirable sounding Modern seems to be unachievable for any real world site. I'd love to see counterexamples if I'm wrong. I'd agree that the description of "M" in https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations https://wiki.mozilla.org/Security/Server_Side_TLS#Recommende... is unrealistic for a site with a large and diverse audience, so far. The primary issue is that it requires turning off TLSv1.2. Wikipedia is a good example of "about as Modern as you can get in the real world with a big global audience". It's a little stricter than "Intermediate", but doesn't quite meet the "Modern" description. The key items there are that Wikipedia still supports TLSv1.2 (but only with TLSv1.3-like ciphers) and it still supports dual cert compatibility (ECDSA+RSA). The RSA support is likely to be on chopping block Soon, as the only real use-case for RSA in this config is to support ancient installs of the last-known-good version of Chrome (49) on WinXP SP3, but Wikipedia will likely have to continue supporting TLSv1.2 for quite some time. In any case, though, Wikipedia still gets an "M" rating in the check, so either the description is wrong or the check is buggy: https://observatory.mozilla.org/analyze/en.wikipedia.org#tls https://observatory.mozilla.org/analyze/en.wikipedia.org#tls

tialaramex 5y ago
Today TLS 1.2 support is less worrying than it might have been so long as your TLS 1.3 implementation is competent. TLS 1.3 downgrade protection means that most downgrade attack avenues aren't viable. In earlier versions the downgrade protection was pretty flimsy so it's more of a worry that a server offering TLS 1.0 through TLS 1.2 could be vulnerable to downgrade and then a TLS 1.0-only attack works on clients that could have done TLS 1.2 but were downgraded. Nobody's halfway decent TLS 1.3 client will allow that, if you try to downgrade it, the client gives up instead. Denial of service was always possible, but downgrade needn't be. Most of this is actual design work in TLS 1.3 but a fair amount is simply willpower from major clients like web browsers. Deciding that OK, if you insist on downgrading the protocol we would rather tell the user the site is inaccessible than allow that.