Hacker News Reader

Comment by Animats | Hacker News Reader

We need MITM detection in the browser.

Yes, it's possible. The crypto bits the host is sending are different from the crypto bits the client is receiving. There are several ways to compare those, despite what the MITM box is doing. Out of band channels, timing, and order of data can be used.

I sometimes refer to HTTPS Everywhere as "Security Theater Everywhere". Before the mania for HTTPS, many sites only used HTTPS only for crucial transactions such as logins and credit cards. Those were infrequent enough that they didn't have to go through a CDN. Now, with HTTPS Everywhere, there's no distinction between the stuff that has to be hidden from observers, and the stuff which only needs something like Subresource Integrity to make sure it hasn't been messed with. So now the secure channel over which credit card numbers and logins are passed is exposed at the CDN.

View on HN

It's not safe to do only logins over HTTPS because if the initial site is served over HTTP, an attacker could rewrite the URL or inject JavaScript to leak your password.

Also, once you're signed in, every request sends a cookie which is also valuable to steal as it's an active session.

Every request needs to be encrypted. We haven't made TLS worse by deploying it everywhere.

Logins? 99% of the websites I visit don't have user accounts.

Not even for the person managing them?

/wp-admin

There is a larger number of threads we are opposing. I want everything over HTTPS because that how I know its actually the site that I wanted.

How many more cases do we need where some stupid ISP or middleware puts ads into other peoples webpage. Not to mention that those ads might also be a security problem.

Privacy is another issue that HTTPS Everywhere at least helps considerably. The NSA literally tcpdumps the internet and uses sophisticated tools to analyse it. I prefer to have a internet that makes it hard for the NSA and company.

> I want everything over HTTPS because that how I know its actually the site that I wanted.

That's why the poster said "the stuff which only needs something like Subresource Integrity to make sure it hasn't been messed with".

We have MITM detection in the browser. It's called certificate validation.

Browser certificate validation hasn't been as simple as "check CA signature" for close to a decade, and even a decade ago you could configure your browser to trust only certain CAs, or, through the certificate exception manager, only certain specific certificates.

All of this functionality breaks MITM proxies.

You can request a second opinion attempting to detect MitM via JavaScript using snuck.me:

https://jlospinoso.github.io/node/javascript/security/crypto...

Most of the usual client-side JavaScript crypto caveats apply: Of course, all bets are off if the man in the middle is also a man in your device. You should give up any expectations of privacy in this case.

You can prevent MITM from the browser - you 'simply' use Whitebox Crypto to create a secured channel - (shameless plug Irdeto who I work for sell this as solution https://irdeto.com/payments-and-banking/cloakedjs-code-prote...)

In that case even if you MITM it - all the bad guy gets is encrypted (AES) data. Whitebox does sound a bit like black magic, but it's widely deployed (over 5 billion devices for Irdeto's) and add a nice layer to ensure that you're actually talking to the end users browser, and it's your code that's running on it.

Snake-oil. If I MITM, I'll just add my own code that copies the plain-text to my server, I don't need to break any encryption. It's nothing more than an obfuscation layer.

We did think of that :) - we can detect your tampering with the forms we protect. But that said it doesn't stop everything if you can install a keylogger, or get the user to enter data somewhere else we can't stop it and it does depend on where in the user journey you try and protect things, as someone else here has pointed out if any of the journey is HTTP (or HTTPS being MITM) then they can send the user somewhere else.

However I'd also argue you don't actually need to stop people grabbing the data. Noticing achieves a large chunk of that, as (for example) I can notify the credit card system it's happened.

If you want to see exactly what it does and doesn't do see https://resources.irdeto.com/payments-banking/solution-overv...

I am confused, initially you said "you can prevent MITM" now you say "doesnt stop everything...(HTTPS being MITM)". So your claim is that your product can or can not prevent MITM?

It can prevent MITM IF it's loaded in client page (defining MITM as network interception).

It can't stop keyloggers, people looking over your shoulder, malware in the browser (MITB)/plugins as it still sits within the browser sandbox. It can in some cases detect that, and in some cases hinder it.

An attacker can stop it loading by MITM the connection, but then the site can't work against it's APIs as the solution also verifies as data goes into those API's the encryption is present and the code isn't tampered. If it's tampered a business rule is applied to decide what to do, either stop the messages, OR pass it back to risk management systems (very common in finance).

Frankly, regarding MITM, that paper is just nonsense. How can it "ensure contents of a message are secure on the 'wire', by encrypting with a secondary scheme between the JavaScript client and the server", when you can't even guarantee that the signing and encryption code isn't tampered with in-flight?

And you can't guarantee that you can notify either, and for the same reason. The code that leaves your server won't be the code that actually runs on the client - it'll be a mutated version that will say "everything is OK" and acts normally to your server while it sends all the data somewhere else.

Nothing has changed since [1] was written; I don't see how that is anything but DRM promising more than it can deliver.

[1] https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...

You can still do the exact same thing: have a specific (sub)domain for those crucial transactions, while the main domain gets served by the CDN.

Alternatively, and in my opinion better, is to have a (sub)domain for static assets, served from the CDN, and keep the main one free from man-in-the-middle.

Then those organizations using MITM boxes will install a patch or special modified browser on their members' computers instead of installing a certificate. What's the difference? They still control the computer and can bypass whatever security it has.

Servers are better poised to detect it. Caddy can serve sites that warn browsers of HTTPS interception: https://github.com/mholt/caddy/pull/1430

Reply on news.ycombinator.com