I'm looking for a specific answer regarding the TLS handshake in a scenario of domain-fronting. Following hensonsecurity and zscaler blogs I have noticed that a detailed description regarding the re-direct / routing scheme is missing when the CDN finishes the legitimate TLS hand-shake and it sees that the GET is to another domain that hosted in it. If there is a redirect command, is there a new ssl hand-shake with the domain itself (if it has imported its own private cert?)
2 Answers
Domain fronting works be misusing request routing implementation inside a CDN, which is responsible both for the outer domain O and inner domain I. With domain fronting the attacker uses the outer domain O as server name inside the TLS handshake (SNI extension), but uses the inner domain I as Host header inside the HTTP request inside the TLS connection. A passive deep packet inspection sees only the outer domain O and not the inner domain I. If the outer domain is acceptable the request will not be blocked by a DPI, even if the inner domain would be considered suspicious.
No additional TLS sessions and no redirects are involved here.
- 184,332
- 29
- 363
- 424
-
That I understand, but what happens when the domain inside the host got its own cert? – user281868 Aug 21 '22 at 10:43
-
@user281868: This does not matter, i.e. the cert is not used since the TLS connection is done for a different domain on the same server. – Steffen Ullrich Aug 21 '22 at 21:49
With domain fronting you use a "modified client", not a normal web browser or https library. This modified client makes the outer HTTPS to bear one destination, even though internally it is directed to someone else.
- 17,578
- 3
- 25
- 60