9 ms·

TLS 1.3 approved

441 points by Shoothe 9y ago

namelost 9y ago
Does someone know what the differences are between the final version and the draft that Chrome and Firefox enabled in Feb 2017? How much did they have to change for the middleboxes?
- cesarb 9y ago
  The final version is going to be basically the last draft (draft-ietf-tls-tls13-28) with a few editorial changes. There's a changelog in the draft: https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-1.2 https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-... The question is just which draft Chrome and Firefox were using back then. The changes for the middleboxes were according to the changelog in draft-22, and IIRC consisted basically in adding back a few unnecessary fields, and allowing an useless handshake message (which is ignored by the receiver). The main trick was IIRC to make all TLS 1.3 connections (resume or not) appear identical to a TLS 1.2 resume connection. A more detailed history of all changes to the spec can be found at its git repository: https://github.com/tlswg/tls13-spec/ https://github.com/tlswg/tls13-spec/
CodeMichael 9y ago
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.
- agl 9y ago
  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 implemented TLS 1.2 correctly, which some didn't.)
  - CodeMichael 9y ago
    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.
    - agl 9y ago
      > 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(+). (+) as much as it did with TLS 1.2, anyway.
  - Asdfbla 9y ago
    Did banks and other network operators who require monitoring their traffic just deem the MITM proxies too expensive or complex, or what was the reason for their protest?
    - cesarb 9y ago
      The main complaint seems to be that the proxy can no longer use the Triple Handshake attack to inspect only part of the connection and pass the rest through, it's instead forced to do a full MITM all the time: https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00 https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00
      - bscphil 9y ago
        Except they'll just start checking SNI instead to see what sites you're browsing. Getting rid of triple handshakes is good from a theoretical perspective, but it does nothing at all to increase your privacy against middle-boxes.
        cesarb 9y ago
        With SNI, they can't easily see whether you're looking at https://en.wikipedia.org/wiki/Cat https://en.wikipedia.org/wiki/Cat or at https://en.wikipedia.org/wiki/Pornography https://en.wikipedia.org/wiki/Pornography (just looking at the size is not enough; Wikipedia has millions of pages, thousands of then are changed every day, it has a variable-sized HTML comment, and the HTML size also changes when you're logged in), while with the triple handshake attack, they can see the full HTTP request and response headers, while avoiding most of the cost of being "in the middle" during the actual content transfer.
- iluxonchik 9y ago
  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. [1] https://tools.ietf.org/html/draft-ietf-tls-tls13-28#appendix-C.5 https://tools.ietf.org/html/draft-ietf-tls-tls13-28#appendix...
- arghwhat 9y ago
  Yes and no. Passive eavesdropping where the eavesdroppers has been given the servers' RSA keys no longer works, but that's about it. This was mainly something that banks did for very, very defective reasons. Other types of MiTM still work, such as an active MiTM through a malicious root certificate.
_wmd 9y ago
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 include: - Duplication of actions which cause side effects (e.g., purchasing an item or transferring money) to be duplicated, thus harming the site or the user. - Attackers can store and replay 0-RTT messages in order to re-order them with respect to other messages (e.g., moving a delete to after a create). - Exploiting cache timing behavior to discover the content of 0-RTT messages by replaying a 0-RTT message to a different cache node and then using a separate connection to measure request latency, to see if the two requests address the same resource. Ultimately, servers have the responsibility to protect themselves against attacks employing 0-RTT data replication. The mechanisms described in Section 8 are intended to prevent replay at the TLS layer but do not provide complete protection against receiving multiple copies of client data. It seems practically guaranteed a lot of devs will enable it without understanding the ramifications.. I hope embeddings like Nginx add a nice configuration interface like "enable_0rtt YES_I_UNDERSTAND_THIS_MIGHT_BE_INSANE;" or similar. Meanwhile I wonder if concentrators like Cloudflare will ever be able to support it, without knowing lots more about the apps they are fronting I guess e.g. Nginx could also insert an artificial header to mark requests received as 0-RTT, and frameworks like Django could use that header to require views be explicitly marked with a decorator to indicate support, or something like that
- mtgx 9y ago
  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 do it the banks and middlebox guys will just stick to TLS 1.2 or whatever? 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? Some poor performance tracking tracking scripts add 800 ms on their own.
