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 = a
  • b = ḃ
  • k = κ

Therefore, www.facebook.com --> {www.facebook.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.

  • 2
    Your question makes assumptions that make no sense to me. How can DNS spoofing bypass HSTS? FYI, the type of attack you're referring to is called a homograph attack. Jul 15, 2018 at 21:47
  • As DNS spoofing will replace the DNS with an entirely different domain name via DNS spoofing. However, this will be an IDN homograph attack, because of the lookalike characters. Circumvent is a better choice of word than bypass, this I agree.
    – safesploit
    Jul 15, 2018 at 22:51
  • I think you need to do some research into how DNS works. DNS spoofing can't change the domain name. Jul 15, 2018 at 22:54
  • Correct, it assigns a domain name to the IPv4 address. I choose to omit this as its general knowledge. Hence what I displayed above "facebook.com --> faceḃook.com" which outlines a "change" of the domain name via a rewrite, this altered DNS is then returned to the client. Recreating SSStrip+ to work in a more clandestine manner. This thread of conceptual rather than tool based!
    – safesploit
    Jul 16, 2018 at 9:53
  • "which outlines a "change" of the domain name via a rewrite" - This is the problem, DNS has no way to tell the client to change the domain. The closest is a CNAME record, but that's more of an alias than a rewrite. Jul 16, 2018 at 12:28

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .