Why TLS 1.3 isn't in browsers yet

https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet/

by el_duderino • 9 years ago

190 116 9 years ago

blog.cloudflare.com

nimbius• 9 years ago

"Middleboxes" is a pretty chicken shit definition of what are essentially appliances that, at best, allow companies to spy on employees and at worst enable despotic governments to target and crush dissent. My security should not have to wait for the devices that seek to violate it.

colmmacc• 9 years ago

Most of these middle boxes aren't actually man-in-the-middle attacking TLS. Instead they are enforcing aspects of the protocol, as some kind of Firewall. Sometimes this is silly fluff, preventing the bit-torrent protocol from running over port 443.

But sometimes it is useful: after HeartBleed I wrote a TLS inspecting firewall that blocks heartbeat records and I know it really helped get some customers out of a deep hole (they were unable to upgrade the impacted software itself).

Often it is something in the middle; like firewalls that look at SNI and X509 certificates to block "bad" domains associated with phishing and other abuse.

acranox• 9 years ago

I think middleboxes also just includes network load balancers. A lot of places do TLS termination at a load balancer and plain HTTP inside the data center. These load balancer appliances are probably where a lot of these issues come up. And they aren’t there to spy on you.

Freak_NL• 9 years ago

Load balancers tend to be used on the server-side though, where the servers behind the load balancer serve web API's and such. It's fine if a TLS tunnel terminates at the edge of your private network if what's behind it is aware of this — i.e., the servers within the network serve plain HTTP by design and delegate transport layer security to the load balancer. TLS 1.3 doesn't break this.

These middleboxes are a way to spy on HTTPS connections between browsers and servers (where server can mean the load balancer at the edge of your server cluster), without having to ensure every device on the local network has a set of spyware installed on it.

unethical_ban3• 9 years ago

"Spy on employees" = Monitor the network activity of a sensitive, private business network.

I'll give the same spiel I give every time proxies come up: I am a donor to EFF, friend of privacy and the 4th amendment and I love the ACLU. I also recognize the legitimacy and importance of MITM proxies that inspect the content of SSL on a corporate network. It's not despotic to deploy company assets with company root CA certs that proxy TLS traffic to make sure a random employee isn't uploading credit card data to Box.

wyldfire• 9 years ago

I wish browsers would visually distinguish between the vanilla trust store from the OS or browser vendor and the current trust store as may have been altered by the system owner. Maybe the API to various certificate stores can't tell you this? But in practice there's probably some certificate qualities that are "really really good" at indicating where this connection is trusted on this computer but would not have been trusted by a newly installed Windows/macOS/linux/firefox/chrome system.

If you are going to spy on me, please disclose when and where. AFAIK w/HSTS sites they generally don't interdict the traffic (not because they don't want to but probably because they can't).

kodablah3• 9 years ago

make sure a random employee isn't uploading credit card data to Box

Except you aren't making sure, and there are many ways sensitive data can be exported. Let's be honest with ourselves here, these measures are often implemented under the guise of security but really are just liability and risk reduction approaches. The practical security benefit is very low IME, especially considering the burdens these measures put on employees' ability to work their best (and, as this article points out, burdens on others as well).

MaulingMonkey5• 9 years ago

to make sure a random employee isn't uploading credit card data to Box.

or the PDF they clicked on

brohee• 9 years ago

Data Loss Prevention solutions are the only class of security products I can think of that attacks the problem in a worst way than antivirus do... That's say a lot.

All the time spent implementing those "solutions" would be better spent deploying proper access control, so that retards that may inadvertently upload confidential data to box don't have access to the information in the first place. As a bonus, it also protects you better from malice and not only stupidity.

saurik• 9 years ago

When presented with a client hello with version 3.4, a large percentage of TLS 1.2-capable servers would disconnect instead of replying with 3.3.

As someone who has implemented a ton of protocols, I honestly don't understand how anyone even does something this stupid.

quotemstr2• 9 years ago

Maybe whoever wrote that code was excellent on soft skills.

sp332• 9 years ago

If the team had good soft skills, they might have felt comfortable to ask questions about edge cases. And they might have put the work in to make sure they understood the users' goals. Instead they probably just wrote code to pass some conformance test and patted themselves on the back for being very technically correct.

cesarb• 9 years ago

It's the "fail closed" principle in action: if I don't understand it, it must be malicious, so the connection should be rejected as swiftly as possible.

Also seen in firewalls which drop all ICMP packets ("the only real-world use of ICMP is ping floods, right?"), breaking PMTUD.

DiabloD3• 9 years ago

Fun fact: Trying to apply that to IPv6 ends up without a working network connection.

jchw2• 9 years ago

