Hacker News Reader

Comment by Asmod4n | Hacker News Reader

The main issue I still see with JavaScript crypto in a Website session is how you can verify the Code running in the Browser isn’t tempered with.

I got no issues with it inside a browser extension, because a Website cannot change the Code running there, correct?

What I mean is, an advertisement could simply override the crypto API and do whatever it wants with it.

View on HN

You generally wouldn't put adverts on a site that's dealing with security.

You should also add subresource integrity as a defence in depth. https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

Oh, that looks cool.

There’s many security sites that load tons of external scripts. My bank is one such example. Even if those third party trackers and such are trustworthy there remains the whole supply chain attack consideration.

Banks are never a good example for security. I know mine, which is a big name, still doesn't support OTP 2FA.

Banks, Enterprise management, ... these are all guarding extremely valuable assets so i considered them security websites (not sure what is more security relevant other than the master email account we all have). They are written in a way that is hard to secure through CSP, disabling javascript, etc.

I know you or I or someone on HN talking about secure environments wouldn't put adverts on a site. But I just checked the first thing I could think of (https://www.coinbase.com/signin) and I can see Google Ads right there. I don't want to sound like I'm calling them out specifically because I'm sure what I'm looking at is entirely normal.

Yes, I just looked at the source. That leaves them open to an attack, but I guess they trust google. Fingers crossed.

It unfortunately apply also to many banks, airlines etc. All the conversion tracking, retention, ads, various third party sdk etc.etc. has full access to user information.

You verify it with TLS.

But then that raises the question of why you need crypto if everything is already encrypted and verified via TLS.

There are probably a couple obscure unique usecases (maybe if you're doing some p2p stuff with webrtc), but i'm pretty convinced client side crypto on the web is useless 99% of the time.

Client side encryption is still useful for webapps (or even proprietary apps) for example in apps like protonmail. At any time the company could send a payload that would extract the keys and pwn a user. But what it does provide is the guarantee that if they start non malicious, but later become malicious the scope of their capabilities are limited. If you don't log in to some historical account there is nothing they can do the attack has to be active. Similarly continuing on the example plaintext emails are encrypted when they are received by them and stored with your key. You could argue "well they could just not encrypt them". But any emails that they did encrypt while not malicious are still outside of their power if they change.

Bitwarden, and all web based password manager clients, rely on client side crypto for ensuring the data is not viewable by the service provider.

I'd argue that I would like to see more client-side crypto. I'd prefer my data to be stored encrypted and inaccessible to third parties such as Google. Google Drive or Dropbox would get my business back instantly if they supported client-side encryption of data. Of course, in Google's case, that would completely break the business model of mining us for every ounce of data.

> But then that raises the question of why you need crypto if everything is already encrypted and verified via TLS.

Depends where the TLS path terminates and what your threat model is. If I send a message via a service (an email via gmail.com for instance) the message is only protected by TLS as far as that provider. If the content itself is encrypted as well as the transport (and that provider does not know the keys) then the message is still protected at that point. This could be important for code sending data via an API proxy of some sort.

Also remember that the user of the browser might not have control over what certificates are trusted for HTTPS purposes. If they are operating in an environment where a local CA certificate is installed and that is used by a transparent proxy to enable them to inspect otherwise secure streams, the application protecting the content as well as the transport may protect against that (though you'll be wanting to use PKI here - otherwise you have a key distribution problem).

Imagine a world where the (signed) DNS response contains a root hash of the contents of the page you are visiting.

If the page is dynamic, not everything can be linked into that hash, but paired with CSP you can 100% guarantee that any code that executes is coming from a trusted source.

Then there's technologies like DNSLink for IPFS that obviate the need for this altogether, since the DNS response just contains the hash of what you want, and you ask IPFS for that hash, and anyone who's got it can deliver it to you.

https://docs.ipfs.io/concepts/dnslink/

If the attacker can replace the code inside your web application, then you have security issues somewhere else than in your application.

I forgot which state does it, but there is at least one which intercepts all web traffic and runs it through MitM Proxy’s. I believe it’s citizen are forced to install their root certificate too.

Kazakhstan was it I think

Maybe you're thinking of Kazakhstan. Important to note that citizens had to install a root certificate for this to succeed, and even Then major browser vendors took action to invalidate it.

https://en.wikipedia.org/wiki/Kazakhstan_man-in-the-middle_a...

All other browsers have inferior trust store.

one of my big issue of placing google analytics or some kind of font js on your web site!

Reply on news.ycombinator.com