Live data from Hacker News

RFC 9849. TLS Encrypted Client Hello

rfc-editor.org

41–50 of 159 posts

Re: RFC 9849. TLS Encrypted Client Hello

#41
post #36

Earlier quoted context omitted.

How would you (an arbitrary web server) fingerprint a TLS connection if the Client Hello is encrypted?

The website owner (or cloudflare in this case) has the keys to decrypt the client hello. That's necessary for routing information.

You're right, sorry! I got confused myself.

Re: RFC 9849. TLS Encrypted Client Hello

#42
post #36

Earlier quoted context omitted.

I am talking about TLS fingerprinting, not JS fingerprinting. > Please elaborate how else TLS fingerprinting can be done. By doing everything as it is right now?

How would you (an arbitrary web server) fingerprint a TLS connection if the Client Hello is encrypted?

By decrypting it? I don't think you know how TLS, or E2E works in general. ISP doesn't perform the fingerprinting, the server does.

Re: RFC 9849. TLS Encrypted Client Hello

#43
post #22

Earlier quoted context omitted.

The colon isn’t a valid character in DNS, so there’s just no risk of confusing IPv6 addresses (which contain at least one colon in all notations I’ve seen). For IPv4, there’s room for ambiguity. And how are IP certificates required for small servers?

> 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 with 10.20.30.40 if they can see you're connecting to 10 20.30.40 anyway

Re: RFC 9849. TLS Encrypted Client Hello

#44
post #38

Earlier quoted context omitted.

It doesn't prevent fingerprinting, stop spreading misinformation. It only prevents your ISP from knowing what website you're connecting to.

Since most ISPs also maintain their own DNS resolver, they could always reverse lookup the IP address AFAIK.

True. ECH is useless if you're using plain DNS. DNS over TLS or HTTPS is the way to go.

Re: RFC 9849. TLS Encrypted Client Hello

#45
post #36

Earlier quoted context omitted.

How would you (an arbitrary web server) fingerprint a TLS connection if the Client Hello is encrypted?

By decrypting it? I don't think you know how TLS, or E2E works in general. ISP doesn't perform the fingerprinting, the server does.

Of course! My bad, thanks for engaging.

Re: RFC 9849. TLS Encrypted Client Hello

#46
post #38

Earlier quoted context omitted.

It doesn't prevent fingerprinting, stop spreading misinformation. It only prevents your ISP from knowing what website you're connecting to.

Since most ISPs also maintain their own DNS resolver, they could always reverse lookup the IP address AFAIK.

The whole idea behind ECH is one IP hosts tons of sites (eg. CDN) so you have no idea which one it is.

Also reverse lookup has nothing to do with hosting own DNS resolver.

Re: RFC 9849. TLS Encrypted Client Hello

#49
post #22

Earlier quoted context omitted.

The colon isn’t a valid character in DNS, so there’s just no risk of confusing IPv6 addresses (which contain at least one colon in all notations I’ve seen). For IPv4, there’s room for ambiguity. And how are IP certificates required for small servers?

> 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 importedgoodsecommercesitegovernmentofficialslove.com next to myhumanrightsblog.net on the same IP, ECH is for you and solves your problem: Just register mycoolagnostichosting.net and do ECH to that.

Re: RFC 9849. TLS Encrypted Client Hello

#50
post #38

Earlier quoted context omitted.

Since most ISPs also maintain their own DNS resolver, they could always reverse lookup the IP address AFAIK.

The whole idea behind ECH is one IP hosts tons of sites (eg. CDN) so you have no idea which one it is. Also reverse lookup has nothing to do with hosting own DNS resolver.

What you're describing is a SNI, not ECH. Those two serve very different purposes.

> Also reverse lookup has nothing to do with hosting own DNS resolver.

It has everything to do with that. Had you used two brain cells, you would've known that they can memorize the IP address and the domain name, and if you connect to that IP in a short period of time, most likely you visited that domain name.

Post reply on HN