But this isn't fail-closed. The specification allows for newer versions. The problem is, you are supposed to spit back the version you actually support instead of disconnecting. I don't understand how this can be interpreted as anything but non-compliance of the standard.

toast0• 9 years ago

As someone who has debugged many weird TLS problems, I'm not at all surprised. The protocol documentation is pretty hard to use, so I'm not surprised that server or proxy implementations would bail out on unexpected input, and that they would only use existing clients as their base of expected input.

magicalhippo• 9 years ago

Reminds me of the OpenGL 2.0 version issue. So many games and programs just checked the minor version number, as OpenGL had been stuck in 1.x land for over a decade.

So when drivers suddenly started reporting 2.0 rather than 1.3 or 1.4 the flawed version check failed and reported you didn't have a modern enough OpenGL implementation.

ncmncm• 9 years ago

This article doesn't explain why they have so much trouble with versioning a protocol that is quite a lot simpler than many IP protocols that work. They shouldn't need GREASE, because anybody implementing TLS should be testing against a dedicated server, identified in the RFC, that connects as a client and jiggles all the knobs.

What, no conformance testing address is in the RFC? There's your problem right there.

To the conspiracy-minded among us, it is clear that "some people" don't want progress on encrypted communications, and know just what percentage of devices need to be intolerant of progress to stall adoption of fixes. Making browsers treat dropped connections as part of the protocol was very convenient for "those people". I.e., this is not (significantly) a matter of incompetent implementers, this is an enemy attack. Deployment plans that assume good faith by all parties fail under enemy attack.

As with everything cryptographic, a threat model is essential. Deployment is as much a part of the system and attack surface as the ciphers.

skissane• 9 years ago

What, no conformance testing address is in the RFC? There's your problem right there.

The vast majority of RFCs don't have conformance testing suites. IETF focuses on interoperability testing, which demonstrates that independent implementations work together for the major use cases, it doesn't test all the edge cases (such as future version negotiation) that a good conformance test would.

Creating and maintaining a conformance test is an order of magnitude more work than creating or maintaining a specification.

Someone has to be willing to expend the effort, and that usually means it has to make economic sense, and it rarely does.

