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".