Bypassing HSTS and Public-key pinning with lookalike characters

Question

Using lookalike character symbols to circumvent HSTS and public-key pinning with DNS spoofing via MITM Attack.

Redirect: facebook.com --> faceḃook.com

--

I have seen SSLStrip+ using the technique of adding another "w" to domains {www.facebook.com --> wwww.facebook.com} to circumvent HSTS and public-key pinning. However, this clearly shows a modified address. I feel it would be more clandestine to use lookalike characters to perform DNS spoofing.

In my full conceptualised idea every letter will have a substitutable set of lookalike characters:

• a = ａ
• b = ḃ
• k = κ

Therefore, www.facebook.com --> {www.fａcebook.com, www.faceḃook.com, www.facebooκ.com} Any of the above three should circumvent HSTS.

I can see mitigations by having HSTS preloading with HSTS no_redirect, this idea of no_redirect would make the browser prevent an HTTP redirect for known HSTS websites.

My question is how can this model of lookalike characters for circumventing HSTS be strengthened for greater clandestine nature. As modern Google Chrome displays "Not Secure" for HTTP web pages, which would be a big red flag.

Answer 1

I can see mitigations by having HSTS preloading with HSTS no_redirect, this idea of no_redirect would make the browser prevent an HTTP redirect for known HSTS websites.

A redirect is done by sending a HTTP response with code 302 or similar and the new location inside the Location header of the HTTP response. If a website is on the HSTS preload list the request for the original domain would already be done with HTTPS. This means that a successful TLS handshake need to be done before the HTTP request inside the TLS connection could be send and the HTTP response with the redirect could be received.

This means that in order to send the redirect the attacker would need to intercept the initial TLS connection successfully (i.e. MITM attack) by using a trusted certificate and its private key for the domain the user tries to visit. Attempts to do this with some self-signed certificate or certificate not matching the hostname and hope that the user will just skip any certificate warnings will not work since with HSTS no option will be offered to skip certificate problems.

But, if the attacker has already access to such a trusted certificate (maybe by hacking a CA) then there is no need to issue a redirect in the first place, i.e. the attacker could just continue to serve a different HTTP response (with fake content) for the original domain the same as you propose with the redirect.

Thus, the proposed no_redirect attribute for HSTS would not actually provide additional security.