rurban 9y ago
So it looks like that this seasons NSA/GHCQ backdoor is 0-RTT, and will be implemented into the commercial variants, whilst the open source variants will turn it off by default. Or use it like Cloudflare, in HTTPS without GET params only.
- azinman2 9y ago
  You make it sound like NSA/GCHQ somehow secretly put in a weakness into a IETF standard that’s gone through many public drafts...
  - thriftwy 9y ago
    That's roughly the line of their job, as we have all learned the hard way a few years back.
    - azinman2 9y ago
      So they’re hardly the only intelligence agencies in the world, so I don’t get why they’re specifically being pointed out unless you have some direct evidence. As far as I’m aware, 0rtt started with Google’s QUIC. It’s since gone through a ton of academic and industry debate, particularly at the IETF level. It’s something optional to turn on, comes with notes on limitations and weaknesses, and major supporting vendors like Cloudflare have giant blog posts about how it can be used in only limited ways. How is this an intelligence crafted backdoor?
    - tialaramex 9y ago
      If you were going to point fingers (probably unfairly) at people whose agenda seems compatible with agencies that don't like BCP#188 (the IETF policy document "Pervasive Monitoring Is an Attack") then the best candidates would be those asking for the "transparency" features, some of which claimed at different times to represent data centre operators, financial institutions, and IoT manufacturers. None of that made it into this draft, indeed the Monday meeting (this link is about the Wednesday meeting although practically speaking I think this was a done deal by Monday) of the TLS working group at IETF 101 basically killed all those plans, at least in so far as they impact TLS 1.3 itself. The IETF operates on "rough consensus" and there wasn't any way forward on "transparency" (aka snooping) that had consensus, so it was either publish this or stall forever.
lappet 9y ago
Anyone know what TLS 1.3 offers (or fixes) that TLS 1.2 does not?
- Choco31415 9y ago
  WolfSSL has a short write up on the changes: https://www.wolfssl.com/differences-between-tls-1-2-and-tls-1-3/ https://www.wolfssl.com/differences-between-tls-1-2-and-tls-...
- alwillis 9y ago
  Worth watching: "Deploying TLS 1.3: the great, the good and the bad”—https://www.youtube.com/watch?v=0opakLwtPWk https://www.youtube.com/watch?v=0opakLwtPWk
tedwilliamshock 9y ago
Related and ongoing ; https://www.crowdrise.com/o/en/campaign/ostif1 https://www.crowdrise.com/o/en/campaign/ostif1 Part of the DuckDuckGo $500,000 Privacy Challenge 2018 ; https://www.crowdrise.com/duckduckgoprivacychallenge https://www.crowdrise.com/duckduckgoprivacychallenge
edwinyzh 9y ago
I have a dumb question - Can existing clients with the old TLS versions connect to a server with TLS 1.3?
- mcpherrinm 9y ago
  A TLS server and client can both support multiple versions. Clients which don't support 1.3 will continue to use 1.2 (or 1.1 or 1.0, if the server still supports them)
