3 ms·

This is very wise of them. Rolling out new network features is always going to be something of an experiment, no matter how confident you are that the feature m

This is very wise of them. Rolling out new network features is always going to be something of an experiment, no matter how confident you are that the feature meets all the standards and works in all browsers and all OSes. You never know what weird stuff is going to be out there that will screw things up. Back when they first tried to roll out TLS 1.3 there were tons of problems due to buggy middleboxes in corporate networks that couldn't conceive of a new TLS protocol. Thankfully they worked around it, but it probably sucked for the guinea pigs. CloudFlare's giant footprint of free customers gives them an advantage: it's way more acceptable to roll out new potentially downtime-causing features to users who aren't paying than to businesses paying you hundreds to thousands of dollars per month. The free tier gives them a bit of leeway to experiment, and gives them massive amounts of data from around the world to tell them how those experiments are working.

tialaramex 3y ago
You're likely thinking of the point when the TLS 1.3 core protocol design was finished, but they were experimenting to understand deployability. This is long before the TLS 1.3 protocol your browser uses today was finished, and that is about half a year earlier than RFC 8446 was published. So any "guinea pigs" in this experiment know what they're getting into, likely people explicitly working on, or in a group tasked with supporting, TLS 1.3. This is like that Windows 95 era but instead of buying random Windows software in a Best Buy to check it works on Win95 before you ship it, you are raising Purchase Orders to buy the "Best Security Office SSL Protection Plus" or whatever to check what it does with your prototype TLS 1.3 stack. The most important thing expected and confirmed in the deployability testing is that many of the middleboxes were allergic to new TLS versions de facto. TLS says clients announce the maximum "version" of SSL they can do, then a server chooses the same or any lower version e.g. 0x0303 means SSL 3.3 which in reality is named TLS 1.2. However most middleboxes react to any version they don't understand by freaking out, so you can't ever say you speak a newer version. The initial TLS 1.3 design chooses 0x0304 with 0x0400 also a possibility, but neither would be deployable for this reason. The most important surprise was that middleboxes are so reluctant to allow people's web browsing to just break that they mostly instead don't implement any meaningful security at all in a certain edge case. This is surprising to an engineer but makes sense once you understand their business (they sell tiger-deterring rocks, they don't sell tiger insurance, so they don't care that the rocks don't work, they're relying on the fact that there probably aren't any tigers and if there are too bad for you trusting their useless rocks). As a result of this insight RFC 8446 TLS 1.3 connections actually start like this: 1.3 Client: Hello some-server-name, I'm the TLS 1.2 client you were talking to earlier, just resuming our earlier conversation number #random-nonsense. Also, just thought you might like to know I support optional FLY CASUAL THIS IS TLS 1.3 with a bunch of parameters 1.3 Server: Hello, yes let's resume our conversation. I too know FLY CASUAL THIS IS TLS 1.3 and I've got a different bunch of parameters. And then everything is encrypted. Which makes sense, we said we're resuming a TLS 1.2 conversation, of course those are encrypted, nothing to see here, if the middlebox tampers with it that'll break people's web browsing. But actually the DH key agreement parameters for the session were in that optional extension and we aren't talking TLS 1.2 at all.

tialaramex 3y ago

You're likely thinking of the point when the TLS 1.3 core protocol design was finished, but they were experimenting to understand deployability. This is long before the TLS 1.3 protocol your browser uses today was finished, and that is about half a year earlier than RFC 8446 was published. So any "guinea pigs" in this experiment know what they're getting into, likely people explicitly working on, or in a group tasked with supporting, TLS 1.3. This is like that Windows 95 era but instead of buying random Windows software in a Best Buy to check it works on Win95 before you ship it, you are raising Purchase Orders to buy the "Best Security Office SSL Protection Plus" or whatever to check what it does with your prototype TLS 1.3 stack. The most important thing expected and confirmed in the deployability testing is that many of the middleboxes were allergic to new TLS versions de facto. TLS says clients announce the maximum "version" of SSL they can do, then a server chooses the same or any lower version e.g. 0x0303 means SSL 3.3 which in reality is named TLS 1.2. However most middleboxes react to any version they don't understand by freaking out, so you can't ever say you speak a newer version. The initial TLS 1.3 design chooses 0x0304 with 0x0400 also a possibility, but neither would be deployable for this reason. The most important surprise was that middleboxes are so reluctant to allow people's web browsing to just break that they mostly instead don't implement any meaningful security at all in a certain edge case. This is surprising to an engineer but makes sense once you understand their business (they sell tiger-deterring rocks, they don't sell tiger insurance, so they don't care that the rocks don't work, they're relying on the fact that there probably aren't any tigers and if there are too bad for you trusting their useless rocks). As a result of this insight RFC 8446 TLS 1.3 connections actually start like this: 1.3 Client: Hello some-server-name, I'm the TLS 1.2 client you were talking to earlier, just resuming our earlier conversation number #random-nonsense. Also, just thought you might like to know I support optional FLY CASUAL THIS IS TLS 1.3 with a bunch of parameters 1.3 Server: Hello, yes let's resume our conversation. I too know FLY CASUAL THIS IS TLS 1.3 and I've got a different bunch of parameters. And then everything is encrypted. Which makes sense, we said we're resuming a TLS 1.2 conversation, of course those are encrypted, nothing to see here, if the middlebox tampers with it that'll break people's web browsing. But actually the DH key agreement parameters for the session were in that optional extension and we aren't talking TLS 1.2 at all.