1

sslstrip and bettercap work “sometimes” on Chrome browsers on sites such as Facebook, Google, AOL, and other sites that use preload HSTS. Why does it work sometimes when it shouldn’t work at all?

schroeder
  • 123,438
  • 55
  • 284
  • 319
AznBoyStride
  • 39
  • 1
  • 4
  • 3
    *"Why does it work sometimes?"* - this is a claim without proof. Please show actual examples where sslstrip works against a domain on the browsers HSTS preload list, i.e. show that sslstrip works and show that the domain is HSTS preloaded. Note that for example not all of Google is on the preload list, i.e. www.google.com is currently while google.com is not. – Steffen Ullrich Jul 17 '18 at 04:54
  • @SteffenUllrich Clarification: `www.google.com` has HSTS but is not preloaded. – jub0bs Mar 04 '21 at 13:35

1 Answers1

4

According to the documentation, this works by rewriting HTTPS links to HTTP links with a different subdomain. Since none of these sites use the includeSubDomains directive, the browser won't use HSTS for these rewritten links. Using the includeSubDomains directive prevents this attack by having browsers force the use of HTTPS for all subdomains of a site, instead of just certain subdomains.

Normally this shouldn't work for preloaded sites, given that the preload list requires that includeSubDomains be specified, but it appears the list has made certain exceptions to that requirement, notably for Google and Facebook. Google has a long list of subdomains preloaded including accounts.google.com, docs.google.com, encrypted.gogole.com, etc, but google.com is not preloaded. Likewise Facebook has www.facebook.com, m.facebook.com, secure.facebook.com, and several others preloaded, but facebook.com is not. Thus if you're already on an HTTP site, sslstrip2 can rewrite a link from www.facebook.com to wwww.facebook.com to avoid HSTS.

While testing this I discovered that Firefox's preload list also differs from Chrome's more than one might expect. As noted here, Firefox's list is based on Chrome's, but Firefox does its own validation of the list. This results in cases like touch.facebook.com, where Chrome has includeSubdomains set to true in its preload list, but Firefox has it set to false (indeed when I just tested it the header I got was strict-transport-security max-age=15552000; preload).

AndrolGenhald
  • 15,436
  • 5
  • 45
  • 50
  • So `google.com` itself can be sslstripped? Isn't this risky for users who visit google.com first time? `facebook.com` is preloaded, check it [here](https://hstspreload.org). – defalt Dec 08 '18 at 06:34
  • 1
    @defalt Yes, in certain cases google.com can be sslstripped because its subdomains aren't all forced to HTTPS. Technically you are correct that facebook.com is preloaded, but not for HSTS. Google gave it a "[custom policy](https://cs.chromium.org/chromium/src/net/http/transport_security_state_static.json?g=0&maxsize=13996278&l=738)" (presumably at Facebook's request) that enables HPKP for all subdomains, but HSTS only for facebook.com itself and specific subdomains (but not for others such as `wwww.facebook.com` for example). – AndrolGenhald Dec 08 '18 at 14:56