ohnoesjmr 9y ago
SNI is still in plain text :( They could just hash the SNI and do matching based on hashes.
- cesarb 9y ago
  That gains nothing, since the attacker can simple connect to the service, replaying your hash, and see which certificate comes back. Take a look at https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-02 https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-02 which on its section 2 has a long list of requirements a solution should meet; hashing the SNI fails at least the first two (Mitigate Replay Attacks and Avoid Widely Shared Secrets).
  - xorcist 9y ago
    There's also a limited amount of domains registered, so even if you did something to prevent hash replays you could just try them all and see which matches.
swherdman 9y ago
No banking backdoor either, Sanity won out! See below if you haven't come across this https://www.thesslstore.com/blog/tls-1-3-banking-industry-working-undermine-encryption/ https://www.thesslstore.com/blog/tls-1-3-banking-industry-wo... https://tools.ietf.org/html/draft-rhrd-tls-tls13-visibility-00 https://tools.ietf.org/html/draft-rhrd-tls-tls13-visibility-...

441 points by Shoothe 9y ago

Does someone know what the differences are between the final version and the draft that Chrome and Firefox enabled in Feb 2017? How much did they have to change for the middleboxes?

cesarb 9y ago
The final version is going to be basically the last draft (draft-ietf-tls-tls13-28) with a few editorial changes. There's a changelog in the draft: https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-1.2 https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-... The question is just which draft Chrome and Firefox were using back then. The changes for the middleboxes were according to the changelog in draft-22, and IIRC consisted basically in adding back a few unnecessary fields, and allowing an useless handshake message (which is ignored by the receiver). The main trick was IIRC to make all TLS 1.3 connections (resume or not) appear identical to a TLS 1.2 resume connection. A more detailed history of all changes to the spec can be found at its git repository: https://github.com/tlswg/tls13-spec/ https://github.com/tlswg/tls13-spec/

CodeMichael 9y ago

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.

agl 9y ago
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 implemented TLS 1.2 correctly, which some didn't.)
- CodeMichael 9y ago
  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.
  - agl 9y ago
    > 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(+). (+) as much as it did with TLS 1.2, anyway.
- Asdfbla 9y ago
  Did banks and other network operators who require monitoring their traffic just deem the MITM proxies too expensive or complex, or what was the reason for their protest?
  - cesarb 9y ago
    The main complaint seems to be that the proxy can no longer use the Triple Handshake attack to inspect only part of the connection and pass the rest through, it's instead forced to do a full MITM all the time: https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00 https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00
    - bscphil 9y ago
      Except they'll just start checking SNI instead to see what sites you're browsing. Getting rid of triple handshakes is good from a theoretical perspective, but it does nothing at all to increase your privacy against middle-boxes.
      - cesarb 9y ago
        With SNI, they can't easily see whether you're looking at https://en.wikipedia.org/wiki/Cat https://en.wikipedia.org/wiki/Cat or at https://en.wikipedia.org/wiki/Pornography https://en.wikipedia.org/wiki/Pornography (just looking at the size is not enough; Wikipedia has millions of pages, thousands of then are changed every day, it has a variable-sized HTML comment, and the HTML size also changes when you're logged in), while with the triple handshake attack, they can see the full HTTP request and response headers, while avoiding most of the cost of being "in the middle" during the actual content transfer.
iluxonchik 9y ago
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. [1] https://tools.ietf.org/html/draft-ietf-tls-tls13-28#appendix-C.5 https://tools.ietf.org/html/draft-ietf-tls-tls13-28#appendix...
arghwhat 9y ago
Yes and no. Passive eavesdropping where the eavesdroppers has been given the servers' RSA keys no longer works, but that's about it. This was mainly something that banks did for very, very defective reasons. Other types of MiTM still work, such as an active MiTM through a malicious root certificate.

_wmd 9y ago

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 include: - Duplication of actions which cause side effects (e.g., purchasing an item or transferring money) to be duplicated, thus harming the site or the user. - Attackers can store and replay 0-RTT messages in order to re-order them with respect to other messages (e.g., moving a delete to after a create). - Exploiting cache timing behavior to discover the content of 0-RTT messages by replaying a 0-RTT message to a different cache node and then using a separate connection to measure request latency, to see if the two requests address the same resource. Ultimately, servers have the responsibility to protect themselves against attacks employing 0-RTT data replication. The mechanisms described in Section 8 are intended to prevent replay at the TLS layer but do not provide complete protection against receiving multiple copies of client data. It seems practically guaranteed a lot of devs will enable it without understanding the ramifications.. I hope embeddings like Nginx add a nice configuration interface like "enable_0rtt YES_I_UNDERSTAND_THIS_MIGHT_BE_INSANE;" or similar. Meanwhile I wonder if concentrators like Cloudflare will ever be able to support it, without knowing lots more about the apps they are fronting I guess e.g. Nginx could also insert an artificial header to mark requests received as 0-RTT, and frameworks like Django could use that header to require views be explicitly marked with a decorator to indicate support, or something like that

mtgx 9y ago
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 do it the banks and middlebox guys will just stick to TLS 1.2 or whatever? 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? Some poor performance tracking tracking scripts add 800 ms on their own.

rurban 9y ago

So it looks like that this seasons NSA/GHCQ backdoor is 0-RTT, and will be implemented into the commercial variants, whilst the open source variants will turn it off by default. Or use it like Cloudflare, in HTTPS without GET params only.

azinman2 9y ago
You make it sound like NSA/GCHQ somehow secretly put in a weakness into a IETF standard that’s gone through many public drafts...
- thriftwy 9y ago
  That's roughly the line of their job, as we have all learned the hard way a few years back.
  - azinman2 9y ago
    So they’re hardly the only intelligence agencies in the world, so I don’t get why they’re specifically being pointed out unless you have some direct evidence. As far as I’m aware, 0rtt started with Google’s QUIC. It’s since gone through a ton of academic and industry debate, particularly at the IETF level. It’s something optional to turn on, comes with notes on limitations and weaknesses, and major supporting vendors like Cloudflare have giant blog posts about how it can be used in only limited ways. How is this an intelligence crafted backdoor?
  - tialaramex 9y ago
    If you were going to point fingers (probably unfairly) at people whose agenda seems compatible with agencies that don't like BCP#188 (the IETF policy document "Pervasive Monitoring Is an Attack") then the best candidates would be those asking for the "transparency" features, some of which claimed at different times to represent data centre operators, financial institutions, and IoT manufacturers. None of that made it into this draft, indeed the Monday meeting (this link is about the Wednesday meeting although practically speaking I think this was a done deal by Monday) of the TLS working group at IETF 101 basically killed all those plans, at least in so far as they impact TLS 1.3 itself. The IETF operates on "rough consensus" and there wasn't any way forward on "transparency" (aka snooping) that had consensus, so it was either publish this or stall forever.

lappet 9y ago

Anyone know what TLS 1.3 offers (or fixes) that TLS 1.2 does not?

Choco31415 9y ago
WolfSSL has a short write up on the changes: https://www.wolfssl.com/differences-between-tls-1-2-and-tls-1-3/ https://www.wolfssl.com/differences-between-tls-1-2-and-tls-...
alwillis 9y ago
Worth watching: "Deploying TLS 1.3: the great, the good and the bad”—https://www.youtube.com/watch?v=0opakLwtPWk https://www.youtube.com/watch?v=0opakLwtPWk

tedwilliamshock 9y ago

Related and ongoing ; https://www.crowdrise.com/o/en/campaign/ostif1 https://www.crowdrise.com/o/en/campaign/ostif1 Part of the DuckDuckGo $500,000 Privacy Challenge 2018 ; https://www.crowdrise.com/duckduckgoprivacychallenge https://www.crowdrise.com/duckduckgoprivacychallenge

edwinyzh 9y ago

I have a dumb question - Can existing clients with the old TLS versions connect to a server with TLS 1.3?

mcpherrinm 9y ago
A TLS server and client can both support multiple versions. Clients which don't support 1.3 will continue to use 1.2 (or 1.1 or 1.0, if the server still supports them)

ohnoesjmr 9y ago

SNI is still in plain text :( They could just hash the SNI and do matching based on hashes.

cesarb 9y ago
That gains nothing, since the attacker can simple connect to the service, replaying your hash, and see which certificate comes back. Take a look at https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-02 https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-02 which on its section 2 has a long list of requirements a solution should meet; hashing the SNI fails at least the first two (Mitigate Replay Attacks and Avoid Widely Shared Secrets).
- xorcist 9y ago
  There's also a limited amount of domains registered, so even if you did something to prevent hash replays you could just try them all and see which matches.

swherdman 9y ago

No banking backdoor either, Sanity won out! See below if you haven't come across this https://www.thesslstore.com/blog/tls-1-3-banking-industry-working-undermine-encryption/ https://www.thesslstore.com/blog/tls-1-3-banking-industry-wo... https://tools.ietf.org/html/draft-rhrd-tls-tls13-visibility-00 https://tools.ietf.org/html/draft-rhrd-tls-tls13-visibility-...