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

151–159 of 159 posts

Re: RFC 9849. TLS Encrypted Client Hello

#151

Post by pocksuppet »

sgjohnson wrote: post #131
pocksuppet wrote: post #129

Earlier quoted context omitted.

> How do you determine to whom an IP is even registered to? You check the RIR's records. > They get sub-leased all the time. With records updated. If not, any consequences from wrong information fall on the lessor and lessee. > There's also no way to actually know _where_ an IP actually originates from. Only its AS path. Ping time from different locations on their upstream AS gives a good guess.

> With records updated. If not, any consequences from wrong information fall on the lessor and lessee. Not always + there are no consequences whatsoever. Plenty of leasing services will just provide you with IRR & RPKI, without ever touching the actual records. > Ping time from different locations on their upstream AS gives a good guess. Upstream AS is meaningless if it's a T1 carrier. Ping AS6939. They are everywher…

Ping a specific address of AS6939 and find out where it is.

Re: RFC 9849. TLS Encrypted Client Hello

#152

Post by sgjohnson »

pocksuppet wrote: post #151
sgjohnson wrote: post #131

Earlier quoted context omitted.

> With records updated. If not, any consequences from wrong information fall on the lessor and lessee. Not always + there are no consequences whatsoever. Plenty of leasing services will just provide you with IRR & RPKI, without ever touching the actual records. > Ping time from different locations on their upstream AS gives a good guess. Upstream AS is meaningless if it's a T1 carrier. Ping AS6939. They are everywher…

Ping a specific address of AS6939 and find out where it is.

https://bgp.tools/as/6939#prefixes

They are everywhere. It's a global carrier. Carriers also know no geographic boundaries.

Re: RFC 9849. TLS Encrypted Client Hello

#153

Post by tialaramex »

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

Earlier quoted context omitted.

> 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?

Yes, you've basically got it, the customers for fuck-trump.example just write your chosen value in OuterSNI and fuck-trump.example in the InnerSNI, which is encrypted and you do the (very cheap on modern hardware) decryption and route fuck-trump.example. In practice it might work (but isn't guaranteed to) to write something else in OuterSNI like whitehouse.gov rather than the value chosen by the operator.

It's apparent from other responses that most people didn't understand that we're not talking about a weird new feature which might work if people implement it. This is the published document explaining how it works, but the reality is that it's widely deployed today. This is already how it's working today, if you tell people first they raise all sorts of objections and insist it's unworkable, so, we didn't tell them first we just did it. Here's a relevant quote:

"Dan, I'm not a Republic serial villain. Do you seriously think I'd explain my master-stroke if there remained the slightest chance of you affecting its outcome? I did it thirty-five minutes ago" -- Watchmen, by Alan Moore.

Re: RFC 9849. TLS Encrypted Client Hello

#154

Post by jeroenhd »

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.

> you just need to trust the resolver you're DoH'ing to

I don't trust the public DoH resolvers that much, actually, and neither do I trust my own ISP. I know for a fact that they mess with DNS records because of court orders, and I want to know when that happens.

DoH and DoT are not the modern DNSSEC alternatives we need. They naively assume that the DNS resolver always speaks the truth.

Re: RFC 9849. TLS Encrypted Client Hello

#155

Post by ndriscoll »

pocksuppet wrote: post #150
ndriscoll wrote: post #148

Earlier quoted context omitted.

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.

They do not. Here's the California bill[0]. Here's the Colorado bill[1]. They're short. Nowhere is there something about letting me set policy (e.g. blocking applications/services, presenting plaintext traffic to filtering software, setting time-of-use restrictions, etc.). In fact, it requires my operating system to give any application developer PII about me and requires the application to collect it, even when it's irrelevant (functionality is not age-restricted).

Or did you have some other laws in mind?

[0] https://leginfo.legislature.ca.gov/faces/billTextClient.xhtm...

[1] https://leg.colorado.gov/bill_files/112795/download

Re: RFC 9849. TLS Encrypted Client Hello

#156

Post by EvanAnderson »

JoshTriplett wrote: post #99
EvanAnderson wrote: post #91

Earlier quoted context omitted.

Because there are network operators who have mal-intent increasingly no network operators are permitted to exercise network-level control. A parent who wants to filter the network access in their house is the same as a despotic regime practicing surveillance and censorship on their citizens. Given that it's pretty much the norm that consumer embedded devices don't respect the owner's wishes network level filtering is…

