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

141–150 of 159 posts

Re: RFC 9849. TLS Encrypted Client Hello

#141

Post by Hizonner »

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…

The network's job is to move packets from A to B, based on the addresses in the headers. Full stop.

Re: RFC 9849. TLS Encrypted Client Hello

#142

Post by tialaramex »

tptacek wrote: post #136
jeroenhd wrote: post #130

Earlier quoted context omitted.

DNSSEC alone is obviously useless because any attacker interested in SNI hostnames can just as easily monitor DNS traffic. However, DoH/DoT without record integrity is about as useful as self-signed HTTPS certificates. You need both for the system to work right in every case. To quote the spec: > Clearly, DNSSEC (if the client validates and hard fails) is a defense against this form of attack, but encrypted DNS trans…

I don't think this is true; I think this misunderstands the ECH threat model. You don't need record integrity to make ECH a strong defense against on-path ISP attackers; you just need to trust the resolver you're DoH'ing to.

This actually reminds me of the "God of the gaps" problem. A gradual retreat in the face of inconvenient facts.

Many years ago when I was a student the argument was that integrity isn't a big deal so plaintext telnet is just fine. If you're paranoid you use an "enhanced" telnet where the authentication step is protected but not everything else [Yes I'm an old man]

By the turn of the century everybody agreed telnet is stupid, use SSH but integrity still wasn't a big deal when it comes to ordinary web sites. Only your bank needs SSL fool.

And I suppose that 8-10 years ago that changed too and it's now recognised that plaintext HTTP really isn't good enough, you need HTTPS. But still I see that you say integrity isn't important when it comes to DNS records.

Integrity is the hardest thing to get ordinary users to care about. Given how freely even young kids lie we should probably take it more seriously but it remains hard to get ordinary people to care, however ultimately this does matter.

Re: RFC 9849. TLS Encrypted Client Hello

#143

Post by tptacek »

tialaramex wrote: post #142
tptacek wrote: post #136

Earlier quoted context omitted.

I don't think this is true; I think this misunderstands the ECH threat model. You don't need record integrity to make ECH a strong defense against on-path ISP attackers; you just need to trust the resolver you're DoH'ing to.

This actually reminds me of the "God of the gaps" problem. A gradual retreat in the face of inconvenient facts. Many years ago when I was a student the argument was that integrity isn't a big deal so plaintext telnet is just fine. If you're paranoid you use an "enhanced" telnet where the authentication step is protected but not everything else [Yes I'm an old man] By the turn of the century everybody agreed telnet is…

Sir, this is a Wendy's. We're talking about ECH. Can you maybe rephrase all this to be specifically about how DNS record integrity practically impacts the threat model for ECH? The threat actor for Encrypted Client Hello is ISPs.

This same thing happened with DNS cache corruption; which went unaddressed from the mid-1990s to 2008 despite the known fix of port/ID randomization because the DNS operator community was fixated on the "real" fix of... DNS record integrity.

Re: RFC 9849. TLS Encrypted Client Hello

#144

Post by Ms-J »

arowthway wrote: post #78
arch-choot wrote: post #12

Glad that it's published, I'd been following it since ESNI draft days. Was pretty useful back when I was in India since Jio randomly blocked websites, and cloudflare adopted the ESNI draft on its servers as did Firefox client side which made their SNI based blocking easy to bypass. There was a period where I think both disabled ESNI support as work was made on ECH, which now is pretty far along. I was even able to se…

The server can also advertise a public name that doesn't match any domain it has a TLS certificate for, like example.com or nsa.gov. I'm not 100% sure it's allowed in the specs, but it works in Chrome. As I understand it, without this feature it would be pretty useless for small website owners, since they would need to register a separate domain for their ECH public name, which censors could just block.

This is a good feature for getting past blocks.

I'm happy that this RFC is published.

Re: RFC 9849. TLS Encrypted Client Hello

#145

Post by arch-choot »

tialaramex wrote: post #134
ignoramous wrote: post #125

Earlier quoted context omitted.

> Such tricks, called "domain fronting" GP said "not setting SNI"... doing TLS handshake with IP certs don't (need to) set SNI?

That's true, usually with domain fronting you provide the (wrong) SNI. But the same strategy is happening here, you were supposed to provide SNI and you didn't to avoid some potential censorship but it's a headache for the provider They won't have received a certificate for the IP as a name, it's relatively unusual to have those, the main users are things like DoH and DoT servers since their clients may not know the…

An example for the hub:

``` echo -e "GET / HTTP/1.1\r\nHost: www.pornhub.com\r\nConnection: close\r\n\r\n" | openssl s_client -connect 66.254.114.41:443 -quiet ```

This works for most ISPs in India, but if you set the SNI it'll get a TCP reset

Re: RFC 9849. TLS Encrypted Client Hello

#146

Post by arch-choot »

tialaramex wrote: post #72
arch-choot wrote: post #34

Earlier quoted context omitted.

Should've added this was back in like 2018 or so. Setting up DoH was harder than enabling SNI, and from my testing back then they were hard filtering on SNI (e.g. I used OpenSSL CLI to set the SNI to `pornhub.com` and connect to "known good" IPs, it'd still get reset). Funnily enough, not setting the SNI and connecting the the origin IP, and then requesting the page worked fine.

> Funnily enough, not setting the SNI and connecting the the origin IP, and then requesting the page worked fine. Such tricks, called "domain fronting" are why ECH exists. The problem is that although domain fronting is effective for the client it's a significant headache for the provider. Big providers involved, such as Cloudflare have always insisted that they want to provide this sort of censorship resisting capab…

Could you clarify a bit more what you mean by "Domain Fronting is why ECH exists"?

Because even with ECH, you (TLS client) can set any public_name you want, but the innerSNI can be something else.

Or is that what you mean; since the providers can "ignore" the OuterSNI, they can rely on the InnerSNI to still route traffic?

Re: RFC 9849. TLS Encrypted Client Hello

#147

Post by ndriscoll »

iamnothere wrote: post #113
ndriscoll wrote: post #90

Earlier quoted context omitted.

I think the population at large generally needs to get over their hangups (actually, maybe they have, and it's just techies). No one in a first world country cares if you visit pornhub just like no one cares if you go to amazon. Your ISP has had the ability to see this since the beginning of the web. It does not matter, but we can also have privacy laws restricting their (and everyone else like application/service ve…

Yes well some of us live in first world countries that are at risk of declining into third world status, where some states DO actually care what sites you visit and would jump at the chance to further restrict traffic. Rather than “get over” it I think we need to fight . You seem to insist that monitoring/control is a done deal and we only need to argue about the form it takes, but this is not correct. Centralized mo…

I think you misunderstand what I mean by "centralized". I mean e.g. at your gateway/firewall/router. As in a single place for you to enforce policy on your network.

At least in the US, what happens outside of your network is mostly irrelevant (except perhaps that free, open wifi should be liable for any lack of filtering). Centralized (as in e.g. government) control is non-existent, and centralized monitoring is easily defeated if you'd like with a variety of methods (though like I said we could have laws against the monitoring).

Re: RFC 9849. TLS Encrypted Client Hello

#148

Post by ndriscoll »

pocksuppet wrote: post #116
ndriscoll wrote: post #105

Earlier quoted context omitted.

This brings us back to "sure you can use my guest wifi, just install my root CA/enroll in MDM". I do agree though that it should be illegal for device manufacturers or application developers to use encryption that the device owner cannot MitM. The owner should always be able to install their own CA and all applications should be required to respect it.

Why would you want to censor based on network? You don't want to censor based on network, you want to censor based on device. If your 8yo kid is blocked from pornhub, that doesn't mean everyone on your network is blocked from pornhub, and you having the ability to even know if someone on your network is browsing pornhub is a security risk.

Because consumer devices are barely if at all capable of even setting policy, are basically incapable of enforcing it, and are generally adversarial. It's also easy to apply different policies to different clients at the network level.

Re: RFC 9849. TLS Encrypted Client Hello

#150

Post by pocksuppet »

ndriscoll wrote: post #148
pocksuppet wrote: post #116

Earlier quoted context omitted.

Why would you want to censor based on network? You don't want to censor based on network, you want to censor based on device. If your 8yo kid is blocked from pornhub, that doesn't mean everyone on your network is blocked from pornhub, and you having the ability to even know if someone on your network is browsing pornhub is a security risk.

Because consumer devices are barely if at all capable of even setting policy, are basically incapable of enforcing it, and are generally adversarial. It's also easy to apply different policies to different clients at the network level.

The new California and Colorado laws force consumer devices to be capable of setting and enforcing policy.
Post reply on HN