Now, the way this usually works is things like https://aa.net.uk/ where the browser makes a connection and as part of that connection its says it wants aa.net.uk so the server knows to serve the certificate and key for aa.net.uk.
The problem is that the name of the service (SNI) is in the clear and so some censorship systems can spot this and block it.
Now, we have some generic hosting environments. Cloud services. The nice thing is they have loads of IP addresses for all sorts, so hard to block.
Domain fronting fools this but sending a different SNI (asking for a specific certificate, in the clear) that is "OK" and then talking to a server that is not the same as the SNI.
This fools censorship systems.
Some cloud services are blocking "domain fronting" like this (why?).
OK this is hard to explain... We could do SNI after DH logic, making it so the service you want is encrypted. But as that is before you authenticate (as you cannot authenticate yet as that depends on SNI) it could be "man in the middle" but if it is then the next step of authenticating will fail.
It is like Heisenberg - you can either see what "domain name" is being requested, or you allow the connection, one or the other.
So the logic is simplified - your have two choices :-
- You can detect what someone is accessing (see the SNI)
- You can allow a connection to work
Basically no way to detect it and allow it to work. It is one or the other, only!
Does TLSv1.3 do this, I have not checked. If not then maybe TLSv1.4 will.
Clearly this is possible, and necessary, ASAP. It seems a real shame to me that the SNI was ever "in the clear".
Sounds like one for a "proper" conversation at some point, but strikes me that, if we wanted a more censorship-resistant, more privacy-preserving, Internet, we probably wouldn't be starting from here?
ReplyDeleteWould it be a solution to make an initial connection using a generic server certificate (for the default domain, or no domain in particular), then perform SNI and switch to the domain's specific cert?
ReplyDeleteFirefox introduced "DNS-over-HTTPS" under the guise of increased privacy, so I do not see why they could not implement something like you suggest as well.
DeleteIn TLS versions up to and including TLS 1.2 all the handshake steps are in the clear, so not only SNI but also the certificate sent back by the server. This allows a middlebox to close connections that reach a server which proves it is foo.example, even if the client said it wanted bar.example
ReplyDeleteIt also allows middleboxes to say "Oh, www.hsbc.co.uk, that's a banking site, I will stop peeking" without relying on (untrustworthy) data from the client.
In TLS 1.3 (unless it changes after Last Call which it theoretically still could) only the first message from the client and server are clear, the rest of the handshake is encrypted, and the server immediately after replying in the clear to finish encryption setup sends its certificate encrypted. However yes, SNI is still clear because as you observe there's no way for us to encrypt it and send it only to someone who can only prove their identity to us after we send SNI...
There is an Internet Draft on the work done so far in figuring out how encrypted SNI might work in the future. It will definitely cost an entire roundtrip, whether that's worth it depends on your perspective and circumstances.
TLS 1.2 is designed to cost 2RTT to do initial setup and 1RTT for re-connections. In practice many sites allow "False Start TLS" to do 1RTT initial setup and 1RTT reconnection. In TLS 1.3 it's 1RTT initial setup, and either 1RTT or 0RTT reconnect, with 0RTT only feasible where replays don't matter (e.g. fetching favicon.ico doesn't matter, charging $500 to my VISA card definitely does matter) and so it should never be enabled by default.
The reason why people are interested in securing SNI is that you can replace the word middlebox with MiTM and the fact that it can be any box between the two points (or even off path with ARP or BGP poisoning).
DeleteI chose the neutral word "middlebox" quite deliberately because these facts about them are true regardless of whether you think (as I do) that they're a bad idea.
DeleteIn most cases people interested in encrypting SNI (it's already "secured" in the sense that you can't tamper with it in TLS 1.3, if you change anything about the handshake on the path between client and server the transcript verification step fails and the connection is abandoned) are interested because they desire NOT to have an adversary who is very much on path eavesdropping their SNI. This is often an employer or state adversary although it could be your ISP. Off path adversaries generally have something more nefarious in mind than snooping your SNI.
If there is a version of TLS that encrypts the SNI indication, states that want to censor can just block that version of TLS.
ReplyDeleteAlternatively, states that want to censor can choose to overblock, by blocking any IP address used by Signal regardless of the collateral damage on Amazon etc. Amazon would then have the choice of what to do. It's a company trying to make money, so it would probably either stop providing service to Signal or move Signal to different IP addresses so the country can block just those IP addresses. Alternatively, if Amazon chooses to cease providing services to the country, that's Amazon's choice and all the local vendors will be very happy about that.
Fundamentally, there is no technical solution to the problem of censorship. There may be technical hacks that work for a little while until the country identifies and blocks them, but the censors will always block them in the end. Censorship is a political problem that needs a political solution.
There is some decent downgrade protection in TLS1.3 - basically it includes a cipher suite to signal "By the way, I tried TLS 1.3 and it failed" in a safe way for TLS 1.0-1.2. If the TLS 1.3 server gets this signal with a 1.2 handshake, it should do angry things (Presumably implementation defined, can't recall the details and it's too late to read RFCs).
DeleteThe Internet Draft that I mentioned earlier specifically includes the fact that we should assume our encrypted SNI connections will be blocked if they can be distinguished from others, and therefore they must be indistinguishable.
DeleteIn particular this means the encrypted SNI can't be transmitted until after we've begun sending encrypted data to some specific server whose identity we've verified. So this server acts as essentially a proxy, our SNI always says we want to talk to the proxy server, but inside the TLS connection we then send another SNI for the real server we actually wanted to talk to.
You are correct that overblocking is always an option. But it has a terrible economic and potentially political cost, collateral damage isn't just for the corporations outside, it damages your ability to get stuff done too.
Steve: For correctly implemented TLS 1.3 peers a downgraded connection aborts (specifically it causes "illegal_parameter" which is an abort). It doesn't use SCSV (the cipher suite added to TLS 1.2 for this purpose) but instead hides a marker in eight of the bytes labelled "Random" during Hello. Since these bytes were labelled "Random" no middleboxes try to interpret them.
DeleteIf a MitM is trying to downgrade our connection, we should assume the downgrade allows them to achieve something nefarious we would otherwise prevent, therefore we cannot allow this.
The effect for an end user is the same thing an attacker in this position would be able to force anyway - you can't reach the server at all, they are blocking it.
Aah yes, I recall the random in the final release now. I think they tried SCSV in earlier drafts, but there have been many, and I've not had many customers ask me about TLS 1.3 yet
DeleteSadly the interests of corporations and governments seem to be winning in ownership of the internet.
ReplyDelete