An HTTPS connection sends the domain it wants to connect to in two layers: first unencrypted in the TLS headers, then encrypted in the HTTP header.
In a regular connection (even using a CDN), those two will match. Using domain fronting, you put a popular domain in the unencrypted part, and the real domain in a encrypted HTTP header.
Due to how they're implemented, the load balancers at Google and Amazon will ignore the first (unencrypted) layer, and will send the traffic to the correct server based only on the encrypted HTTP header.
Regular browsers always send the same domain in both layers, only a custom app like Signal can perform domain fronting.
> only a custom app like Signal can perform domain fronting.
Or curl, or openssl s_client. I'm still trying to understand domain fronting, and exactly what is being disallowed now. Do all of my CDN requests have to have identical Host headers and TLS server name indicators now? What if they're mismatched? Does the TLS handshake still succeed, and the traffic just doesn't get passed through the CDN server?
I'm still trying to understand domain fronting, and exactly what is being disallowed now. Do all of my CDN requests have to have identical Host headers and TLS server name indicators now? What if they're mismatched? Does the TLS handshake still succeed, and the traffic just doesn't get passed through the CDN server?
Well, the current conflict is with Amazon; your CDN might or might not object to domain fronting.
Amazon is not saying that they must match, they're saying that you can't use someone else's domain for domain fronting without their permission. That is, if the domains don't match, whoever owns the domain indicated in the TLS server name must give express permission to do that.
I don't think their infrastructure can actually block it, they just ban your Cloudfront account if they happen to know this is going on. So you can probably get away with it if you keep quiet and nobody finds out.
> Well, the current conflict is with Amazon; your CDN might or might not object to domain fronting.
Yeah, understood, I meant CloudFront specifically.
> I don't think their infrastructure can actually block it
If I terminate TLS at CloudFront they can certainly compare SNI with the Host header and block on any mismatches. This is silly of course, since there are legit reasons to do this.
In a regular connection (even using a CDN), those two will match. Using domain fronting, you put a popular domain in the unencrypted part, and the real domain in a encrypted HTTP header.
Due to how they're implemented, the load balancers at Google and Amazon will ignore the first (unencrypted) layer, and will send the traffic to the correct server based only on the encrypted HTTP header.
Regular browsers always send the same domain in both layers, only a custom app like Signal can perform domain fronting.