If you have a device you don't trust, don't allow it on your network, or have an isolated network for such devices. Meanwhile, devices are right to not allow MITMing their traffic and to treat that as a security hole, even if a very tiny fraction of their users might want to MITM it to try to do adblocking on a device they don't trust or fully control, rather than to exploit the device and turn it into a botnet. Alon…

> If you have a device you don't trust, don't allow it on your network...

That's what I do. That means large swaths of potentially interesting "smart" devices are unavailable to me (since they won't work without Internet access and I'm unable to inspect their traffic). I'm not too heartbroken about it, but it does make me a little sad that I don't get to use some of this "we're living in the future" tech.

> ...devices are right to not allow MITMing their traffic and to treat that as a security hole...

> ...a security hole you can use for jailbreaking is also a security hole that could potentially be exploited by malware...

Yes. Complete agreement. Devices are right not to allow unauthorized parties to MiTM their traffic, tinker w/ their innards, etc. I would never suggest otherwise.

Owners, with physical access, should be permitted to MITM the traffic, tinker with the innards, etc. They're authorized parties.

Device manufacturers should compelled by regulation to allow device owners, with physical access, to examine and manipulate the device internals. I'm thinking of the "developer mode" physical switches on Chromebook devices. If I own it I should have the same access to the device the manufacturer does.

If a manufacturer's business / security model isn't compatible with this regulation the manufacturer should be required to deal with any e-waste concerns and it should clearly be marketed as a rental and not a sale.

None of this will ever happen. I know I'm tiling at windmills. The tech world will continue to get more locked-down, the public will lose unfettered access to general purpose computers, and the personal computer revolution will become a distant memory. We already lost and could never really win because "normies" don't care about this stuff.

Re: RFC 9849. TLS Encrypted Client Hello

#157

Post by JoshTriplett »

EvanAnderson wrote: post #156
JoshTriplett wrote: post #99

Earlier quoted context omitted.

If you have a device you don't trust, don't allow it on your network, or have an isolated network for such devices. Meanwhile, devices are right to not allow MITMing their traffic and to treat that as a security hole, even if a very tiny fraction of their users might want to MITM it to try to do adblocking on a device they don't trust or fully control, rather than to exploit the device and turn it into a botnet. Alon…

> If you have a device you don't trust, don't allow it on your network... That's what I do. That means large swaths of potentially interesting "smart" devices are unavailable to me (since they won't work without Internet access and I'm unable to inspect their traffic). I'm not too heartbroken about it, but it does make me a little sad that I don't get to use some of this "we're living in the future" tech. > ...device…

> If a manufacturer's business / security model isn't compatible with this regulation the manufacturer should be required to deal with any e-waste concerns and it should clearly be marketed as a rental and not a sale.

I would be generally in favor of this. I don't like the idea of forbidding building a device that's locked down; there are potential use cases for such a thing. I do like the idea of saying "either allow tinkering or you are subject to numerous other things, like warranty / liability laws".

Re: RFC 9849. TLS Encrypted Client Hello

#159

Post by icehawk »

pocksuppet wrote: post #151
sgjohnson wrote: post #131

Earlier quoted context omitted.

> With records updated. If not, any consequences from wrong information fall on the lessor and lessee. Not always + there are no consequences whatsoever. Plenty of leasing services will just provide you with IRR & RPKI, without ever touching the actual records. > Ping time from different locations on their upstream AS gives a good guess. Upstream AS is meaningless if it's a T1 carrier. Ping AS6939. They are everywher…

Ping a specific address of AS6939 and find out where it is.

ns1.he.net - 216.218.130.2, is simultaneously in

Texas (measured from Texas):

  8  port-channel13.core4.dal1.he.net (184.104.196.170)  1.830 ms  1.969 ms *
  9  ns1.he.net (216.218.130.2)  1.539 ms  1.560 ms  1.555 ms
Virginia (measured from Maryland):

  11  port-channel2.core1.ash1.he.net (184.105.222.174)  19.666 ms 24.395 ms *
  12  ns1.he.net (216.218.130.2)  16.748 ms  17.268 ms  20.507 ms
And California (measured from California):

  8  port-channel13.core1.fmt2.he.net (184.104.188.144)  3.830 ms be7.core1.sjc1.he.net (72.52.92.132)  5.197 ms port-channel13.core1.fmt2.he.net (184.104.188.144)  3.901 ms
  9  ns1.he.net (216.218.130.2)  2.600 ms  2.435 ms  2.728 ms
The speed of light doesn't lie, IP addresses don't have any sort of physicality.
Post reply on HN