7 ms·

The Transport Layer Security (TLS) Protocol Version 1.3

255 points by dochtman 8y ago

vladd 8y ago
New features introduced in TLS 1.3 include: * smaller latency (0-RTT: zero round-trips support). * removes insecure encryption primitives (SHA1, MD5, RC4). * elliptic curve support. * downgrade protection. Some interesting reads: https://blog.cloudflare.com/introducing-0-rtt/ https://blog.cloudflare.com/introducing-0-rtt/ and https://www.cloudflare.com/learning-resources/tls-1-3/ https://www.cloudflare.com/learning-resources/tls-1-3/ .
- deleted 8y ago
  [deleted]
- bcaa7f3a8bbc 8y ago
  * removes insecure encryption primitives (SHA1, MD5, RC4). => also removes all key exchange algos without forward secrecy. * elliptic curve support. => and new X25519/Ed25519 elliptic curve support. I think most security people are aware of these features for a while. The final accepted standardization is what matters now, after 28 drafts, and the epic success of overcoming the middlebox disaster...
  - snvzz 8y ago
    >and the epic success of overcoming the middlebox disaster... This is one of these cases in which it would be (have been) better to just break them. It isn't TLS's job to explicitly support evil. These middleboxes are cancer. There's no way to morally defend their presence. Breaking them (and thus effectively forcing them out of the way) would have been the better approach.
    - jaaames 8y ago
      Can you expand on what middleboxes are?
      - SamWhited 8y ago
        Lots of random routers on the internet (eg. at your ISP, at their transport partners, etc.) were doing all sorts of packet inspection, parsing the plain parts of TLS messages, etc. and then dropping things they thought were invalid (including things as simple as seeing a version number they didn't recognize and dropping the connection). They made TLS 1.3 look sort of like TLS 1.2 resumption which made the protocol much less elegant, but made crappy boxes that had made bad assumptions about what the protocol should look like happy.
        vbezhenar 8y ago
        So currently it's no longer true and TLS 1.3 looks like TLS 1.3, not like TLS 1.2 wrapped something inside? It's good, it was very inelegant.
        bcaa7f3a8bbc 8y ago
        The end result is a hack. The on-wire format of TLSv1.3 is tweaked, to make the TLS 1.3 handshake resemble TLS 1.2 session resumption requests, which is just enough to make the connection being able to pass broken middleboxes.
      - tolien 8y ago
        https://en.wikipedia.org/wiki/Middlebox https://en.wikipedia.org/wiki/Middlebox The nature of TLS is that nobody in the middle is supposed to be able to read what's encrypted, and that either end can detect if traffic they receive has been modified in transit. Of course this is incompatible with corporate (especially financial) networks where employers have legal/compliance/noseyness reasons to want to make sure their employees aren't doing things they shouldn't (sending corporate secrets to the NYT, having their corporate knowledge siphoned out by malware, spending all their time on Facebook etc.), and repressive regimes (where, for example, Erdogan wants to know if you're a member of the Gulen movement) - Bluecoat and Cisco, for example, do a lot of business in the Middle East and China. They'll typically act as a man in the middle for TLS traffic, re-encrypting traffic using either a compliant root CA or a corporate CA that all employee machines have been made to trust. The nature of Enterprise Software is that these devices will have poor, incomplete or outdated implementations of TLS with the result that, for example, a lot of them didn't know what to do with draft TLS v1.3 traffic and just dropped it on the floor as invalid.
    - willglynn 8y ago
      BRB, telling the compliance team that SSL inspection is morally indefensible. I'm sure they'll be happy to turn it off.
      - geofft 8y ago
        "We should continue doing immoral things because there's no way we'll ever convince corporate and governmental power to let us stop doing immoral things" is ... probably not an incorrect argument, but a very sad one.
        tptacek 8y ago
        SSL inspection isn't immoral. That's an uncharacteristically silly argument.
        geofft 8y ago
        It's a tool, but it is (in a small way) a normalization of mass surveillance. (I guess I should clarify that my argument is not "SSL inspection is bad and therefore TLS 1.3 is bad" - my employer monitors all my SSL traffic from work-owned machines, and could do so very easily with a browser extension or something instead of SSL inspection if the protocol somehow made middleboxes difficult. The proxies are currently designed to permit a few websites through without interception, which is the specific thing that there was debate about doing, but I don't think there's any real reason why my employer wouldn't just monitor everything if they had to. So I don't think there's anything the TLS spec could have done to make my employer more or less likely to monitor traffic, and I don't think that this affects the argument about whether the monitoring itself is immoral.)
        unethical_ban 8y ago
        A company monitoring its assets for proper use and the SECURITY and PRIVACY of its customers is not immoral. A browser extension would not do nearly what a proper web proxy can do. I am a critic of the surveillance state and a donating member of the EFF, but web proxies are not evil in themselves, anymore than a camera is evil because it can be used to build a panopticon, or cookies are evil because they can be used for cross site tracking.
    - bcaa7f3a8bbc 8y ago
      I personally believe stop breaking these middleboxes is a necessary evil/compromise to make TLSv1.3 to be universally accepted. The net gain is a huge positive. > Breaking them (and thus effectively forcing them out of the way) would have been the better approach. This is exactly what the security people are going to do after TLSv1.3 is introduced. Google Chrome is going to implement the so-called GREASE protocol (https://tools.ietf.org/html/draft-ietf-tls-grease-01 https://tools.ietf.org/html/draft-ietf-tls-grease-01), which actively tries to negotiate a connection with random, non-existent, but standard-compliant values in various fields of the protocol, to actively break the (future) broken middleboxes early on. Revenge time.
      - dwheeler 8y ago
        I think GREASE has an excellent chance of long-term success, and if it works, other protocol implementations should start doing the same thing. Actively requiring implementations to support future compatibility looks like an excellent plan. In case people are curious what TLS 1.3 did to support broken middleboxes, a lot of information is in "D.4. Middlebox Compatibility Mode". Here's the text: > Field measurements [Ben17a] [Ben17b] [Res17a] [Res17b] have found that a significant number of middleboxes misbehave when a TLS client/server pair negotiates TLS 1.3. Implementations can increase the chance of making connections through those middleboxes by making the TLS 1.3 handshake look more like a TLS 1.2 handshake... I think working around it in the short term (so that TLS 1.3 can start improving our protections NOW), and separately getting middleboxes to upgrade over a longer period of time, is a good plan.
  - mikorym 8y ago
    I would like to ask two basic questions. 1. What do you mean that they overcome it? 2. Are middle boxes still possible, and how would these be implemented? I assume intra-network, by signing local certificates one can for instance do this for company employees. But if I access a website over an encrypted connection, is there any way that it is routed through a middlebox without being able to know?
    - ethbro 8y ago
      One more basic question -- what are current middleboxes actually doing with their inspection? Given that you'd be insane not to run application-level connection encryption for malware communication, and I don't see any fundamental reason you couldn't duplicate a TLS-esque handshake at a higher level (reimplementing cert chaining, e.g. via web of trust), what's there for the boxes to inspect that's not already encrypted? Setup negotiation? Or do so few legitimate applications encypt on top of TLS that the traffic stands out?
      - bcaa7f3a8bbc 8y ago
        Just read SamWhited's comment. Some middleboxes act as Man-in-the-Middle and inspect the plaintext, this is how those middleboxes were implemented in the past, and still, how they are going to be implemented in the future. The middlebox disaster I mentioned is not necessarily about those boxes, but other boxes which do not decrypt traffic, but instead try to inspect visible fields and metadata in packets and protocols. One basic example is inspecting the SNI field to know the domain name you are visiting. Many of these middleboxes are poorly implemented with hardcoded assumptions (but compatible with existing implementations), not fully in compliance with the standard. They also like to reject or drop the connection if they cannot successfully parse the protocol as expected. After TLSv1.3 is released, guess what? Their assumptions don't work anymore, and they start rejecting every TLSv1.3 connection. The final solution is some tweaks of the wire format, to make it seems to be TLSv1.2 in middleboxes' perspective. In fact, this is not really a new problem - many firewalls are designed to reject things they don't understand, because it was believed to be the defense-in-depth. This was the problem that almost killed TCP ECN 20 years ago, and officially condemned by the IETF (https://tools.ietf.org/html/rfc3360 https://tools.ietf.org/html/rfc3360), but history repeats... This blogpost from CloudFlare gives an extensive introduction to this issue: https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet
- hannob 8y ago
  > * elliptic curve support. > * downgrade protection. These are not new. Particularly the second is a complicated story. TLS always had downgrade protection, but at some point browsers had to decide to break downgrade protection, because there were too many shitty devices out there that didn't implement the TLS handshake correctly.
  - tialaramex 8y ago
    TLS 1.3 downgrade protection is cleverer than previous approaches because the downgrade marker is scribbled into a field used for connection setup whenever a TLS 1.3 server ends up not doing TLS 1.3. If an attacker erases the marker, the connection fails. If they don't erase it the downgrade is reported to the client. If the client doesn't know TLS 1.3 the marker means nothing to it.
- ndesaulniers 8y ago
  Without a round trip, we must be reusing keys right? So no more ephemeral keys? I know it's optional, but I wonder which will be the default for most off the shelf https severs folks use?
  - tialaramex 8y ago
    1. Yes 0RTT uses a key agreed during a previous TLS session 2. The intent is that correct servers will never do 0RTT unless there's some explicit buy-in from the application. Allowing 0RTT unconditionally is almost invariably going to end badly. A static web site (all idempotent GETs) ought to be OK, and making it safe for toy (single server, transactional) apps isn't so hard, but 0RTT safely for serious stuff is hard, most people just shouldn't.
pas 8y ago
Any news on encrypted SNI? ( eg https://tools.ietf.org/html/draft-rescorla-tls-esni-00 https://tools.ietf.org/html/draft-rescorla-tls-esni-00 [ https://datatracker.ietf.org/doc/draft-rescorla-tls-esni/history/ https://datatracker.ietf.org/doc/draft-rescorla-tls-esni/his... ] )
- hacknat 8y ago
  Encrypted SNI probably can’t make this version, as it requires a fair bit of new protocol infrastructure to support. The handshake would have to start with a generalized untrusted assymetric exchange exchange to transfer the SNI field then “upgrade” the connection to be trusted and then retroactively tell the client what the initial “untrusted” key was so that the client can confirm it didn’t suffer a man in the middle attack during the SNI transfer phase. All of this is possible and should be done, but I doubt it will make protocol 3.
  - rocqua 8y ago
    As far as I know, the SNI field is only used by the server to select what cert to use and site to serve. So if someone were to MitM the SNI exchange, presuming they don't have a valid cert, they could only cause the client to receive a different site (if served with a cert valid for both sites). We can presume the MitM doesn't have a valid cert, otherwise they could fully MitM the connection. To ensure your keys are indeed set up by the trusted party, you need to get that signed by the server cert, but that is already part of the TLS protocol. It seems I'm missing something.
    - stanleydrew 8y ago
      The danger is not that unencrypted SNI exposes clients to additional MitM attacks. It just exposes the client's intended domain to everyone on the connection route. It's an information leak, that's all.
      - rocqua 8y ago
        I think OP I replied to stated that encrypting SNI requires MitM mitigations.
tialaramex 8y ago
Notably the RFC by making this a standard rather than merely the draft we all expect to become standard (which had been solid for months) removes all the overrides in the drafts that switch off e.g. downgrade detection. These overrides were needed in drafts so as to prevent craziness where a draft changes the protocol in an incompatible way and the anti-downgrade forbids using TLS 1.2 so then you're screwed. So even though popular clients, services and libraries had the last draft for months this will, as I understand it, require a patch to do actual bona fide TLS 1.3
- ctz 8y ago
  Yep. https://rustls.jbp.io/ https://rustls.jbp.io/ now supports final TLS1.3 but you'll be hard-pressed to find a library which negotiates TLS1.3 with it. Give it a few weeks.
anonymousiam 8y ago
Attended this talk yesterday: https://www.defcon.org/html/defcon-26/dc-26-speakers.html#Garc%C3%ADa https://www.defcon.org/html/defcon-26/dc-26-speakers.html#Ga... TLS 1.3 is the new secure communication protocol that should be already with us. One of its new features is 0-RTT (Zero Round Trip Time Resumption) that could potentially allow replay attacks. This is a known issue acknowledged by the TLS 1.3 specification, as the protocol does not provide replay protections for 0-RTT data, but proposed countermeasures that would need to be implemented on other layers, not at the protocol level. Therefore, the applications deployed with TLS 1.3 support could end up exposed to replay attacks depending on the implementation of those protections. This talk will describe the technical details regarding the TLS 1.3 0-RTT feature and its associated risks. It will include Proof of Concepts (PoC) showing real-world replay attacks against TLS 1.3 libraries and browsers. Finally, potential solutions or mitigation controls would be discussed that will help to prevent those attacks when deploying software using a library with TLS 1.3 support.
westurner 8y ago
Is PKI still an optional feature of TLS? Can one still use self-signed x.509 certificates and have key-signing parties?

255 points by dochtman 8y ago

New features introduced in TLS 1.3 include: * smaller latency (0-RTT: zero round-trips support). * removes insecure encryption primitives (SHA1, MD5, RC4). * elliptic curve support. * downgrade protection. Some interesting reads: https://blog.cloudflare.com/introducing-0-rtt/ https://blog.cloudflare.com/introducing-0-rtt/ and https://www.cloudflare.com/learning-resources/tls-1-3/ https://www.cloudflare.com/learning-resources/tls-1-3/ .

deleted 8y ago
[deleted]
bcaa7f3a8bbc 8y ago
* removes insecure encryption primitives (SHA1, MD5, RC4). => also removes all key exchange algos without forward secrecy. * elliptic curve support. => and new X25519/Ed25519 elliptic curve support. I think most security people are aware of these features for a while. The final accepted standardization is what matters now, after 28 drafts, and the epic success of overcoming the middlebox disaster...
- snvzz 8y ago
  >and the epic success of overcoming the middlebox disaster... This is one of these cases in which it would be (have been) better to just break them. It isn't TLS's job to explicitly support evil. These middleboxes are cancer. There's no way to morally defend their presence. Breaking them (and thus effectively forcing them out of the way) would have been the better approach.
  - jaaames 8y ago
    Can you expand on what middleboxes are?
    - SamWhited 8y ago
      Lots of random routers on the internet (eg. at your ISP, at their transport partners, etc.) were doing all sorts of packet inspection, parsing the plain parts of TLS messages, etc. and then dropping things they thought were invalid (including things as simple as seeing a version number they didn't recognize and dropping the connection). They made TLS 1.3 look sort of like TLS 1.2 resumption which made the protocol much less elegant, but made crappy boxes that had made bad assumptions about what the protocol should look like happy.
      - vbezhenar 8y ago
        So currently it's no longer true and TLS 1.3 looks like TLS 1.3, not like TLS 1.2 wrapped something inside? It's good, it was very inelegant.
        bcaa7f3a8bbc 8y ago
        The end result is a hack. The on-wire format of TLSv1.3 is tweaked, to make the TLS 1.3 handshake resemble TLS 1.2 session resumption requests, which is just enough to make the connection being able to pass broken middleboxes.
    - tolien 8y ago
      https://en.wikipedia.org/wiki/Middlebox https://en.wikipedia.org/wiki/Middlebox The nature of TLS is that nobody in the middle is supposed to be able to read what's encrypted, and that either end can detect if traffic they receive has been modified in transit. Of course this is incompatible with corporate (especially financial) networks where employers have legal/compliance/noseyness reasons to want to make sure their employees aren't doing things they shouldn't (sending corporate secrets to the NYT, having their corporate knowledge siphoned out by malware, spending all their time on Facebook etc.), and repressive regimes (where, for example, Erdogan wants to know if you're a member of the Gulen movement) - Bluecoat and Cisco, for example, do a lot of business in the Middle East and China. They'll typically act as a man in the middle for TLS traffic, re-encrypting traffic using either a compliant root CA or a corporate CA that all employee machines have been made to trust. The nature of Enterprise Software is that these devices will have poor, incomplete or outdated implementations of TLS with the result that, for example, a lot of them didn't know what to do with draft TLS v1.3 traffic and just dropped it on the floor as invalid.
  - willglynn 8y ago
    BRB, telling the compliance team that SSL inspection is morally indefensible. I'm sure they'll be happy to turn it off.
    - geofft 8y ago
      "We should continue doing immoral things because there's no way we'll ever convince corporate and governmental power to let us stop doing immoral things" is ... probably not an incorrect argument, but a very sad one.
      - tptacek 8y ago
        SSL inspection isn't immoral. That's an uncharacteristically silly argument.
        geofft 8y ago
        It's a tool, but it is (in a small way) a normalization of mass surveillance. (I guess I should clarify that my argument is not "SSL inspection is bad and therefore TLS 1.3 is bad" - my employer monitors all my SSL traffic from work-owned machines, and could do so very easily with a browser extension or something instead of SSL inspection if the protocol somehow made middleboxes difficult. The proxies are currently designed to permit a few websites through without interception, which is the specific thing that there was debate about doing, but I don't think there's any real reason why my employer wouldn't just monitor everything if they had to. So I don't think there's anything the TLS spec could have done to make my employer more or less likely to monitor traffic, and I don't think that this affects the argument about whether the monitoring itself is immoral.)
        unethical_ban 8y ago
        A company monitoring its assets for proper use and the SECURITY and PRIVACY of its customers is not immoral. A browser extension would not do nearly what a proper web proxy can do. I am a critic of the surveillance state and a donating member of the EFF, but web proxies are not evil in themselves, anymore than a camera is evil because it can be used to build a panopticon, or cookies are evil because they can be used for cross site tracking.
  - bcaa7f3a8bbc 8y ago
    I personally believe stop breaking these middleboxes is a necessary evil/compromise to make TLSv1.3 to be universally accepted. The net gain is a huge positive. > Breaking them (and thus effectively forcing them out of the way) would have been the better approach. This is exactly what the security people are going to do after TLSv1.3 is introduced. Google Chrome is going to implement the so-called GREASE protocol (https://tools.ietf.org/html/draft-ietf-tls-grease-01 https://tools.ietf.org/html/draft-ietf-tls-grease-01), which actively tries to negotiate a connection with random, non-existent, but standard-compliant values in various fields of the protocol, to actively break the (future) broken middleboxes early on. Revenge time.
    - dwheeler 8y ago
      I think GREASE has an excellent chance of long-term success, and if it works, other protocol implementations should start doing the same thing. Actively requiring implementations to support future compatibility looks like an excellent plan. In case people are curious what TLS 1.3 did to support broken middleboxes, a lot of information is in "D.4. Middlebox Compatibility Mode". Here's the text: > Field measurements [Ben17a] [Ben17b] [Res17a] [Res17b] have found that a significant number of middleboxes misbehave when a TLS client/server pair negotiates TLS 1.3. Implementations can increase the chance of making connections through those middleboxes by making the TLS 1.3 handshake look more like a TLS 1.2 handshake... I think working around it in the short term (so that TLS 1.3 can start improving our protections NOW), and separately getting middleboxes to upgrade over a longer period of time, is a good plan.
- mikorym 8y ago
  I would like to ask two basic questions. 1. What do you mean that they overcome it? 2. Are middle boxes still possible, and how would these be implemented? I assume intra-network, by signing local certificates one can for instance do this for company employees. But if I access a website over an encrypted connection, is there any way that it is routed through a middlebox without being able to know?
  - ethbro 8y ago
    One more basic question -- what are current middleboxes actually doing with their inspection? Given that you'd be insane not to run application-level connection encryption for malware communication, and I don't see any fundamental reason you couldn't duplicate a TLS-esque handshake at a higher level (reimplementing cert chaining, e.g. via web of trust), what's there for the boxes to inspect that's not already encrypted? Setup negotiation? Or do so few legitimate applications encypt on top of TLS that the traffic stands out?
    - bcaa7f3a8bbc 8y ago
      Just read SamWhited's comment. Some middleboxes act as Man-in-the-Middle and inspect the plaintext, this is how those middleboxes were implemented in the past, and still, how they are going to be implemented in the future. The middlebox disaster I mentioned is not necessarily about those boxes, but other boxes which do not decrypt traffic, but instead try to inspect visible fields and metadata in packets and protocols. One basic example is inspecting the SNI field to know the domain name you are visiting. Many of these middleboxes are poorly implemented with hardcoded assumptions (but compatible with existing implementations), not fully in compliance with the standard. They also like to reject or drop the connection if they cannot successfully parse the protocol as expected. After TLSv1.3 is released, guess what? Their assumptions don't work anymore, and they start rejecting every TLSv1.3 connection. The final solution is some tweaks of the wire format, to make it seems to be TLSv1.2 in middleboxes' perspective. In fact, this is not really a new problem - many firewalls are designed to reject things they don't understand, because it was believed to be the defense-in-depth. This was the problem that almost killed TCP ECN 20 years ago, and officially condemned by the IETF (https://tools.ietf.org/html/rfc3360 https://tools.ietf.org/html/rfc3360), but history repeats... This blogpost from CloudFlare gives an extensive introduction to this issue: https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet
hannob 8y ago
> * elliptic curve support. > * downgrade protection. These are not new. Particularly the second is a complicated story. TLS always had downgrade protection, but at some point browsers had to decide to break downgrade protection, because there were too many shitty devices out there that didn't implement the TLS handshake correctly.
- tialaramex 8y ago
  TLS 1.3 downgrade protection is cleverer than previous approaches because the downgrade marker is scribbled into a field used for connection setup whenever a TLS 1.3 server ends up not doing TLS 1.3. If an attacker erases the marker, the connection fails. If they don't erase it the downgrade is reported to the client. If the client doesn't know TLS 1.3 the marker means nothing to it.
ndesaulniers 8y ago
Without a round trip, we must be reusing keys right? So no more ephemeral keys? I know it's optional, but I wonder which will be the default for most off the shelf https severs folks use?
- tialaramex 8y ago
  1. Yes 0RTT uses a key agreed during a previous TLS session 2. The intent is that correct servers will never do 0RTT unless there's some explicit buy-in from the application. Allowing 0RTT unconditionally is almost invariably going to end badly. A static web site (all idempotent GETs) ought to be OK, and making it safe for toy (single server, transactional) apps isn't so hard, but 0RTT safely for serious stuff is hard, most people just shouldn't.

pas 8y ago

Any news on encrypted SNI? ( eg https://tools.ietf.org/html/draft-rescorla-tls-esni-00 https://tools.ietf.org/html/draft-rescorla-tls-esni-00 [ https://datatracker.ietf.org/doc/draft-rescorla-tls-esni/history/ https://datatracker.ietf.org/doc/draft-rescorla-tls-esni/his... ] )

hacknat 8y ago
Encrypted SNI probably can’t make this version, as it requires a fair bit of new protocol infrastructure to support. The handshake would have to start with a generalized untrusted assymetric exchange exchange to transfer the SNI field then “upgrade” the connection to be trusted and then retroactively tell the client what the initial “untrusted” key was so that the client can confirm it didn’t suffer a man in the middle attack during the SNI transfer phase. All of this is possible and should be done, but I doubt it will make protocol 3.
- rocqua 8y ago
  As far as I know, the SNI field is only used by the server to select what cert to use and site to serve. So if someone were to MitM the SNI exchange, presuming they don't have a valid cert, they could only cause the client to receive a different site (if served with a cert valid for both sites). We can presume the MitM doesn't have a valid cert, otherwise they could fully MitM the connection. To ensure your keys are indeed set up by the trusted party, you need to get that signed by the server cert, but that is already part of the TLS protocol. It seems I'm missing something.
  - stanleydrew 8y ago
    The danger is not that unencrypted SNI exposes clients to additional MitM attacks. It just exposes the client's intended domain to everyone on the connection route. It's an information leak, that's all.
    - rocqua 8y ago
      I think OP I replied to stated that encrypting SNI requires MitM mitigations.

tialaramex 8y ago

Notably the RFC by making this a standard rather than merely the draft we all expect to become standard (which had been solid for months) removes all the overrides in the drafts that switch off e.g. downgrade detection. These overrides were needed in drafts so as to prevent craziness where a draft changes the protocol in an incompatible way and the anti-downgrade forbids using TLS 1.2 so then you're screwed. So even though popular clients, services and libraries had the last draft for months this will, as I understand it, require a patch to do actual bona fide TLS 1.3

ctz 8y ago
Yep. https://rustls.jbp.io/ https://rustls.jbp.io/ now supports final TLS1.3 but you'll be hard-pressed to find a library which negotiates TLS1.3 with it. Give it a few weeks.

anonymousiam 8y ago

Attended this talk yesterday: https://www.defcon.org/html/defcon-26/dc-26-speakers.html#Garc%C3%ADa https://www.defcon.org/html/defcon-26/dc-26-speakers.html#Ga... TLS 1.3 is the new secure communication protocol that should be already with us. One of its new features is 0-RTT (Zero Round Trip Time Resumption) that could potentially allow replay attacks. This is a known issue acknowledged by the TLS 1.3 specification, as the protocol does not provide replay protections for 0-RTT data, but proposed countermeasures that would need to be implemented on other layers, not at the protocol level. Therefore, the applications deployed with TLS 1.3 support could end up exposed to replay attacks depending on the implementation of those protections. This talk will describe the technical details regarding the TLS 1.3 0-RTT feature and its associated risks. It will include Proof of Concepts (PoC) showing real-world replay attacks against TLS 1.3 libraries and browsers. Finally, potential solutions or mitigation controls would be discussed that will help to prevent those attacks when deploying software using a library with TLS 1.3 support.

westurner 8y ago

Is PKI still an optional feature of TLS? Can one still use self-signed x.509 certificates and have key-signing parties?