And even when it does, in order to gain funding it often has to be licensed on commercial terms, which puts it out of reach of a lot of open source projects and smaller commercial implementors. (Even many large companies wouldn't pay for a test suite unless customers start putting it in RFPs.)

NIST used to maintain a whole bunch of free conformance test suites (CGM, COBOL, FORTRAN, PHIGS, POSIX, SQL), but the US government decided to stop paying for that.

gsnedders• 9 years ago

The WHATWG and the W3C have been moving in a very different direction, treating testing as a major part of spec development, because the goal is to get implementations of the specifications, and how do you determine that if not by testing.

https://blog.whatwg.org/improving-interoperability is a post from the WHATWG side about this, and the outcome isn't just the direct "it's easier to write code against tests" but also "it's easier to notice when the spec changes" (because you now get a failing test).

kevin_thibedeau• 9 years ago

The protocol supports versioning just fine. There's an entire negotiation phase in the handshake just for that. The problem is there are too many broken implementations of TLS 1.2 out there.

quotemstr2• 9 years ago

The ossification phenomenon happens to all sorts of APIs. Consider stat(2): all hell would break loose if we introduced another file type for st_mode. I'm a fan of keeping things "well oiled" by exercising extension points that are supposed to keep working.

That said, I wish we would be more willing to force these rusted joints to open, breakage be damned. Breaking 3% of the web sounds like a lot, but it's not that much, especially considering that anyone broken will very quickly upgrade.

By using elaborate workarounds described in the article, we recognize and reward the worst technical practices. The author may not want to cast blame, but I do.

nerdponx• 9 years ago

I'm okay with this if and only if browser vendors make old releases available for download, or better yet open-source their old releases. That way we can be more confident, when archiving pages that no longer render correctly, someone will be able to actually view them.

jopsen• 9 years ago

Firefox is open source as is large portions of chrome and the engine in safari...

So mostly you're talking about IE/Edge...

bzbarsky2• 9 years ago

Old Firefox releases (binary and source) are very much available for download, though whether you can run them on modern operating systems somewhat varies. And you almost certainly can't compile some of them with a modern compiler, though a compiler from the era of the release should work...

Anyway, https://ftp.mozilla.org/pub/firefox/releases/ has links to all the Firefox release binaries and corresponding source snapshots starting with version 0.8. It includes a number of the betas as well (so for example has the Firefox 58 beta builds already).

mangix• 9 years ago

The numbers shown were more than 3%

pornel• 9 years ago

Web breakage is a Prisoner's Dilemma. Unless all major vendors agree to break the same thing at the same time, the one that "defects" to being compatible with garbage will seem more reliable to users. Remember, most users don't know what TLS is, but they care whether the page they wanted to see opens "fine" or shows scary errors.

We've been there with CSS box model, DOM levels, (X)HTML(5), and CSS prefixes. There have been some cases of cooperation, e.g. SHA-1 certs and kicking of bad CAs, but most of the time browser vendors only "break" things gradually and only when it affects < 0.1%.

unscaled• 9 years ago

Considering Chrome's market share, it's enough for Chrome to break something to force server-side action. Distrusting Symantec certificates is a prime example, I think. The breakage rate for distrusting all Symantec certificates is significantly higher than 0.1%, but there is just one vendor that needs to fix things.

Middleboxes are considerably more problematic, since you've got a lot of manufacturers out there, some of them might actually be out of business. Pushing firmware upgrades to all of those middleboxes would also be a nightmare. And the icing on the cake is actually finding the malfunctioning middleboxes, since they can be anywhere between the end user and the web server.

0xcde4c3db• 9 years ago

We've been there with CSS box model, DOM levels, (X)HTML(5), and CSS prefixes.

Other examples:

Content-Type. There were a few years where many sites were misconfigured to serve virtually every non-HTML file as text/plain. IE, deviating from the HTTP spec, always used its own algorithm to detect the actual file type and thus "worked", whereas Netscape (and later Mozilla) respected the header and would display "garbage".

Windows-1252 mojibake. Various Windows-based authoring tools simply used the native Windows code page 1252 to encode their text in HTML files, which were then claimed to be encoded as ASCII or ISO 8859-1. This led to documents that mostly looked correct but would have garbage sprinkled around due to added punctuation in Windows-1252 (primarily the distinct open/close quotes and em-dashes, if memory serves). IE of course handled these "correctly", i.e. interpreted ASCII or ISO 8859-1 to mean Windows-1252. I think this behavior is now specified by HTML5 under certain conditions.

misterbowfinger2• 9 years ago

Ugh, why did they have to use Flash...

https://tls13.mitm.watch/

I know they mention it here:

It uses Adobe Flash, because that’s the only widespread cross-platform way to get access to raw sockets from a browser.

But there's really no other way???

roblabla2• 9 years ago

That's actually a huge annoyance of mine. There's no stable, cross-platform web API to get raw sockets, and I'm not sure why.

slrz2• 9 years ago

How would that interact with the Same-Origin Policy?

QasimK2• 9 years ago

Imagine if every webpage (JavaScript) could open sockets to any location and port - sounds like a significant security issue.

Franciscouzo2• 9 years ago

There's this [0] standard that nobody implements, AFAIK the security risks could be mitigated by asking for confirmation from the user.

[0] https://www.w3.org/TR/tcp-udp-sockets/

jchw2• 9 years ago

I really don't think there should be a way, frankly. This shouldn't be tested from a webapp.

fulafel• 9 years ago

Raw sockets are not required for TCP protocols, need root privileges and hopefully are not used by flash. Terminology problem?

ori_b• 9 years ago

It hasn't even been released yet.

QasimK2• 9 years ago

This is essentially explaining why it hasn’t been released.

mkonecny4• 9 years ago

It was released last year but quickly removed. This article explains why...

newman314• 9 years ago

Sigh. I'm leading an effort to cleanup TLS company wide and it's a nightmare.

I get why some people want middleboxes but honestly, I'd rather TLS1.3 take the opportunity to clean things up instead of coming up with workarounds for fallback.

atesti2• 9 years ago

To me it sounds like reenabling the fallback with trying TLS1.2 after TLS1.3 fails for a connection would be the best solution to gradually upgrade all devices.

kalleboo• 9 years ago

The article says "Browsers did not want to re-enable the insecure downgrade and fight the uphill battle of oiling the protocol negotiation joint again for the next half-decade." So I guess the natural solution to that is making the TLS protocol a User-Agent-esque nightmare of compatibility patches and pretending to support something you don't which surely WONT come back to bite them in the ass years down the line...

wav-part10• 9 years ago

1.2 is still secure. This downgrading/oiling is simple and works for all future versions.

TLS is already so complex and ASN.1 makes xml look like c-struct. This begs the question: why would anyone want to make a crypto overly complex ?

mkonecny4• 9 years ago

This is exactly what they are trying to avoid. Read the article and you will see this thinking is how the POODLE attack happened.

atesti2• 9 years ago

Yes, I read it, but I think a clean new TLS 1.3 with that old retry fallback system like before would still have been the best solution to establish TLS 1.3 without breakage. Poddle was solved by SCSV and this could be part of TLS 1.3 again, but even a desaster that makes us turn off TLS 1.2 5 years from now is a "good" solution because then the middleboxes have been upgraded.

user59944612• 9 years ago

Meanwhile, still supporting TLS 1.0 because of office 2010.

user59944612• 9 years ago

>> To help support this discussion with data, we built a tool to help check if your network is compatible with TLS 1.3: https://tls13.mitm.watch/

The name is so terrible that I can't tell if it's a malware or a porn site.

If anyone from cloudflare is reading, please host your project on something legit. tls13test.cloudflare.com or whatever.

zeep• 9 years ago

Flash being required is probably a bigger issue...

Buge• 9 years ago

The downside of hosting things all in the same domain is that cookies are shared between them, so a vulnerability in one site (e.g. XSS) leads to compromise of all sites. Choosing different domains means they are sandboxed and safe from each other.

Any domain name could be used to host porn. But not any domain name can get linked from a cloudflare blog. I think the fact that it's linked from cloudflare's blog should indicate that it's fine.

tombrossman• 9 years ago

The downside of hosting things all in the same domain is that cookies are shared between them, so a vulnerability in one site (e.g. XSS) leads to compromise of all sites. Choosing different domains means they are sandboxed and safe from each other.

I believe this is incorrect. Cookies should only be shared (by default) if the domain matches exactly, which is why it's best practice to use a www subdomain instead of the domain alone. For example, www.example.com cookies will not be shared with test.example.com by default, though this can be enabled. See here for a fuller explanation: https://stackoverflow.com/a/23086139

yeukhon• 9 years ago

There is no signal to developers that an implementation is flawed, and so mistakes can happen without being noticed. That is, until a new version of the protocol is deployed and your implementation fails, but by then the code is deployed and it could take years for everyone to upgrade.
If a protocol is designed with a flexible structure, but that flexibility is never used in practice, some implementation is going to assume it is constant.

Perhaps this is a naive thought. I remember several years ago Mozilla announced its experimental browser rendering engine (Servo) passed Acid 2 tests [1]. So why can't we come together and create such standard tests so that server implementers and middlebox implementers are encouraged to include them as part of their QA score?

I know this is an optional. There is no mandate, but it sounds like a start. Isn't there some network vendor organization the major players are part of?

[1] https://research.mozilla.org/2014/04/17/another-big-mileston...

wav-part10• 9 years ago

I dont get the crisis. If 3% disconnect with 1.3, then retry again with secure 1.2. Its only a performence penalty for those 3%. Its obviously less than lets-talk-about-it penalty.

jve• 9 years ago

Except it is INSECURE: > However, insecure downgrades are called insecure for a reason. Client downgrades are triggered by a specific type of network failure, one that can be easily spoofed. From the client’s perspective, there’s no way to tell if this failure was caused by a faulty server or by an attacker who happens to be on the path of the connection network. This means that network attackers can inject fake network failures and trick a client into connecting to a server with SSLv3, even if both support a newer protocol. At this point, there were no severe publicly-known vulnerabilities in SSLv3, so this didn’t seem like a big problem. Then POODLE happened.

wav-part10• 9 years ago

Ofcourse CL should never downgrade to non-secure versions. SSLv3 is discouraged so CL wont try this. But 1.2 still ok.

MaulingMonkey5• 9 years ago

The article calls this "insecure downgrade" - which is not just the performance penalty you say it is, it's also a security penalty that's been previously (ab)used via POODLE. It's also code that's been removed and would need re-implementing, re-testing, etc.

The only crisis the article mentions - in passing at that - is when they tried to roll out 1.3 initially and things broke outright at alarmingly high rates. Whoever wrote the article appears to be a fan of discussing things before they turn into crisises.

wav-part10• 9 years ago

Hows downgrading to _secure 1.2_ insecure ? Regarding sslv3, why would client ever use it, downgrade/POODLE or not ?

This is literally very simple, few lines of patch. Its basically tls server discovery.

Its a crisis when a upgrade makes 3% webservers stop working.

mkonecny4• 9 years ago

This is exactly with what happened with Poodle and SSLv3 and it's in the article. Attackers were successfully downgrading to the vulnerable SSL when a TLS connection was attempted.

In the future when TLS1.2 is considered insecure, we do not want this workaround in place.

snvzz• 9 years ago

I say: Just break middleboxes. Do it well. Red padlock "TLS connection downgraded because middlebox".

This shit shouldn't exist in the first place. Routers shouldn't look past the layer 3 headers of the packet.

sloxy• 9 years ago

site down for maintenance.. cache: http://webcache.googleusercontent.com/search?q=cache:BQlyePw...

Why TLS 1.3 isn't in browsers yet

Related Stories