Hacker News Reader

Comment by Pxtl | Hacker News Reader

Yes, but browsers give huge warnings about password fields on non-SSL sites. Password in the clear won't happen with any major website.

View on HN

If the site is non-SSL, then there's nothing stopping somebody in control of the network from replacing all "password" fields with plain "text" fields, and then applying a custom font to them so every character entered is displayed as a "•"

That's basically what a password field already is. That would make no difference to anything - the password would be sent over the network in exactly the same way either way.

Right, but some browsers display a small warning message when you select a password field on a non-https page [1]

If instead of a password field it's a text field with a custom font, no such warning will be presented.

[1] https://blog.mozilla.org/security/2017/01/20/communicating-t... http://http-password.badssl.com/

No. The point of switching out a password field for a text field is to prevent the browser from warning about the existence of a password field on a non-HTTPs secured page. This is a well known, and old trick.

There's a little "not secure" at the top in Chrome, something most users will simply ignore.

Not so little when the user is also typing into a password field

I can imagine an HN commenter scrutinizing things when encountering that warning, but it's not very actionable for anyone else.

"Ah, okay, it's not so secure, whatever that means... but I still want to login and do what I set out to do."

Do they? I don't think so...

Try http://login.ebiquity.com

Do you see any warnings in your browser? I see no warnings in Chrome.

This is shown in firefox: https://files.catbox.moe/srdxhe.png

Interesting. With the latest version of Chrome on Linux I see no warnings whatsoever...

Sooooo easily ignorable.

Safari shows a red "Website not secure" in the address bar like this https://i.imgur.com/6DXzZ8G.png

Chrome changes the "Not secure" in the address bar from grey to red (and displays a red explamation mark symbol there) when data is entered into the form.

Which version/OS? I have the latest Chrome (69.0.3497.100) on macOS 10.13.3, and I see no red exclamation mark. Nothing changes or warns me at all when I start entering data in the fields.

https://imgur.com/a/Q0rZWOS

Maybe you have a browser extension, or setting turned on that I'm missing?

It's not enabled by default on the latest Chrome, at least for macOS (10.14). You can enable it using the #enable-mark-http-as flag, after which HTTP pages with password fields will look like this:

https://i.imgur.com/8kKWPjr.png

This is in Version 69.0.3497.100 (Official Build) (64-bit), Windows 10.

This happens regardless of extension (i.e. in an incognito window).

> so this was a linked comment from a thread 3 years ago....

While major websites already were on SSL, a lot of websites didn't and there were no browser warnings yet.

The box controls the DNS; majorwebsite.com points to any sever the attacker likes.

The only defense is HSTS/certificate-pinning, for sites previously visited with that browser & device (it’s a TOFU security model).

HN has HSTS, but not Reddit, or my credit union, or my local pizza place, or Kaiser Permanente, etc. etc. etc.

EDIT: I believe e.g. Chrome and Firefox bake in some major certificates, which would also likely flag MITM attacks, for those sites.

EDIT II: Someone responded below (since deleted) that you’d also need that cert to be signed by a CA your browser trusts, which is true. My explanation is faulty/poor. Better informed discussion of attacks further down the thread!

That's assuming the box can generate certificates trusted by the target machines - there's a reason the CN field exists.

The X.500 series Common Name is a weird thing to fixate on here. It's an arbitrary free text "name". The only reason it's even sometimes useful in the modern era is that the CAB BRs say it has to match one of the SANs so it will probably be a DNS name. But even there good luck, it took until 2016 or so to get the last stragglers to obey that rule properly without "misunderstanding" it and unlike SANs it isn't defined to be DNS A-labels so it may have arbitrary Unicode text.

Most browsers stopped even looking at CN or only do so for people's crappy home grown private CAs

Anyway, what makes certs trustworthy isn't the CN, it's a chain of two or more digital signatures leading to a trusted root. And the CN in that root, while it had to be truthful when written, may be twenty years old, so it's nonsense now.

Good luck finding anyone willing to issue you a cert that's valid for 20 years.

Leaf certificates have a maximum permitted lifespan of 825 days (down from 36 months)

But I wasn't talking about leaf certificates, I expressly mentioned this for the CN in _root_ certificates and it's pretty common for those to have a lifetime of ten, fifteen even twenty five years.

Here's an easy to remember example, https://crt.sh/?id=1 the first entry in the crt.sh database.

The Common Name on that certificate is "AddTrust External CA Root". So... who are AddTrust? I actually have no idea. This root is today controlled by Comodo, a CA in the United Kingdom but you'd never guess that from the certificate.

> That's assuming the box can generate certificates trusted by the target machines - there's a reason the CN field exists.

If you're dumb enough to install one of these boxes on your network, you might also be dumb enough to install an attacker-provided root certificate on your PC.

But if you ask your user to install a CA, why not simply ask him to install malware?

Is it to circumvent antivirus?

Reply on news.ycombinator.com