I'm still pissed off we didn't get encrypted SNI in TLS 1.3

It would've broken so many dpi based censorship systems in countries like Iran, Turkey, and Russia.

We’re working on it.

(for the lazy: eastdakota's profile claims to be the CEO & co-founder of CloudFlare)

Thanks & very, very good luck!

He is

This is fantastic and amazing to hear. Thank you!

Getting rid of plaintext SNI won't help much.

The domain is there in the certificate itself. There are, of course, some (or maybe many, I don't have statistics) certificates for multiple domains (wildcard and alt. name), but still.

> The domain is there in the certificate itself.

With TLS 1.3, the certificate is in the encrypted portion of the handshake.

However as I understand the protocol the very first step of the TLS 1.3 handshake, the nonce generation, can be MiTMed sufficiently to allow an attacker to determine the target domain. It's only in the next step that server and client do authentication.

The attacker can't trivially continue the handshake beyond that point but that might give enough info to log the attempt and terminate the connection.

Or just connect up a second connection and see what certificate they send back.

That's nice to hear. I stand corrected, thank you.

SNI is just an ugly hack because IPv6 is not deployed widely.

You could have a server listen on a subnet and clients randomizing its target IP.

Datacenters today work differently: IPs convey a fuzzy idea of where to find what you are looking for. Server name will be used to route your request internally in the DC.

I cannot imagine exposing the IPv6 IPs of single racks: it makes the whole "cloud" thing fall apart.

You don't need to. This is no different than how lack of SNI is handled with IPv4, just have multiple static IP addresses on whatever frontend you're using. With IPv6 it's easy to delegate as many IP addresses as you want. The slight problem with this is that it doesn't solve the privacy problem at all as now you just look at the IP address and check which domain it serves.

If thats true it’s because of the limitations of IPv4 more than anything else. With a single $5/month machine from Linode you have a /64 IPv6 subnet, that is 2^64 IP addresses just for that one machine.

how would encrypted SNI work? sure, you can probably do some sort of DHE, but that's vulnerable to MITM, which is why we have certificates to begin with.

What if we could have first class SSL certs for IP addresses? You connect to the IP and verify the cert it presents you with your PKI, then switch to the desired host via SNI or some other mechanism after DHE is established. I suspect you could do this without any extra hops but I haven't really thought through how that would work.

tls certificates already work out of the box for ip addresses (at least on firefox, see https://1.1.1.1/), so that's actually a pretty neat solution.

> What if we could have first class SSL certs for IP addresses?

They're not routable.

What does this mean?

What's the next hop for a cryptographic hash? With IP addresses, you have a heirarchy: You match on a prefix to find the router to handle the next path, and that one matches on a longer prefix to find the next hop, and so on.

That allows you to have routing tables that don't include every single host on the internet. This is what allows efficient routing to happen.

Couldn't the client send SNI after the DH and then the server authenticate the secret? That way MITM would always be detectable at least.

> Couldn't the client send SNI after the DH and then the server authenticate the secret?

That means you can't use sni to route your request to a different server.

Yes, whatever is serving on that interface will have to terminate TLS. Or somehow pass the session information to the proxied server, or ask the client to reconnect, or do some kind of tls tunneling from the client to the real host. I don't think any of those are unreasonable options.

> But that’s vulnerable to MITM

It is if that’s all you’re trusting, but you get to check the validity of the cert, so someone could MITM a TLS 1.3, but it wouldn’t do them much good as all they would get is a request for a certificate, then the normal TLS certification steps must proceed. Without the certificate private key the rest of the handshake would fail.

sure, they're not going to MITM your http connection, but they will be able to MITM your certificate connection, which allows them to discover what site you visited, which is the same problem that SNI has.

They can do this, but your browser would retroactively notice that it happened and go "holy shit that was bad, you should complain to someone about it". This does not solve for all threat models, but it does avoid the "snoopy ISP".

There's domain fronting [1] and http/2 certificate frames [2] - they are conceptually similar.

[1]: https://www.bamsoftware.com/papers/fronting/

[2]: https://tools.ietf.org/html/draft-bishop-httpbis-http2-addit...

both of them seem to use the concept of "connect via a fake domain name, then connect to the real domain". i'm not sure how this is scaleable for everyday browsing. you might be able to find the fronting server for wikipedia, but how are you going to find the fronting server for every website you're visiting? this solves the problem of censorship, but not the problem of ISP surveillance.

> you can probably do some sort of DHE

Could the browser send a symmetric key encrypted in the public key of the target website, as part of the initial challenge?

The point is you don't know what the public key of the target website is. You find out by asking for it, and then you verify it's authenticity by checking the signature. Before you connect all you know is the domain and the keys of CA's you trust.

Ah, right. Thanks.

Russian here. Entries in gov's blacklist of sites should include IP addresses, domain names and optionally URLs. SNI isn't that helpful for ISPs because they could block traffic by IPs rather using DPI (IIRC only one NIR is using it, but for DNS rather than TLS itself).

For sites like google, blocking IPs would meet resistance.

This situation is covered with a whitelist of IPs and domains (year ago it became official after exploitation of vulnerability in how blacklist register works, before it was on ISPs, Youtube was banned by some ISPs quite a few times), including .google.com, .youtube.com and other Alphabet's domains, *.facebook.com and some others.

So effectively, if you post something on Blogger it cannot be taken down, because the whole Google would come down with it.

Still, encrypting SNI hides quite some information (were you searching, watching youtube, reading blogger, was it image search, maps...?)

Rechecked the list, only https://*.youtube.com and (whooping) .google. are inside [0]. [0]: https://storage.googleapis.com/smisc/%D0%A1%D0%BF%D0%B8%D1%8...

There's nothing good about breaking DPI. Instead of blocking a single site you'll end up blocking entire IP address. I'd even suggest an optional extension of HTTPS which allows to put entire URL as unencrypted part of the request. Censorship systems usually block content by individual pages. Currently with HTTPS it's not possible to block individual page, so an entire website is blocked.

TLS and HTTP are different things. TLS is being used without HTTP in lots of cases.

Besides, even if such extension had existed it would've been easy to write X in TLS header and Y in the HTTP payload to circumvent the ban, like the domain fronting[1] trick currently being used by e.g. Signal.

[1] https://en.wikipedia.org/wiki/Domain_fronting

That would be such a bad idea, lots of websites send data that should be secret on the query parameters.

Services like google share IPs amongs their services. If SNI was encrypted, youtube.com could not be blocked unless the entire IP space of google is blocked (which would be very hard to do since nearly everyone relies on gmail).

Kazakhstan blocked major part of gmail functionality at one point of time. You couldn't download attachments, images didn't work, may be something else. I think they tried to block blogspot. but shared IP broke gmail. It was broken for months, nobody really cared except people pointlessly ranting on forums. Those, who needed working email, migrated to other providers or used proxy. I'd like to live in the world without censorship but I don't see this happening, so I'd prefer to minimize censorship damage at least.

Not every DNS query is going to be followed by a HTTP or HTTPS connection. You also have queries for other protocols; queries which are never followed by a connection because the response was "this name doesn't exist"; "leaked" queries for internal hostnames; queries which were just to check if a name exists; and reverse (PTR) queries.

While for absolute privacy this makes sense, from a lazy ISP dev perspective, why log packets/IPs if you can get marketing data straight from your DNS servers? Surely ISPs have taken this easy approach while encryption has been only for fringe users?

On the other hand, if I were a curious and amoral ISP dev - I'd consider the people circumventing the "easy approach" to be _much_ more interesting to snoop on...

ISPs want to sell advertising, or data to advertisers. Why bother trying to advertise to a few geeks who are probably running PiHole anyway? Especially since doing that multiplies the hardware requirements 100 fold.

Possibly because the people who you can sell that data to are prepared to pay way more per "product" than the people trying to sell you fast moving consumer goods or ICO de jour...

Wouldn't surprise me at all to find there's a market where intelligence services can purchase lists of TOR users - for example...

True, although what are they going to do with the data? If it’s primarily for selling to ad companies, a tiny slice of privacy minded people aren’t worth much.

Err, snooping on a teen visiting "naughty" sites isn't exactly interesting from any perspective.

Nah. DNS caching would prevent you from seeing every usage of the site. Much better to just log every source ip : dest ip.

IPs are shared, they don't necessarily tell you what site you're accessing.

IMHO, very few things the ISPs and their advertising customers care about would be using shared IPs.

Never thought of virtual hosts as a security feature! But, I guess it is!

The only thing you'll see is a list of CDNs and cloud providers.

I suppose that is true for smaller sites that don't have their own IP addresses but for larger sites you will be easily able to map it through reverse DNS.

Probably only for the very large. And even there I'm not sure if you can distinguish amazon from AWS, Microsoft from Azure and Google from Google Cloud. Facebook and Twitter should work reliably but even with a Facebook IP it could probably still be Instagram or Whatsapp.

Data mining is big money. They can glean in insane amount of personal information about you based on the sites you go, aside from the fact they already know who you are.

I'm not a 'networking' person, but am I wrong in believing a VPN would (potentially, with caveats) prevent your ISP from "being able to see which IPs you're sending packets to"? Wouldn't all packets look like they are going to and from the VPN?

As mentioned, that doesn't get around the VPN knowing where your traffic is going, and there are issues such as your VPN dropping and your system switching over as opposed to dropping the packets, compromising your privacy.

correct, only VPN connection visible to ISP, no content

sshuttle 0.0.0.0/0 --dns -r $server

don't forget --dns ;)

Kind of strange that Google's first result for "sshuttle" is a dead project (literally says "Wrong project!" in the title) that links you to the real one.

That is true in my case, but my ISP has in the past redirected various queries to their landing/search pages, which means that I simply don't use them anymore.

Not all TLS-enabled websites require SNI. I customised an https client so I dont use SNI unless a website requires it.

With all due respect, 100% adoption of SNI seems like some sort of popular myth among certain web forum commenters.

Perhaps we should do a survey of all websites found on HN on a given day and publish it. I would bet that the majority do not require SNI.

SNI-enabled browsers send the unencrypted hostname in the initial ClientHello frame. It's the first transaction in the protocol, and it's how the server decides the content of the ServerHello reply. There is no way to detect the ability to avoid SNI, or indeed any sensible and generally useful way to tell if a ServerHello varied according to the ClientHello SNI hostname without probing the server, which entails introducing roundtrips, and disclosing the hostname unencrypted at least once on the wire.

"There is no way to detect the ability to avoid SNI..."

Assuming one is using an SNI-enabled browser.

I dont use an SNI-enabled browser to make the first encrypted HTTP request.

In fact I didnt even say I was using a "browser". I said "https client".

For example, one can use an https client that has SNI disabled or which has no SNI code at all, or one can send any string as the servername in ClientHello.1 If the server responds with hostname not found, then retry using SNI and the desired hostname. IME, most TLS-enabled websites do not require SNI.

  1
  exec printf 'GET / HTTP/1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n'|exec openssl s_client -tls1_2 -no_ssl2 -no_ssl3 -ign_eof -connect 93.184.216.34:443 -servername SNI_NOT_REQUIRED

When you say "If the server responds with hostname not found", what are you talking about? Exactly which protocol are you refering to when you say "hostname not found" ?

Most web servers will just fall back to the default virtual hosts SSL certificate if no SNI header is present in the clients request... They don't reply "hostname not found", or "nope, no such host", or anything similar...

"They don't reply "hostname not found", or "nope, no such host", or anything similar..."

"hostname not found" was meant to be a general term for failure due to not sending the correct servername when it is required, not a specific protocol error. I apologise for not being more precise. What happens with the non-SNI clients I use in the rare case when absence of correct servername is fatal is that the connection fails. (Most times a correct servername, let alone any servername, is not required1 and the connection succeeds. Thats the point of the original comment: in a majority of cases, its possible to get the page content without using SNI.)

1 As in the case of example.com, for example.

However, I use a local forward proxy for TLS-enabled websites. The proxy returns HTTP 503 error when the connection fails due to SNI. Thus, I do get a consistent "server response" when this happens, albeit not from the remote server.

Since the ClientHello is sent in the clear, a MITM can simply reset the connection until the client retries with SNI. Again, there is no generally useful way to solve this

"... a MITM can simply reset the connection until the client retries with SNI."

That doesnt happen when I fetch https://example.com without sending a servername in ClientHello.

For the majority of TLS-enabled websites on the internet, that does not happen. I get the page content just fine witout sending a servername in ClientHello.

But I should send the servername in ClientHello anyway?

This reasoning I am too stupid to understand.

TLS 1.3 mandates it, doesn't it? It's safe to say it's near enough to 100% (of clients sending) to not be worth mentioning outliers like yourself.

Some of us have no use for our ISP's DNS servers, due to government-mandated cencorship.

I was addressing "privacy". It sounds like you have other reasons to not use your ISPs DNS servers. Fair enough.

I'm in the same boat. My ISP's DNS servers tend to be very slow and often unresponsive. As a result I've used googles (a bad idea, in retrospect) for the last 10 years or so.

> I've used googles (a bad idea, in retrospect) for the last 10 years or so.

That is a reasonable consideration, but Google is very specific about how they use and retain data collected by Google Public DNS. Assuming they are not lying, I don't think it's a significant concern. (Admittedly, their policy is not as good as Cloudflare's "no IP logging" policy.)

https://developers.google.com/speed/public-dns/privacy

TL;DR: Logs with IP addresses are deleted within 48 hours; permanent logs keep city-level location data, but no personally identifiable information. "We don't correlate or combine information from our temporary or permanent logs with any personal information that you have provided Google for other services."

There aren't many ISP DNS servers that aren't garbage in my experience. Most of them don't send NXDOMAIN. Many of them are slower than either Google or Cloudflare despite being theoretically closer.

Then switch ISPs. Mine sends NXDOMAIN just fine, and is with 0.632ms massively faster than what Google or Cloudflare offer.

>Then switch ISPs.

Hahahha, and then he said "Then switch ISPs", like we have more than one high speed choice where we live".

Then vote for politicians that help with that.

Due to laws designed for more broadband competition, I've got over 6 providers to choose from here in Germany.

They want a solution today, not in 20 years.

So if I make an ssh tunnel and use a remote DNS, my ISP can still log requests? How?

That's not what the article is proposing. Still, your home ISP may not be able to, but the ISP of the machine you're SSHing into can.

It is a social issue. Would you trust the government of Holland or would you rather try your chances with the Turkish government?

With the new legislation that's coming I absolutely wouldn't trust the Netherlands anymore... Something like Denmark seems like a better alternative.

What's the new legislation to be wary of? For the benefit of those using Dutch hosting services...

Well if you’re using a VPN then your ISP can’t see much. Some VPNs offer DNS too.

I've spoken to some folks that worked in the VPN provider industry... many of them aren't the bastion of consumer protection they claim/are perceived to be. With the exception of Tor (and even that has been found to have problems) I'm not sure "single-point" anything will really provide you with anonymity.

I think it really comes down to your threat model though and what tradeoffs you're willing to accept for anonymity (e.g. captchas, performance, etc).

I think the sweet spot for CloudFlare's offering is if you're in a country or service provider that takes liberties in overriding DNS responses.

Buy VPS and install your own VPN. It's much harder to spy on you in this setup and basically requires complicated targeted attack. I'm not sure if common networking setups for VPS record TCP connections, if they do, then VPS provider can record some important metainformation, but it's still not a lot. On the other side with VPN it's much easier to spy on every client.

Sure, however any warrant can get billing data from your hosting provider, or your credit card company will resolve directly to you.

But if your VPS is in a country that's not very friendly to your country, getting data from the hosting provider won't be easy.

I mean, if you’re trying to defend against a coordinate government attack, you’re boned anyway. They’ll just break into your house and install a sniffer, or arrest you, or make your life hell.

That’s assuming they can’t just get into your home network through zero days, which an individual has no practical defense against.

Well seeing as all credit cards are basically subject to US law, you'd need to find a VPS that is going to accept say Bitcoin for server space. Perhaps one that is going to accept cash in the mail.

Then hope that said provider is reputable enough to be up to date on their security, and honest enough not to just cave under pressure.

Realistically the VPS solution fails simply because there is no obscuring of traffic. We all know that security through obscurity isn't real security. However if a VPN provider has 1,000 users using their IP block than any specific traffic is harder to isolate to one user. -- Presuming they are honest and not keeping logs.

Running your own VPS means that all traffic is owned by you.

there's a huge difference between anonymity when someone is looking for you and anonymity in general.

As you've mentioned, if someone wants to track you through Tor, that's still potentially possible. But that's a completely different ballgame than "My ISP wants to track every last website I visit so they can pair that with my address/billing info to sell to advertisers". I don't think my ISP is going to go through all the hoops to find my Tor exit node, just so they can sell that to advertisers. Passive onlookers can be untrustworthy too.

The shades on my windows keep people from seeing me change, but if someone really wanted to see specifically me naked, they could probably enter my house and make the shades useless.

I still consider the shades useful.

VPN is just a remote ISP.

Of course you have more options, but it's not TOR.

Edit: I mean TOR only figuratively.

So? What if the VPN doesn’t know who you are? What if it’s your own VPN but others don’t know that?

The entire point of choosing a good VPN is to get the visible data off of your immediate ISP, since they know who you are, and into a more nebulous net, where others do not.

There are Tor exit nodes which monitor traffic see:

https://boingboing.net/2016/07/01/researchers-find-over-100-...

If the traffic is https, in theory they can't link any of that traffic to individuals.

If a party were to, by chance, to monitor both your entry and exit nodes couldn't they match the traffic by time & packet size, et al? Then use known techniques to match pages accessed (it's something like 85% accuracy IIRC).

That would match to individual IP, or potentially an individual if you're logged in.

This is a great way of thinking about a VPN, and how I describe it myself. If you have limited options on your choice of ISP, then a VPN allows you to expand your choices (excluding speed, latency, usage caps).

Same argument applies there then. Your VPN provider can already see what websites you're visiting, so use their DNS servers if you can. Don't add yet another third party.

The problem currently is that they aren't getting warrants!

What about running your own DNS server locally?

Your requests will go to the root dns servers, which then go the dns servers of the domains you request. But also it will cache responses locally (so if you make another request it won't even need to make an external request).

Yes your ISP can still see it but they can see all your traffic anyway.

Standard DNS is clear text. It doesn't matter if you use your ISP DNS server or not. Either way, they will see the DNS traffic.

Forward you DNS requests to servers using DNS with TLS encryption or with a VPN provider. That way the DNS requests can't be seen by your ISP.

Using a non-ISP DNS server isn't enough.

That won't work. All the ISP has to do is snoop port 53 and they can see your DNS whether you're using their DNS server or someone else's. You have to get the DNS traffic out of their visibility by using VPN or DNS TLS.

Not every site uses SNI. Most probably do not. Not every site uses custom DNS for their CDN, either.

Your ISP knows way less about you if you avoid their DNS. And they are the only ones that know your legal name and billing address, usually.

SNI is part of the first message a TLS client sends to the server - the Client Hello. TLS clients that support SNI (including all modern browsers) will typically always send the SNI extension, regardless of whether the server supports or makes use of SNI.

That's why I use IE6: for Privacy reasons.

If what you say is true -- on top of that, your ISP can also (in theory) fingerprint you as someone who is avoiding their DNS servers.

We have to plug many holes, encrypted DNS plugs one, encrypted SNI will plug another.

You most likely also get faster DNS lookups by using your ISP's DNS servers.

Depends a lot. My ISP's (both mobile ISP and DSL) have pretty slow DNS providers. My mobile connections were significantly quicker after I switched to using VPN with Cloudflare DNS as resolver (or even the local resolver, though that is normally a bit slower than Cloudflare/Google DNS due to caching)

Not necessarily. Back when I used Comcast I got much faster browsing speeds by using a proxy over a VPN to a linode server, even though that server was in another state.