[hguant]

>Everything should be encrypted and authenticated through PKI when using any website that accepts login details.

Yes, everything SHOULD be like this. I should be able to trust my neighbors and leave my doors unlocked as well, and I should be able to have faith in my elected officials. And yet...

The other issue is that you can connect to a website that implements HTTPS correctly, and still be borked if that site doesn't implement HSTS properly - there are tools that implement HTTPS downgrading on Kali.

>I still don't understand how this device could steal login details...Whenever I visit a website with an expired certificate, for example, Chrome gives me a big red warning banner before allowing me to continue to the site.

The problem comes when your corrupted router messes with DNS and sends you to https://evil.chase.com, which has a pixel perfect mock up of a chase bank login screen, and a perfectly valid cert.

[jugg1es]

I'm disappointed that's not a real website

[westpfelia]

It is a real website he just got the URL wrong. Its supposed to be https://www.chase.com/

[EADGBE]

I live for these kind of zingers!

[gorgonian]

Of course it's not real. Its a subdomain of chase.com. Parent should've said something like chase.evil.com.

[tomsmeding]

If the user hasn't visited the subdomain evil.chase.com yet, a http downgrade attack (https://news.ycombinator.com/item?id=18090419) would maybe work.

[hunter2_]

That's not a downgrade, but a lack of upgrade. A few comments back said https://evil but it would have to instead be http://evil assuming no rogue root cert is installed.

And requires that if the user had visited chase.com, that chase.com not have includeSubdomains in their HSTS header.

[deaps]

So to prevent a downgrade attack before a first connection is made, not only does the domain need to "includeSubdomains" - and have a valid lifetime (maybe of at least 31536000 seconds, or 1 year [this may just be a government standard]), but they'd also have to send the preload directive in their HSTS header and have been preloaded by that browser platform. If the domain is not preloaded, that first connection is required to get the HSTS information to the client in the Strict-Transport-Security header.

[hunter2_]

Perfectly valid cert how? Assuming no theft of a chase private key.

[hguant]

Perfectly valid cert for the evil.com domain - someone below pointed out that I flipped the domain names.

In reality the "evil" page would look something like "https://www.login.chase/login?id=DEADBEEF/.evil.com". For a non-trivial number of users, that's enough - "I see the nice green lock, I see chase, and some crazy web address characters that are always there".

[SamBam]

Huh? "https://www.login.chase/login?id=DEADBEEF/.evil.com" wouldn't go to evil.com, it would go to login.chase. "chase" is the TLD of that URI.

Unless you're doing something super clever with characters that I'm not understand, that's not how urls work. ".evil.com" is clearly part of the query parameter.

[notriddle]

Assuming they're not doing anything weird with Unicode, the evil pi is probably running its own DNS server, intercepting the traffic intended for normal DNS, and basically creating its own TLD the same way you would normally do localdomain. The evil.com part is redundant.

[SamBam]

Sure, that's a totally different scenario than tricky-looking urls.

[closetohome]

This seems...a little unnecessarily pedantic. It's an example of a well-known URL obfuscation technique -- we all understood what he meant.