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

61–70 of 78 posts

Re: TLS 1.3 approved

#61

Post by mehrdadn »

geofft wrote: post #39
nerdponx wrote: post #38

Earlier quoted context omitted.

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…

> 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.

Not an expert on this but this seems a little bit wrong or at least very misleading when I reason through it? I don't imagine the server needs to prove anything before it is sent data encrypted with its public key... if it doesn't have the private key then it simply can't decrypt; it wouldn't need a certificate for that. Rather I expect this is because the server & client want to generate ephemeral keys (for forward secrecy), which fundamentally requires a round-trip. Is that correct?

Re: TLS 1.3 approved

#62

Post by alwillis »

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?

Great presentation by a couple of Cloudflare employees:

"Deploying TLS 1.3: the great, the good and the bad”—https://www.youtube.com/watch?v=0opakLwtPWk

Re: TLS 1.3 approved

#64

Post by tialaramex »

mehrdadn wrote: post #61
geofft wrote: post #39

Earlier quoted context omitted.

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

> 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. Not an expert on this but this seems a little bit wrong or at least very misleading when I reason through it? I don't imagine the server needs to prove anything…

A few things:

Yes, normal setup for TLS 1.3 always does ephemeral keys for forward secrecy first.

If some alternate protocol started by sending data encrypted with a remote server's public key this data can be replayed by attackers, just like with 0-RTT in TLS 1.3, this problem is unavoidable for 0-RTT protocols.

But where should we get a public key from anyway? If it came from a previous session, the resumption PSK is better. If we got it by guessing, maybe checking a central store of known public keys, then it might be wrong and we have to start over any time it was wrong anyway.

We have to wait to see the certificate (and transcript signature) in the normal case because until we see the certificate (and signature) we have no proof we're talking to whoever we wanted to talk to, and even if the wrong person can't decrypt the message they can replay it at their leisure.

Note that "waiting" for these is an exaggeration, in TLS 1.3 the server sends both its half of the key exchange AND the certificate with the transcript signature AND any extra metadata in a single message, it's just conceptually separate because the latter part of this message is encrypted while the first part agreed the keys for encryption, so the client needs to think about them separately.

Re: TLS 1.3 approved

#65

Post by blattimwind »

mehrdadn wrote: post #61
geofft wrote: post #39

Earlier quoted context omitted.

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

> 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. Not an expert on this but this seems a little bit wrong or at least very misleading when I reason through it? I don't imagine the server needs to prove anything…

The server needs to transmit its certificate to the client. Before that the client generally doesn't know the server's public key.

For PFS suites with ephemeral-ephemeral DH/ECDH (DHE/ECDHE in TLS parlance) the client generates a DH key pair for each connection and so does the server; both public keys need to be exchanged before secrecy can commence.

EE-DH-based handshakes have innate entropy (due to the ephemeral keys), but TLS was initially build without EE-DH. For the historic RSA key exchange, client and server random nonces supply the handshake entropy and liveness proof; again necessitating a transmission of both nonces to the other party. RSA-KEX was removed in TLS 1.3. The nonces are always there, mostly for PSK and PSK-only handshakes (otherwise you could use PSKs only once).

TLS 1.3 resumption essentially uses a previously negotiated shared secret (PSK) which allows both parties to forego authentication-by-signature, because knowledge of the PSK authenticates them. Forward secrecy is added back in by EE-DH, but can actually be disabled.

TLS 1.3 0-RTT extends session resumption. Essentially, the early data is encrypted only under the PSK. It has neither forward secrecy (relative to the session under negotiation) nor liveness [I think it might be hypothetically possible to reject replays server-side by rejecting duplicate ClientHello.random values but this is hugely out of spec and completely negates any performance benefits 0RTT might have had].

(It's important to realize that TLS is and always has been a meta-protocol with a lot of knobs you can tweak. Now, for use in HTTPS/FTPS/STARTTLS the set of parameters is relatively restricted, because e.g. browsers simply won't support PSK-only handshakes. For general discussions of TLS properties this is something to keep in mind, however.)

Re: TLS 1.3 approved

#67

Post by cesarb »

ohnoesjmr wrote: post #66

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

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 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).

Re: TLS 1.3 approved

#68

Post by cesarb »

bscphil wrote: post #56
cesarb wrote: post #9

Earlier quoted context omitted.

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

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.

With SNI, they can't easily see whether you're looking at https://en.wikipedia.org/wiki/Cat or at 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.

Re: TLS 1.3 approved

#69

Post by 0x0 »

andrewstuart2 wrote: post #57
TimWolla wrote: post #31

Earlier quoted context omitted.

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

That would certainly require a lot of coupling from proxy to code, though. The nicest thing about TLS is that it's just a transparent dumb pipe that provides confidentiality and integrity (and less often, client authentication). Having to write your app to understand that TLS 1.3 was used, and 0RTT was used, seems like a really really bad idea. The longer I'm in engineering, the more I realize that the number of peop…

Eh, it doesn't sound too bad. There's already a myriad of meta data (HTTP request headers) you need to process today if you want to be a good HTTP citizen, such as acknowledging Accept-Encoding, HTTP byte ranges, If-Modified-Since, X-Forwarded-For, X-Forwarded-Proto, etc; and sending correct response headers such as Cache-Control, Vary, and so on.

Re: TLS 1.3 approved

#70

Post by tialaramex »

bscphil wrote: post #56
cesarb wrote: post #9

Earlier quoted context omitted.

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

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.

https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-02 is the current state of the effort to encrypt SNI. It's a good overview of which obvious ideas can't work and why, plus some complicated ideas that might work, with two of them expanded to a state where it's reasonable to start developing opinions about them as engineers or cryptographers.

Ultimately the destination is that one of these two (or potentially some upset newcomer if it's written up and presented soon) becomes the agreed way to do SNI encryption, and perhaps in 2019-2020 we start seeing clients & servers that can really do it.

For the short term it remains unclear which of the following three things will happen, both generally and in particular environments:

1. (Bad) Organisations bite the bullet and MitM Proxy everything, expenditure on MitM proxies sky-rockets, lawyers spend lots of time & money in court arguing that they _had_ to MitM proxy everything even though it violated employees legal rights.

2. (Good) Organisations suck it up and get rid of MitM proxies almost everywhere, preferring edge solutions that actually still work with TLS 1.3 without needing to spend loads of cash on MitM proxies for everything.

3. (Meh) Organisations refuse to use TLS 1.3, insisting on downgrading everything to TLS 1.2 and crossing their fingers that never becomes obsolete or insecure (see also Windows XP)

Post reply on HN