0-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…
By the looks of it, Cloudflare already does support 0-RTT as a (generally available) beta feature in the crypto tab of a website. Maybe TLS 1.3 not being enabled on the origin machine protects the origin from this type of attack.
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…
Does that assume that all of the components (browser and server) support 1.2 as well? In a theoretical future state if I disable 1.2 on my browser doesn't that mean I won't trust a MITM box.
> Does that assume that all of the components (browser and server) support 1.2 as well?
No: a client, server, and MITM proxy can all be exclusively TLS 1.3 and everything will still work(+).
0-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…
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.
0-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…
Cloudflare only supports 0-rtt for GET requests with no query parameters in an attempt to limit the attack surface.[0] It is enabled by default for all free accounts.
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.
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.
0-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…
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…
> And who cares about a little bit of an extra HTTPS delay, when just adding Google analytics and Facebook Pixel to your site can increase the delay by over 400 ms?
That's how you might feel if you live with fast broadband internet. A lot of the world is stuck with high latency, low-bandwidth connections. Applications that are incredibly lean will still be slow if the server is in San Jose and the client is in, say, Uganda.
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.
The content of your page may be encrypted but the DNS lookup isn't
0-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…
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…
I run a very large number of web performance tests and GA and the Facebook pixel do not add 400ms either alone or together of user-perceptible speed decreases. They will take some small amount of main thread time for parse and compile, but they are loaded async and generally not performance problems on the (hundreds) of pages I have profiled.
Intercom and other live chat solutions are typically the biggest offenders on modern pages. They serve 10-20x the script as GA and the Facebook pixel.
If 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.
This is not true. The client can simply skip the certificate verification, making the connection unauthenticated. Raw Public Keys (which are basically simplified X.509 certificates), can also lead to unauthenticated connections.
In fact, Appendix C5[1] reads:
Previous versions of TLS offered explicitly unauthenticated cipher
suites based on anonymous Diffie-Hellman. These modes have been
deprecated in TLS 1.3. However, it is still possible to negotiate
parameters that do not provide verifiable server authentication by
several methods, including:
- Raw public keys [RFC7250].
- Using a public key contained in a certificate but without
validation of the certificate chain or any of its contents.
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…
I run a very large number of web performance tests and GA and the Facebook pixel do not add 400ms either alone or together of user-perceptible speed decreases. They will take some small amount of main thread time for parse and compile, but they are loaded async and generally not performance problems on the (hundreds) of pages I have profiled. Intercom and other live chat solutions are typically the biggest offenders…
GA and FB-P both effect the document complete time; but your right, there are way way worse scripts out there.