7 ms·
The situation is additionally confused by the fact that the version numbers do not give a good clue to how different the protocols were. Specifically: SSLv2 wa
by ekr____ 1y ago
The situation is additionally confused by the fact that the version numbers do not give a good clue to how different the protocols were. Specifically:
SSLv2 was the first widely deployed version of SSL, but as this post indicates, had a number of issues.
SSLv3 is a more or less completely new protocol
TLS 1.0 is much like SSLv3 but with some small revisions made during the IETF standardization process.
TLS 1.1 is a really minor revision to TLS 1.0 to address some issues with the way block ciphers were used.
TLS 1.2 is a moderately sized revision to TLS 1.1 to adjust to advances in cryptography, specifically adding support for newer hashes in response to weaknesses in MD5 and SHA-1 and adding support for AEAD cipher suites such as AES-GCM.
TLS 1.3 is mostly a new protocol though it reuses some pieces of TLS 1.2 and before.
Each of these protocols has been designed so that you could automatically negotiate versions, thus allowing for clients and servers to independently upgrade without loss of connectivity.
- cortesoft 1y ago> Each of these protocols has been designed so that you could automatically negotiate versions, thus allowing for clients and servers to independently upgrade without loss of connectivity. And ensuring decades of various downgrade attacks
- mcpherrinm 1y agoThe downgrade attacks on TLS are only really present in the case of client behaviour where, on failing to achieve one version, they retry a new connection without it. This was necessary to bypass various broken server side implementations, and broken middleboxes, but wasn’t necessarily a flaw in TLS itself. But from the learnings of this issue preventing 1.2 deployment, TLS 1.3 goes out of its way to look very similar on the wire to 1.2
- ekr____ 1y agoMoreover, there's not really much in the way of choices here. If you don't have this kind of automatic version negotiation then it's essentially impossible to deploy a new version.
- Dylan16807 1y agoDepends on what you mean by "this kind" because you want a way to detect attacker-forced downgrades and that used to be missing.
- pcthrowaway 1y agoYou could deploy a new version, you'd just have older clients unable to connect to servers implementing the newer versions. It wouldn't have been insane to rename https to httpt or something after TLS 1.2 and screw backwards compatibility (yes I realize the 's' stands for secure, not 'ssl', but httpt would have still worked as "HTTP with TLS")
- josephg 1y ago> It wouldn't have been insane to rename https to httpt or something after TLS 1.2 and screw backwards compatibility That would have been at least little bit insane, since then web links would be embedding the protocol version number. As a result, we'd need to keep old versions of TLS around indefinitely to make sure old URLs still work. I wish we could go the other way - and make http:// http:// implicitly use TLS when TLS is available. Having http://.../x http://.../x and https://.../x https://.../x be able to resolve to different resources was a huge mistake.
- cpach 1y agoRegarding your last paragraph: Isn’t that pretty much solved thanks to HSTS preload? A non-technical author of a small recipe blog might not know how to set it up, but a bank ought to have staff (and auditors) who takes care of stuff like that.
- account42 1y agoIt doesn't solve the problem of a client having to treat https:// https:// and http:// http:// URLs with the same string after the :// as distinct resources.
- frollogaston 1y agoIf a protocol is widely used wrongly, I consider it a flaw in the protocol. But overall, SSL standardization has gone decently well. I always bring it up as a good example to contrast with XMPP as a bad example.
- mcpherrinm 1y agoWell, my only real point is that it’s not the version negotiation in TLS that’s broken. It’s the workaround for intolerance of newer versions that had downgrade attacks. Fortunately that’s all behind us now, and transitioning from 1.2 to 1.3 is going much smoother than 1.0 to 1.2 went.
- tialaramex 1y agoOne of the big differences was in attitude. The TLS 1.3 anti-downgrade feature was not compatible with some popular middlebox products. Google told people too bad, either your vendor fixes it (most shipped free bug fixes for this issue, presumably "encouraged" by the resulting customer anger) or you can't run Chrome once this temporary fudge goes away in a year's time. Previously (in earlier protocol versions) nobody stood up to the crap middleboxes even though it's bad for all normal users.
- drob518 1y agoThe service providers were the worst offenders here because they wanted to be the MIM to be able to look at the data and “add value” to their networks some how. Moving to TLS 1.3 took a lot of that away from them and it was only Google’s market power that could break them.
- frollogaston 1y agoSimilar thing has been happening with email sender auth, with Gmail and other big providers enforcing things
- adgjlsfhk1 1y ago
- sjducb 1y agoMan in the middle interfering with TLS handshakes? The handshake is unencrypted so you can modify the messages to make it look like the server only supports broken ciphers. Then the man in the middle can read all of the encrypted data because it was badly encrypted. A surprising number of servers still support broken ciphers due to legacy uses or incompetence.
- kevincox 1y agoYou could encrypt the handshake that you recieved with the server's certificate and send it back. Then if it doesn't match what the server thought it sent it aborts the handshake. As long as the server's cert isn't broken this would detect a munged handshake, and if the server's cert is broken you have no root of trust to start the connection in the first place.
- dotancohen 1y agoThe fine man in the middle could still intercept that.
- sjducb 1y agoHow do you agree a protocol to encrypt the message to agree the protocol? This is the message that returns a list of supported ciphers and key exchange protocols. There’s no data in this first packet. Alice: I’d like to connect Bob: Sure here is a list of protocols we could use: You modify bob’s message so that bob only suggests insecure protocols. You might be proposing that Alice asks Trent for Bob’s public key … But that’s not how TLS works.
- lxgr 1y agoBob's list of supported protocols is an input into the (authenticated) final handshake message, and that authentication failing will prevent the connection from being considered successfully established. If the "negotiated" cipher suite is weak enough to allow real-time impersonation of Bob, though, pre-1.3 versions are still vulnerable; that's another reason not to keep insecure cipher suites around in a TLS config.
- matthewdgreen 1y agoThis isn't really accurate historically. TLS has both ciphersuite and version negotiation. Logjam (2015) [1] was a downgrade attack on the former that's now fixed, but is an extension of an attack that was first noticed way back in 1996 [2]. Similar problems occurred with the FREAK attack, though that was actually a client vulnerability. TLS 1.3 goes out of its way to fix all of this using a better negotiation mechanism, and by reducing agility. [1] https://en.wikipedia.org/wiki/Logjam_(computer_security) https://en.wikipedia.org/wiki/Logjam_(computer_security) [2] https://www.usenix.org/legacy/publications/library/proceedings/ec96/full_papers/wagner/wagner.pdf https://www.usenix.org/legacy/publications/library/proceedin...
- jackgavigan 1y agoIt also enabled cipher strength "step up". Back during the '90s and early 2000s (I'm not sure when it stopped, tbh), the US government restricted the export of strong cryptography, with certain exceptions (e.g. for financial services). If you fell under one of those exceptions, you could get a special certificate for your website (from, e.g. Verisign) that allowed the webserver to "step up" the encryption negotiation with the browser to stronger algorithms and/or key lengths.
- 1over137 1y agoWell, at least they were not just versioned by year number. ;)
- marcosdumay 1y agoIt would still be better than changing the name for no reason and resetting the version number.
- nextgens 1y agoTLS1.0 introduced modularity via the concept of "extensions". It's everything but a minor evolution of the protocol. One of the many things it brought is session tickets, enabling server-side session resumption without requiring servers to keep synced-up state. Another is Server Name Indication, enabling servers to use more than one certificate.
- ekr____ 1y agoFWIW, these aren't actually in TLS 1.0. Extensions (including SNI) are in later spec but introduces in RFC 3546 (https://www.rfc-editor.org/rfc/rfc3546 https://www.rfc-editor.org/rfc/rfc3546). Session tickets are in RFC 4507. What TLS 1.0 did was to leave the door open for extensions by allowing the ClientHello to be longer than what was specified. See https://www.rfc-editor.org/rfc/rfc2246.html#section-7.4.1.2 https://www.rfc-editor.org/rfc/rfc2246.html#section-7.4.1.2 (scroll to "Forward Compatibility Note")
- da_chicken 1y agoThey still should have just called it TLS v4.0 instead of v1.0. I'm halfway convinced that they have made subsequent versions v1.1, v1.2, and v1.3 in an outrageously stubborn refusal to admit that they were objectively incorrect to reset the version number.
- ekr____ 1y agoAs I noted below, there was real discussion around the version number for TLS 1.3. I don't recall any such discussion for 1.1 and 1.2.