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

71–78 of 78 posts

Re: TLS 1.3 approved

#71

Post by rurban »

geofft wrote: post #41
rurban wrote: post #21

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.

Can you explain how 0-RTT might be used as a back door? (... edit, actually, I recognize this username from previous nonsensical discussions about crypto and backdoors: https://news.ycombinator.com/item?id=13364173 )

Thanksfully those folks easily expose themselves. Calling the Siphash security theatre senseless explains it also.

Re: TLS 1.3 approved

#72

Post by pas »

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…

Is there any way to do a 0RTT request for a completely new connection/session?

I mean, if I want to get weather data from let's say NOAA, so a simple GET / HTTP/2, why would I want to send any PSK? Let the server send the response and the Server Cert and the client can decide whether to trust the reply or not.

CloudFlare only "allows" 0RTT for GETs, for example. Is that different, or they also need the PSK?

Re: TLS 1.3 approved

#73

Post by tialaramex »

pas wrote: post #72
nfoz wrote: post #37

Earlier quoted context omitted.

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…

Is there any way to do a 0RTT request for a completely new connection/session? I mean, if I want to get weather data from let's say NOAA, so a simple GET / HTTP/2, why would I want to send any PSK? Let the server send the response and the Server Cert and the client can decide whether to trust the reply or not. CloudFlare only "allows" 0RTT for GETs, for example. Is that different, or they also need the PSK?

0-RTT is defined with a PSK (pre-shared key). There are two ways you might have a PSK. The only one that would come up in a web browser as they're constructed today is a "resumption" PSK, agreed between the two parties during a previous connection.

For the Internet of Things it's also envisioned that some devices might know a PSK at the outset to use TLS rather than some custom protocol to secure their traffic. Maybe your lightbulb controller knows a PSK for the lightbulbs baked in at the factory. But it's not expected that web browsers will care about this case.

Re: TLS 1.3 approved

#74

Post by tialaramex »

blattimwind wrote: post #65
mehrdadn wrote: post #61

Earlier quoted context omitted.

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

Rejecting replays by remembering the conversations you had previously forever is permissible in the standard and even called out as something an application can do. It's not required because whilst it's trivial for a toy web server anybody at scale can't do it.

Re: TLS 1.3 approved

#76

Post by zaarn »

nfoz wrote: post #52
minitech wrote: post #24

Earlier quoted context omitted.

> Wouldn't that be a bit of a privacy leak? If 0rrt works, it was a request for a static asset. Response size and timing probably already leak this.

This honestly really bothers me. We're encrypting everything, we have "Let's Encrypt", we have browsers telling users that their connections are "secure". Meanwhile your DNS lookups are public (which leaks what site you're accessing) and size+timing analysis leaks which static assets you've retrieved. Which gives away for example what article you're reading on what news site. Which the site itself is telling google,…

For DNS lookups we're having people testing out DNS-over-HTTPS which would solve this entirely, lookups would be opaque to anyone but the DNS server involved.

For timing and size you can usually do something about it as a site owner (HTTP/2 for example will multiplex connections so it makes timing and size comparisons much harder)

Re: TLS 1.3 approved

#77

Post by pas »

tialaramex wrote: post #73
pas wrote: post #72

Earlier quoted context omitted.

Is there any way to do a 0RTT request for a completely new connection/session? I mean, if I want to get weather data from let's say NOAA, so a simple GET / HTTP/2, why would I want to send any PSK? Let the server send the response and the Server Cert and the client can decide whether to trust the reply or not. CloudFlare only "allows" 0RTT for GETs, for example. Is that different, or they also need the PSK?

0-RTT is defined with a PSK (pre-shared key). There are two ways you might have a PSK. The only one that would come up in a web browser as they're constructed today is a "resumption" PSK, agreed between the two parties during a previous connection. For the Internet of Things it's also envisioned that some devices might know a PSK at the outset to use TLS rather than some custom protocol to secure their traffic. Maybe…

I'm pretty happy with the strong confidentiality guarantees offered by TLS 1.3, and a finished standard is better than more draft and committee turns, but I think the simple use case of securely accessing "public" information with 0-RTT seems to be left out.

Or simply serving static content faster would have been a nice few percentage efficiency gain.

Re: TLS 1.3 approved

#78

Post by xorcist »

cesarb wrote: post #67
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).

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.
Post reply on HN