14 ms·

Why TLS 1.3 isn't in browsers yet

190 points by el_duderino 9y ago

nimbius 9y 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 9y 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 9y 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 9y 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_ban 9y 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 9y 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).
    - DKnoll 9y ago
      HSTS only says connections must be encrypted, not with which cert... you're thinking of a CAA record. Although a CAA record doesn't mean much if your adversary controls the DNS server.
      - yrro 9y ago
        I think you're thinking of HTTP Public Key Pinning. A CAA record just tells a CA whether it is permitted to issue certificates for a domain.
        DKnoll 9y ago
        Well actually I think you mean... no just kidding. Thanks for the correction. I thought CAA records would also tell clients if a trusted root was also trusted for that domain.
saurik 9y 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.
- quotemstr 9y ago
  Maybe whoever wrote that code was excellent on soft skills.
  - sp332 9y 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.
    - deleted 9y ago
      [deleted]
- cesarb 9y 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 9y ago
    Fun fact: Trying to apply that to IPv6 ends up without a working network connection.
    - r1ch 9y ago
      Microsoft's Skype for business servers block(ed?) ICMPv6. That was a fun one to track down when there was an MTU issue on our network, especially when their diagnostic tool claimed there was a 403 error from the SIP endpoint!
ncmncm 9y 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 9y 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 9y 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 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).
quotemstr 9y 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 9y 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 9y ago
    Firefox is open source as is large portions of chrome and the engine in safari... So mostly you're talking about IE/Edge...
  - bzbarsky 9y 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/ 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).
    - katastic 9y ago
      >And you almost certainly can't compile some of them with a modern compiler, I wonder how long and difficult it must be to get all the required dependencies to compile a modern web browser... [two hours of obscure error messages later] "You have v2.3030392.302 of dependency 113, you need to compile v2.3030392.300 in 32-bit first, then build the 64-bit version of v2.3030392.301 then ..." You get all the compiler errors fixed and then it's on to round two... linker errors.
misterbowfinger 9y ago
Ugh, why did they have to use Flash... https://tls13.mitm.watch/ 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???
- roblabla 9y 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.
  - slrz 9y ago
    How would that interact with the Same-Origin Policy?
    - kevincox 9y ago
      Since you wouldn't have access to cookies I don't think it would be the end of the world. However you would have access to the users LAN which would likely make many local devices' vulnerabilities exploitable. All in all it is probably a bad idea with the current state of IoT, home routers, printers...
      - Spivak 9y ago
        Giving a web page access to any part of the user's environment not explicitly given to is malicious data exfiltration waiting to happen.
  - QasimK 9y ago
    Imagine if every webpage (JavaScript) could open sockets to any location and port - sounds like a significant security issue.
    - misterbowfinger 9y ago
ori_b 9y ago
It hasn't even been released yet.
- QasimK 9y ago
  This is essentially explaining why it hasn’t been released.
- mkonecny 9y ago
  It was released last year but quickly removed. This article explains why...
newman314 9y 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.
atesti 9y 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 9y 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-part 9y 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 ?
- mkonecny 9y 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.
  - atesti 9y 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.
    - pas 9y ago
      Why do you assume that the middleshits would get upgraded? If fallback works, fallback works. End of story. 80% of operators (governments, corporations, soho setups) will explicitly prefer not touching things if at all possible. They won't fix their "not broken" network.
user5994461 9y ago
Meanwhile, still supporting TLS 1.0 because of office 2010.
user5994461 9y 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/ 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 9y ago
  Flash being required is probably a bigger issue...
- Buge 9y 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 9y 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 https://stackoverflow.com/a/23086139
    - mkonecny 9y ago
      It is incorrect. Read why personal github pages (username.github.com) moved to github.io (username.github.io) https://github.com/blog/1452-new-github-pages-domain-github-io https://github.com/blog/1452-new-github-pages-domain-github-...
yeukhon 9y 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-milestone-for-servo-acid2/ https://research.mozilla.org/2014/04/17/another-big-mileston...
wav-part 9y 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 9y 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-part 9y ago
    Ofcourse CL should never downgrade to non-secure versions. SSLv3 is discouraged so CL wont try this. But 1.2 still ok.
    - majewsky 9y ago
      That's what they said about SSL 3 some time ago.
      - wav-part 9y ago
        If a client and server both dont upgrade to secure version and still use old now-broken version, there is nothing to be done. This thread is just now getting repeatitive.
    - syncsynchalt 9y ago
      TLS 1.2 is insecure. Prove me wrong. So I guess we can't downgrade to it, and we should make 1.3 work without re-negotiation.
snvzz 9y 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 9y ago
site down for maintenance.. cache: http://webcache.googleusercontent.com/search?q=cache:BQlyePwWdUoJ:blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet/ http://webcache.googleusercontent.com/search?q=cache:BQlyePw...

