So it looks like that this seasons NSA/GHCQ backdoor is 0-RTT, and will be implemented into the commercial variants, whilst the open source variants will turn it off by default.
Or use it like Cloudflare, in HTTPS without GET params only.
TLS 1.3 approved
21–30 of 78 posts
Re: TLS 1.3 approved
#22If I'm not mistaken this means no "authorized" MITM - Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.
It does not. There are some passive decryption tools that will no longer work because they functioned by having non-forward-secure connections and the server's private key installed in the decrypter. (But one can just not support TLS 1.3 at the server to keep them working.) MITM proxies, which are trusted by the client and which terminate and recreate the TLS connection, will continue to function. (Assuming they impl…
"Assuming they implemented TLS 1.2 correctly, which some didn't." -> BlueCoat?
Re: TLS 1.3 approved
#23Earlier quoted context omitted.
Which is why it should have never been implemented in TLS 1.3. I believe the argument against not doing it was that some companies will just implement their own protocols instead. Eh, I think the chances of that happening were pretty slim. Now most of the problems we'll see with TLS 1.3 will likely be related to 0-RTT. Also, wasn't that basically the same argument for implementing MITM in TLS 1.3? That if they don't…
0rtt is still useful for static assets, and generally everything that is public. I have a handful of static websites (literally static, as in consisting of just HTML and CSS files), for those 0rtt is awesome. TLS is no longer used to only protect private pages (eg. access to your private emails, the admin section of a CMS). It's also used for privacy reasons on completely public websites.
Tls connection reuse already works for that. And pipelining in http.
Re: TLS 1.3 approved
#24Earlier quoted context omitted.
0rtt is still useful for static assets, and generally everything that is public. I have a handful of static websites (literally static, as in consisting of just HTML and CSS files), for those 0rtt is awesome. TLS is no longer used to only protect private pages (eg. access to your private emails, the admin section of a CMS). It's also used for privacy reasons on completely public websites.
Wouldn't that be a bit of a privacy leak? If 0rrt works, it was a request for a static asset. Of course, TLS is not only for privacy reasons, but also for integrity reasons (preventing injection of malicious Javascript and similar attacks). For that purpose, 0rtt for static assets works fine.
> Wouldn't that be a bit of a privacy leak? If 0rrt works, it was a request for a static asset.
Response size and timing probably already leak this.
Re: TLS 1.3 approved
#25Earlier quoted context omitted.
0rtt is still useful for static assets, and generally everything that is public. I have a handful of static websites (literally static, as in consisting of just HTML and CSS files), for those 0rtt is awesome. TLS is no longer used to only protect private pages (eg. access to your private emails, the admin section of a CMS). It's also used for privacy reasons on completely public websites.
The content of your page may be encrypted but the DNS lookup isn't
There's work now with DNS-over-HTTPS to prevent that.
Re: TLS 1.3 approved
#26So it looks like that this seasons NSA/GHCQ backdoor is 0-RTT, and will be implemented into the commercial variants, whilst the open source variants will turn it off by default. Or use it like Cloudflare, in HTTPS without GET params only.
You make it sound like NSA/GCHQ somehow secretly put in a weakness into a IETF standard that’s gone through many public drafts...
Re: TLS 1.3 approved
#27So it looks like that this seasons NSA/GHCQ backdoor is 0-RTT, and will be implemented into the commercial variants, whilst the open source variants will turn it off by default. Or use it like Cloudflare, in HTTPS without GET params only.
You make it sound like NSA/GCHQ somehow secretly put in a weakness into a IETF standard that’s gone through many public drafts...
That's roughly the line of their job, as we have all learned the hard way a few years back.
Re: TLS 1.3 approved
#28Anyone know what TLS 1.3 offers (or fixes) that TLS 1.2 does not?
Re: TLS 1.3 approved
#290-RTT sounds nice, until you get to appendix E.5. Everyone should read this: E.5. Replay Attacks on 0-RTT Replayable 0-RTT data presents a number of security threats to TLS- using applications, unless those applications are specifically engineered to be safe under replay (minimally, this means idempotent, but in many cases may also require other stronger conditions, such as constant-time response). Potential attacks…
The other thing I don't like about 0-RTT is that the client reveals that they've been to the server before, i.e. it removes a plausible case for anonymity. Just another implicit "cookie" that needs to be washed, I suppose.
I would love if instead the pre-shared secret enabling 0RTT could be something obtained through DNS instead, if that's possible. But that would require a secure DNS, which we don't have.
Re: TLS 1.3 approved
#30Anyone know what TLS 1.3 offers (or fixes) that TLS 1.2 does not?
WolfSSL has a short write up on the changes: https://www.wolfssl.com/differences-between-tls-1-2-and-tls-...