Erik van Straten<p><span class="h-card" translate="no"><a href="https://westergaard.social/users/kasperd" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>kasperd</span></a></span> wrote: "What I cannot understand is why domain names typed in manually weren't automatically treated as https a long time ago."</p><p>As a matter of fact, they are - but insufficiently reliable.</p><p>Most modern browsers actually first *try* https if an http link is provided (*) or if one types, for example, "cisco.com" (without "") in the browser's address bar and presses the Enter key (which I've seen more than one security trainer do).</p><p>(*) For example, at the bottom of (notably!) <a href="https://www.cyber.gov.au/scams" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="">cyber.gov.au/scams</span><span class="invisible"></span></a> , the link under "visit the IDCARE website" reads "http:⁄⁄www.idcare.org⁄". Of note: the latter website does not even support HSTS (see <a href="https://internet.nl/site/www.idcare.org/2865709/#control-panel-10" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">internet.nl/site/www.idcare.or</span><span class="invisible">g/2865709/#control-panel-10</span></a>).</p><p>Usually https attempts succeed. However, an *active* AitM (Attacker in the Middle), or an attacker who is able to alter DNS responses to the browser, can easily (temporarily) block https and force such browsers to try http - in which case they can emulate any website or redirect the browser to another one (that may support https).</p><p>Of another note, after fully reading the Evil Twin articles, the attacks that took place in that case (in airplanes and on airports) were somewhat different, from <a href="https://www.afp.gov.au/news-centre/media-release/man-charged-over-creation-evil-twin-free-wifi-networks-access-personal" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="ellipsis">afp.gov.au/news-centre/media-r</span><span class="invisible">elease/man-charged-over-creation-evil-twin-free-wifi-networks-access-personal</span></a> :</p><p><<< The AFP alleges that when people tried to connect their devices to the free WiFi networks, they were taken to a fake webpage requiring them to sign in using their email or social media logins. >>></p><p>So while connecting to WiFi, the victims were apparently IMMEDIATELY lured into entering their email-account credentials into a page on a fake website (probably not using federated auth such as "Log in with Google", because -IIRC- in that case the token will be bound to the domain name of the fake website, rendering it useless for the attacker to impersonate the user on a legitimate website).</p><p>That AitM-controlled website *may* have had a valid certificate - but that would mean that the domain name differed from the usual email account sign-in website (to mitigate: use a password manager that checks the domain name).</p><p>Of course the attacker could also intercept 2FA codes if they wanted (by using, for example, EvilGinx2 or some similar tool).</p><p>BTW I noticed a couple of bugs in Chrome that I'm considering to report to the Chromium team (however, a previous bad experience doesn't make me eager to do so):</p><p>1) With the "https only" setting in Chrome for Android enabled, closing the browser *DOES NOT* erase any http-allowed exceptions made for specific domain names (Firefox for Android does it that way - while Firefox for iOS does not seem to support "https only" at all).</p><p>Obviously this poses a risk if a remembered http connection is opened on an untrusted network.</p><p>I don't know whether the following "reset feature" is documented anywhere, but disabling the "https only" setting, followed by closing and restarting Chrome for Android, and then enabling "https only" again, seems to reliably clear the list of exceptions.</p><p>2) The "https only" setting in Chrome for iOS is *unreliable*.</p><p>If set to enabled, opening <a href="http://http.badssl.com" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">http://</span><span class="">http.badssl.com</span><span class="invisible"></span></a> will warn me (once), while opening <a href="http://citicouncil.amsterdam" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">http://</span><span class="">citicouncil.amsterdam</span><span class="invisible"></span></a> - or most other http-only websites (including scanning the QR-code on a can of Pringles -potato chips- which decoded into <a href="http://pringles.eu/1W9vz52" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">http://</span><span class="">pringles.eu/1W9vz52</span><span class="invisible"></span></a>), NEVER warns me.</p><p>3) The "trick" for clearing the list of remembered http domain name exceptions (which works in Chrome on Android) unfortunately does not work in Chrome for iOS. However, clearing all website data does - which probably also deletes all HSTS records, which is a bad thing because of bug 2).</p><p><span class="h-card" translate="no"><a href="https://infosec.exchange/@agl" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>agl</span></a></span> <br><span class="h-card" translate="no"><a href="https://hachyderm.io/@rmondello" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>rmondello</span></a></span> <span class="h-card" translate="no"><a href="https://infosec.exchange/@BleepingComputer" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>BleepingComputer</span></a></span> </p><p><a href="https://infosec.exchange/tags/Chrome" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Chrome</span></a> <a href="https://infosec.exchange/tags/ChromeForAndroid" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ChromeForAndroid</span></a> <a href="https://infosec.exchange/tags/ChromeForIOS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ChromeForIOS</span></a> <a href="https://infosec.exchange/tags/httpsOnly" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>httpsOnly</span></a> <a href="https://infosec.exchange/tags/HSTS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>HSTS</span></a> <a href="https://infosec.exchange/tags/AitM" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>AitM</span></a> <a href="https://infosec.exchange/tags/MitM" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>MitM</span></a> <a href="https://infosec.exchange/tags/EvilTwin" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>EvilTwin</span></a> <a href="https://infosec.exchange/tags/DNSAttacks" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>DNSAttacks</span></a></p>