190 points by el_duderino 9y 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 9y 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 9y 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 9y 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_ban 9y 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 9y 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).
  - DKnoll 9y ago
    HSTS only says connections must be encrypted, not with which cert... you're thinking of a CAA record. Although a CAA record doesn't mean much if your adversary controls the DNS server.
    - yrro 9y ago
      I think you're thinking of HTTP Public Key Pinning. A CAA record just tells a CA whether it is permitted to issue certificates for a domain.
      - DKnoll 9y ago
        Well actually I think you mean... no just kidding. Thanks for the correction. I thought CAA records would also tell clients if a trusted root was also trusted for that domain.

saurik 9y 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.

quotemstr 9y ago
Maybe whoever wrote that code was excellent on soft skills.
- sp332 9y 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.
  - deleted 9y ago
    [deleted]
cesarb 9y 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 9y ago
  Fun fact: Trying to apply that to IPv6 ends up without a working network connection.
  - r1ch 9y ago
    Microsoft's Skype for business servers block(ed?) ICMPv6. That was a fun one to track down when there was an MTU issue on our network, especially when their diagnostic tool claimed there was a 403 error from the SIP endpoint!

ncmncm 9y 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 9y 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 9y 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 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).

quotemstr 9y 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 9y 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 9y ago
  Firefox is open source as is large portions of chrome and the engine in safari... So mostly you're talking about IE/Edge...
- bzbarsky 9y 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/ 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).
  - katastic 9y ago
    >And you almost certainly can't compile some of them with a modern compiler, I wonder how long and difficult it must be to get all the required dependencies to compile a modern web browser... [two hours of obscure error messages later] "You have v2.3030392.302 of dependency 113, you need to compile v2.3030392.300 in 32-bit first, then build the 64-bit version of v2.3030392.301 then ..." You get all the compiler errors fixed and then it's on to round two... linker errors.

misterbowfinger 9y ago

Ugh, why did they have to use Flash... https://tls13.mitm.watch/ 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???

roblabla 9y 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.
- slrz 9y ago
  How would that interact with the Same-Origin Policy?
  - kevincox 9y ago
    Since you wouldn't have access to cookies I don't think it would be the end of the world. However you would have access to the users LAN which would likely make many local devices' vulnerabilities exploitable. All in all it is probably a bad idea with the current state of IoT, home routers, printers...
    - Spivak 9y ago
      Giving a web page access to any part of the user's environment not explicitly given to is malicious data exfiltration waiting to happen.
- QasimK 9y ago
  Imagine if every webpage (JavaScript) could open sockets to any location and port - sounds like a significant security issue.
  - misterbowfinger 9y ago

ori_b 9y ago

It hasn't even been released yet.

QasimK 9y ago
This is essentially explaining why it hasn’t been released.
mkonecny 9y ago
It was released last year but quickly removed. This article explains why...

newman314 9y 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.

atesti 9y 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 9y 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-part 9y 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 ?
mkonecny 9y 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.
- atesti 9y 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.
  - pas 9y ago
    Why do you assume that the middleshits would get upgraded? If fallback works, fallback works. End of story. 80% of operators (governments, corporations, soho setups) will explicitly prefer not touching things if at all possible. They won't fix their "not broken" network.

user5994461 9y ago

Meanwhile, still supporting TLS 1.0 because of office 2010.

user5994461 9y 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/ 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 9y ago
Flash being required is probably a bigger issue...
Buge 9y 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 9y 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 https://stackoverflow.com/a/23086139
  - mkonecny 9y ago
    It is incorrect. Read why personal github pages (username.github.com) moved to github.io (username.github.io) https://github.com/blog/1452-new-github-pages-domain-github-io https://github.com/blog/1452-new-github-pages-domain-github-...

yeukhon 9y 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-milestone-for-servo-acid2/ https://research.mozilla.org/2014/04/17/another-big-mileston...

wav-part 9y 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 9y 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-part 9y ago
  Ofcourse CL should never downgrade to non-secure versions. SSLv3 is discouraged so CL wont try this. But 1.2 still ok.
  - majewsky 9y ago
    That's what they said about SSL 3 some time ago.
    - wav-part 9y ago
      If a client and server both dont upgrade to secure version and still use old now-broken version, there is nothing to be done. This thread is just now getting repeatitive.
  - syncsynchalt 9y ago
    TLS 1.2 is insecure. Prove me wrong. So I guess we can't downgrade to it, and we should make 1.3 work without re-negotiation.

snvzz 9y 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 9y ago

site down for maintenance.. cache: http://webcache.googleusercontent.com/search?q=cache:BQlyePwWdUoJ:blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet/ http://webcache.googleusercontent.com/search?q=cache:BQlyePw...