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

RFC 9849. TLS Encrypted Client Hello

rfc-editor.org

Post reply on HN
Print view View original

61–70 of 159 posts

Re: RFC 9849. TLS Encrypted Client Hello

#61

Post by boondongle »

deep1283 wrote: post #60

ECH is great from a privacy perspective, but I’m curious how well this will actually work in practice.every time the web encrypts more metadata there’s pushback from middleboxes and network operators.

The tension is that Security and Dev parts of the stack remove the actual troubleshooting capabilities of the Network layer without opening up the tools that are supposed to replace them.

It's not a problem if Network can still do their job. It's a whole other matter to expect Network to do their job through another layer. You end up with organizations that can't maintain their applications and expect magic fixes.

Orgs that are cooperative probably don't have this issue but there are definitely parts of some organizations that when one part takes capability from another they don't give it back in some sort of weird headcount game despite not really wanting to understand Network to a Network level.

Re: RFC 9849. TLS Encrypted Client Hello

#62

Post by CloakHQ »

jeroenhd wrote: post #29
CloakHQ wrote: post #25

[flagged]

If you control the domain you're fingerprinting clients on, you can decrypt the inner ClientHello and fingerprint on that. If you're not in control of the domain you're fingerprinting, then ECH is working as intended. I don't expect naive bots to implement ECH any time soon, though. If a bot can't be bothered to download curl-impersonate, they won't pass any ECH flags either.

[flagged]

Re: RFC 9849. TLS Encrypted Client Hello

#63

Post by gzread »

szmarczak wrote: post #55
gzread wrote: post #51

Earlier quoted context omitted.

Why would Clownflare ever see traffic to sites not on Clownflare?

They do routing. Even if you're connecting to a non Cloudflare server, the traffic may still be routed through their servers. Why would they want to peek traffic? Most likely for statistics (most frequently visited websites etc).

Can you give an example of a BGP route or traceroute to a site not on Clownflare that was routed through Clownflare?

Re: RFC 9849. TLS Encrypted Client Hello

#64

Post by jeroenhd »

conradludgate wrote: post #43
jeroenhd wrote: post #26

Earlier quoted context omitted.

> For IPv4, there’s room for ambiguity. I can't think of a single numeric TLD, so I don't think anyone is confusing IP literals with domain names, unless they're doing so extremely lazily. > And how are IP certificates required for small servers? You need a valid certificate as the outer certificate which contains an SNI that will still be readable. For cloudflare.com and google.com that's easy; you can't tell what w…

ECH doesn't benefit you if you're connecting directly to one IP. Middleboxes can track that you're connecting to this IP. ECH prevents tracking through routing layers where your ClientHello might contain foo.example.com or bar.example.com but route via the same IP (Cloudflare). A middlebox can see you are using a cloudflare hosted website, but not know what cloudflare website. There's no benefit encrypting the SNI wi…

THe benefit is that the SNI is not being logged. Resolving an IP to a domain name is pretty hard for a small actor who doesn't have a record of all DNS records.

Re: RFC 9849. TLS Encrypted Client Hello

#65

Post by jeroenhd »

lxgr wrote: post #49
jeroenhd wrote: post #26

Earlier quoted context omitted.

> For IPv4, there’s room for ambiguity. I can't think of a single numeric TLD, so I don't think anyone is confusing IP literals with domain names, unless they're doing so extremely lazily. > And how are IP certificates required for small servers? You need a valid certificate as the outer certificate which contains an SNI that will still be readable. For cloudflare.com and google.com that's easy; you can't tell what w…

But then your underlying issue is that you're microhosting and can't hide behind a large cloud provider's domain front, so isn't that inherent to anything you might do? In other words, blocking solutions that know your small blog is hosted exclusively on 1.2.3.4, without any collateral damage to other blogs the blocking government cares about will just block your IP. Conversely, if you're hosting importedgoodsecommer…

"Just buy a second domain exclusively to work around the arbitrary restrictions put onto the protocol" works as a solution, but it's a silly solution that shouldn't be necessary.

Re: RFC 9849. TLS Encrypted Client Hello

#66

Post by johnisgood »

