5 ms·
From my understanding, it is easy enough to bypass HTTPS encryption if you need to intercept traffic for an attack like this. You only need to intercept and mod
by afuchs 6y ago
From my understanding, it is easy enough to bypass HTTPS encryption if you need to intercept traffic for an attack like this. You only need to intercept and modify the traffic for a website, not a specific website.
There are still websites that don't use HTTPS.
For websites that do use HTTPS, if they haven't configured something like HSTS, HPKP or Expect-CT, typing example.com into a web browser will make it will send an unencrypted HTTP request to http://example.com http://example.com. If the website's content is served only HTTPS, the server will most likely respond with something that redirects the web browser to the HTTPS version of the website (most likely a HTTP 301 or 302 status code). The initial unencrypted HTTP request can be intercepted and modified.
- c22 6y agoNot to mention if DNS isn't encrypted and you control the network you can just redirect requests wherever you want.
- ec109685 6y agoNot to a non-https website if the user is visiting a secure site. Apple should disable javascript for non https sites.
- aeternum 6y agoAbility to disable javascript for non-https would be a great security setting. Aligns well with Apple's goal for privacy and security as many wireless hotspots and even ISPs abuse HTTP javascript injection.
- tjoff 6y agoIronically, in response when people realize how good the non-javascript web is they will demand all sites be http.
- yonixw 6y agoLocation header still can redirect you to well-crafted HTTPs site, so it won't really help
- ec109685 6y agoGood point.
- bawolff 6y agoSorry to nitpick, but hpkp and expect-ct arent really relavent here (since browsers dropped support for hkpk, and expect-ct is now basically the default in chrome). HSTS is what is needed However, you only need 1 http website to pull off the attack, so its not really a problem that hsts is great at addressing since its opt i per server. The easy way to do this attack is control the local wifi, and make the login landing page malicious.
- tialaramex 6y agoExpect-CT does almost nothing. Safari and Chrome both have CT policies that are enforced anyway, Firefox doesn't implement CT yet (patches doubtless welcome). The remaining thing Expect-CT might do (I have not tested) is ensure that bad guys can't present a certificate with a date prior to Safari/ Chrome's enforcement deadline. That's a small and shrinking window. If bad guys can make a certificate dated February 2018 and valid until May 2021 that certificate will be accepted in Chrome despite not having any SCTs. A real one from that date probably does have SCTs but Chrome only required them in April 2018. Setting Expect-CT now might make Chrome reject that certificate for lacking SCTs if it was shown on a subsequent visit. A year from the now the window is closed, Chrome will reject a certificate that says it was issued more recently and lacks SCTs, and it will also reject a certificate that says it was issued longer ago, because that violates Baseline Requirements on validity periods. But for now a February 2018 certificate could be valid yet not require SCTs. All Google-owned TLDs are HSTS-pre-loaded, so if you use a domain in a Google TLD (e.g. example.app) then browsers always use HTTPS anyway. Unfortunately it's unlikely that many older, popular TLDs will pre-load HSTS so most users will be unprotected for the foreseeable future.