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

51–60 of 78 posts

Re: TLS 1.3 approved

#51

Post by nfoz »

wereHamster wrote: post #13
mtgx wrote: post #10

Earlier quoted context omitted.

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…

0rtt is still useful for static assets, and generally everything that is public. I have a handful of static websites (literally static, as in consisting of just HTML and CSS files), for those 0rtt is awesome. TLS is no longer used to only protect private pages (eg. access to your private emails, the admin section of a CMS). It's also used for privacy reasons on completely public websites.

Just to be clear, 0rtt is only for "revisits", and for revisits of static assets the client is likely to have the asset cached still. So the only benefit is if the "static" asset has changed, or the client's cache is cleared. Which seems less useful.

Re: TLS 1.3 approved

#52

Post by nfoz »

minitech wrote: post #24
cesarb wrote: post #15

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. Of course, TLS is not only for privacy reasons, but also for integrity reasons (preventing injection of malicious Javascript and similar attacks). For that purpose, 0rtt for static assets works fine.

> 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, facebook and other malicious third-parties anyway...

How is anyone supposed to understand digital privacy? Everything sucks, and I'm not even sure what could be done to make it suck less.

Re: TLS 1.3 approved

#53

Post by Ajedi32 »

nfoz wrote: post #50
a_t48 wrote: post #45

Earlier quoted context omitted.

If you're concerned about it, couldn't you turn it off clientside?

Yes. And like so many other behaviours in the web-stack, I feel like I'm in a constant fight with my client software to please choose privacy over convenience. So it's worth being aware of where these tradeoffs exist. Especially when I'm writing that client software.

If you're that paranoid about your privacy, then I recommend you choose a user agent whose philosophy on privacy more closely represents your own.

Tor Browser, for example, is highly likely to "choose privacy over convenience" whenever possible with it's default settings.

Re: TLS 1.3 approved

#55

Post by mcpherrinm »

edwinyzh wrote: post #54

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

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)

Re: TLS 1.3 approved

#56

Post by bscphil »

cesarb wrote: post #9
Asdfbla wrote: post #6

Earlier quoted context omitted.

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?

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.

Re: TLS 1.3 approved

#57

Post by andrewstuart2 »

TimWolla wrote: post #31
_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-…

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 people who understand the ramifications here is much smaller than the number who can throw together a TLS 1.3 listening HTTP server by following some dude's tutorial.

Framework support is not going to be enough. This seems like a bad, bad move.

Re: TLS 1.3 approved

#58

Post by thisacctforreal »

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

Even without encrypted DNS lookups, HTTPS leaks the FQDN (i.e. exact subdomain) of what you are connecting to through Server Name Indication.

SNI was added to allow servers to know which SSL certificate to send to the browser, previously you would need to have one IP address per SSL certificate.

Re: TLS 1.3 approved

#59

Post by thisacctforreal »

jensvdh wrote: post #17
wereHamster wrote: post #13

Earlier quoted context omitted.

0rtt is still useful for static assets, and generally everything that is public. I have a handful of static websites (literally static, as in consisting of just HTML and CSS files), for those 0rtt is awesome. TLS is no longer used to only protect private pages (eg. access to your private emails, the admin section of a CMS). It's also used for privacy reasons on completely public websites.

The content of your page may be encrypted but the DNS lookup isn't

As well as SNI

Re: TLS 1.3 approved

#60

Post by adrianN »

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

I think for the average user, the authentication part is a lot more important than the encryption part unless they're entering passwords. I want to be relatively sure that the site I'm visiting hasn't been replaced by something serving malware. I don't care as much about people knowing which articles I read.
Post reply on HN