Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TLS 1.3 approved

ietf.org

Post reply on HN
Print view View original

31–40 of 78 posts

Re: TLS 1.3 approved

#31

Post by TimWolla »

_wmd wrote: post #8

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…

> 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

There is an Internet Draft for that [1]. It is co-authored by Willy Tarreau of haproxy and implemented within haproxy 1.8 [2].

[1] https://tools.ietf.org/id/draft-thomson-http-replay-01.html

[2] https://www.mail-archive.com/haproxy@formilux.org/msg28004.h... (Ctrl+F 'Early-Data') https://www.mail-archive.com/haproxy@formilux.org/msg27653.h... (Ctrl+F '0-RTT')

Re: TLS 1.3 approved

#32

Post by blattimwind »

agl wrote: post #4
CodeMichael wrote: post #3

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.

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 impl…

Nota bene: TLS debugging via SSLKEYLOGFILE and similar mechanisms is of course not affected.

Re: TLS 1.3 approved

#33

Post by azinman2 »

thriftwy wrote: post #27
azinman2 wrote: post #26

Earlier quoted context omitted.

You make it sound like NSA/GCHQ somehow secretly put in a weakness into a IETF standard that’s gone through many public drafts...

That's roughly the line of their job, as we have all learned the hard way a few years back.

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?

Re: TLS 1.3 approved

#34

Post by tialaramex »

borgesCL wrote: post #22
agl wrote: post #4

Earlier quoted context omitted.

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 impl…

"Assuming they implemented TLS 1.2 correctly, which some didn't." -> BlueCoat?

Basically everybody selling middleboxes screwed up, some worse than others but even the workaround in TLS 1.3 could best be understood as a hint that most middleboxes are ineffective garbage.

Re: TLS 1.3 approved

#35

Post by pas »

nfoz wrote: post #29
_wmd wrote: post #8

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…

The other thing I don't like about 0-RTT is that the client reveals that they've been to the server before, i.e. it removes a plausible case for anonymity. Just another implicit "cookie" that needs to be washed, I suppose. I would love if instead the pre-shared secret enabling 0RTT could be something obtained through DNS instead, if that's possible. But that would require a secure DNS, which we don't have.

How exactly does the client reveal that?

Re: TLS 1.3 approved

#36

Post by rgbrenner »

nfoz wrote: post #29
_wmd wrote: post #8

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…

The other thing I don't like about 0-RTT is that the client reveals that they've been to the server before, i.e. it removes a plausible case for anonymity. Just another implicit "cookie" that needs to be washed, I suppose. I would love if instead the pre-shared secret enabling 0RTT could be something obtained through DNS instead, if that's possible. But that would require a secure DNS, which we don't have.

But that problem is just session resumption, and that isn't new or specific to 1.3. Another way to do this would be session tickets too (also not new with 1.3). Your client can remove support for both, and always connect as a new connection.

Re: TLS 1.3 approved

#37

Post by nfoz »

pas wrote: post #35
nfoz wrote: post #29

Earlier quoted context omitted.

The other thing I don't like about 0-RTT is that the client reveals that they've been to the server before, i.e. it removes a plausible case for anonymity. Just another implicit "cookie" that needs to be washed, I suppose. I would love if instead the pre-shared secret enabling 0RTT could be something obtained through DNS instead, if that's possible. But that would require a secure DNS, which we don't have.

How exactly does the client reveal that?

From the spec: "When clients and servers share a PSK (either obtained externally or via a previous handshake), TLS 1.3 allows clients to send data on the first flight (“early data”). The client uses the PSK to authenticate the server and to encrypt the early data."

The client initiating the 0RTT provides a pre-shared key, thus revealing to the server that they're not a newcomer. I don't know exactly how many bits of that PSK could be used by the server to identify specific clients. For QUIC I think it's a 15-bit identifier. Browsers will need to clear the PSK (and so remove the 0-RTT) when they clear cookies or in a "private browsing" mode.

Re: TLS 1.3 approved

#38

Post by nerdponx »

_wmd wrote: post #8

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…

For the nontechnical, what does 0rtt do?

Re: TLS 1.3 approved

#39

Post by geofft »

nerdponx wrote: post #38
_wmd wrote: post #8

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…

For the nontechnical, what does 0rtt do?

"Zero round trip time," i.e., if your web browser previously had an encrypted session with the server and cached the cryptographic keys involved, the next time you visit the website, it can immediately encrypt an HTTP request to that public key and send it in the first packet.

Normally there's a handshake involved: your browser and the server send packets to each other to set up an encrypted channel, then the server uses its certificate to prove that it's in control of its end of the private channel, then you can send a request. So if you and the server are, say, 50 ms apart, there's usually an extra 200 ms for this handshake, which 0-RTT can save you.

The danger is that because your browser isn't setting up an encrypted channel but just sending a request and hoping for the best, someome who can capture the packet can just re-send it to trigger the request twice. Duplicaing the request is fine for, say, the HN home page, but annoying for a comment reply and a real problem for an online purchase.

Re: TLS 1.3 approved

#40

Post by [deleted] »

nfoz wrote: post #37
pas wrote: post #35

Earlier quoted context omitted.

How exactly does the client reveal that?

From the spec: "When clients and servers share a PSK (either obtained externally or via a previous handshake), TLS 1.3 allows clients to send data on the first flight (“early data”). The client uses the PSK to authenticate the server and to encrypt the early data." The client initiating the 0RTT provides a pre-shared key, thus revealing to the server that they're not a newcomer. I don't know exactly how many bits of…

[deleted]
Post reply on HN