7 ms·

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 iss

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.

deepstack 5y ago
one of my big issue of placing google analytics or some kind of font js on your web site!
ianpurton 5y ago
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/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
- Asmod4n 5y ago
  Oh, that looks cool.
- goalieca 5y ago
  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.
  - hanniabu 5y ago
    Banks are never a good example for security. I know mine, which is a big name, still doesn't support OTP 2FA.
    - goalieca 5y ago
      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.
- technion 5y ago
  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 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.
  - ianpurton 5y ago
    Yes, I just looked at the source. That leaves them open to an attack, but I guess they trust google. Fingers crossed.
  - throwaway888abc 5y ago
    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.
perttir 5y ago
If the attacker can replace the code inside your web application, then you have security issues somewhere else than in your application.
- Asmod4n 5y ago
  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.
  - JCWasmx86 5y ago
    Kazakhstan was it I think
  - Jiocus 5y ago
    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_attack https://en.wikipedia.org/wiki/Kazakhstan_man-in-the-middle_a...
    - sneak 5y ago
      All other browsers have inferior trust store.
px43 5y ago
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/ https://docs.ipfs.io/concepts/dnslink/
bawolff 5y ago
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.
- harporoeder 5y ago
  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.
- bronco21016 5y ago
  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.
- dspillett 5y ago
  > 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).

deepstack 5y ago

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

ianpurton 5y ago

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/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

Asmod4n 5y ago
Oh, that looks cool.
goalieca 5y ago
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.
- hanniabu 5y ago
  Banks are never a good example for security. I know mine, which is a big name, still doesn't support OTP 2FA.
  - goalieca 5y ago
    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.
technion 5y ago
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 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.
- ianpurton 5y ago
  Yes, I just looked at the source. That leaves them open to an attack, but I guess they trust google. Fingers crossed.
- throwaway888abc 5y ago
  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.

perttir 5y ago

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

Asmod4n 5y ago
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.
- JCWasmx86 5y ago
  Kazakhstan was it I think
- Jiocus 5y ago
  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_attack https://en.wikipedia.org/wiki/Kazakhstan_man-in-the-middle_a...
  - sneak 5y ago
    All other browsers have inferior trust store.

px43 5y ago

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/ https://docs.ipfs.io/concepts/dnslink/

bawolff 5y ago

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.

harporoeder 5y ago
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.
bronco21016 5y ago
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.
dspillett 5y ago
> 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).