jeroenhd wrote: post #20
micw wrote: post #8

Earlier quoted context omitted.

If the load balancer can force a downgrade, an attacker can do it as well.

Only if the attacker has a valid certificate for the domain to complete the handshake with. Relying on HTTPS and SVCB records will probably allow a downgrade for some attackers, but if browsers roll out something akin to the HSTS preload list, then downgrade attacks become pretty difficult. DNSSEC can also protect against malicious SVCB/HTTPS records and the spec recommends DoT/DoH against local MitM attacks to preve…

> but if browsers roll out something akin to the HSTS preload list, then downgrade attacks become pretty difficult.

Can you explain why, considering it is at the client's side ("browsers")?

Re: RFC 9849. TLS Encrypted Client Hello

#67

Post by deep1283 »

boondongle wrote: post #61
deep1283 wrote: post #60

ECH is great from a privacy perspective, but I’m curious how well this will actually work in practice.every time the web encrypts more metadata there’s pushback from middleboxes and network operators.

The tension is that Security and Dev parts of the stack remove the actual troubleshooting capabilities of the Network layer without opening up the tools that are supposed to replace them. It's not a problem if Network can still do their job. It's a whole other matter to expect Network to do their job through another layer. You end up with organizations that can't maintain their applications and expect magic fixes. Or…

This feels like a recurring pattern in the stack. abstraction removes visibility faster than tooling replaces it.

Encryption and higher-level platforms are great for security and productivity, but the debugging surface keeps shrinking. Eventually when something breaks, nobody actually has the layer-by-layer visibility needed to reason about it.

Re: RFC 9849. TLS Encrypted Client Hello

#68

Post by Bender »

crote wrote: post #58
ivanr wrote: post #10

Earlier quoted context omitted.

Thanks! Sadly, SSL Labs doesn't appear to be actively maintained. I've noticed increasing gaps in its coverage and inspection quality. I left quite a while ago (2016) and can't influence its grading any more, sadly.

Is there a well-maintained alternative to SSL Labs you can recommend?

I use testssl.sh [1] mostly because I can test things not publicly accessible.

[1] - https://github.com/testssl/testssl.sh

Re: RFC 9849. TLS Encrypted Client Hello

#69

Post by jeroenhd »

johnisgood wrote: post #66
jeroenhd wrote: post #20

Earlier quoted context omitted.

Only if the attacker has a valid certificate for the domain to complete the handshake with. Relying on HTTPS and SVCB records will probably allow a downgrade for some attackers, but if browsers roll out something akin to the HSTS preload list, then downgrade attacks become pretty difficult. DNSSEC can also protect against malicious SVCB/HTTPS records and the spec recommends DoT/DoH against local MitM attacks to preve…

> but if browsers roll out something akin to the HSTS preload list, then downgrade attacks become pretty difficult. Can you explain why, considering it is at the client's side ("browsers")?

If browsers remember which domains do ECH and refuse to downgrade to non-ECH connections after, the way the HSTS cache forces browsers to connect over HTTPS despite direct attempts to load over HTTP, then you only need an entry in the browser database to make downgrade attacks to accomplish SNI-snooping impossible.

For HSTS, browsers come with a preloaded list of known-HTTPS domains that requests are matched against. That means they will never connect over HTTP, rather than connect over HTTP and upgrade+maintain a cache when the HSTS header is present. If ECH comes with a preload list, then browsers connecting to ECH domains will simply fail to connect rather than permit the network to downgrade their connection to non-ECH TLS.

Re: RFC 9849. TLS Encrypted Client Hello

#70

Post by [deleted] »

ivanr wrote: post #10
fmajid wrote: post #7

Earlier quoted context omitted.

Thanks for the writeup, Ivan, I am a great fan of your work! Now we need to get Qualys to cap SSL Labs ratings at B for servers that don't support ECH. Also those that don't have HSTS and HSTS Preload while we're at it.

Thanks! Sadly, SSL Labs doesn't appear to be actively maintained. I've noticed increasing gaps in its coverage and inspection quality. I left quite a while ago (2016) and can't influence its grading any more, sadly.

[deleted]
Post reply on HN