5 ms·

You may have seen this: http://matasano.com/articles/javascript-cryptography/ http://matasano.com/articles/javascript-cryptography/ The brief problem statement

You may have seen this: http://matasano.com/articles/javascript-cryptography/ http://matasano.com/articles/javascript-cryptography/ The brief problem statement is: Either you're on SSL, in which case, you have encryption from the client to the server. Or you don't have SSL, and a MITM attack can substitute your javascript with anything, rendering the scheme unsafe.

ionwake 12y ago
but cant you perform a MITM on SSL anyway?
- leereeves 12y ago
  It's possible, but usually prohibitively difficult. (Superfish was scandalous because made MITM attacks easier on affected computers.) TLS and SSL use X.509 certificates[1] to identify who you're talking with. They're cryptographically signed by a Certificate Authority (CA), who must be one of a list of CAs stored on your computer. A MITM attack requires something rather difficult, like breaking the cryptography algorithm, access to the CA's private key, access to install a new CA certificate on your computer, or an insecure CA already on your computer (like Superfish). Edit: As jacques_chester reminded me, it's not difficult for the owner of computer to set up a MITM server, but I don't call that an "attack". 1: http://en.wikipedia.org/wiki/X.509 http://en.wikipedia.org/wiki/X.509
  - jacques_chester 12y ago
    I'm working on a client project right now. Their corporate firewall MITMs all SSL traffic. Their standard OS images all have SSL and root CA certificates installed to make this happen invisibly. The client staff we're working with had no idea this was happening.
    - leereeves 12y ago
      Yeah, not many people know about the CA store, and even if you do, and check it, there are so many pre-installed certificates that it's easy to miss a new one. No one at the company had tried to use the network with a computer they bought for themselves?
      - jacques_chester 12y ago
        Their VPN is very restrictive (no Google, several CDNs are blocked so half the internet is broken) and hard to configure. So they just use the supplied machines. They learnt it from us because we have our own machines.
maaaats 12y ago
You forget one case: Here, the server will never know the content of the encrypted data.
- detaro 12y ago
  Unless it is the one delivering you faulty javascript. It does help if someone gets only read access to the server though (hacked user account, stolen backup, confiscated server...)
- new299 12y ago
  Unless the attacker has access to the server for a period of time, in which case they just replace the JS with their own code. Seems like there should be a way to sign the JS offline (away from the server) and prevent that, but I don't think there's any browser mechanism for that. I think that would be neat though.
new299 12y ago
Or you do both. If your using SSL you still have to trust the server, or anyone who gets access to it. Encrypting in browser at least means the server doesn't intensionally have access to the plaintext. That means if the server is stolen/ceased the plaintext can't be accessed. However you are right of course that it doesn't protect you against a malicious agent who has access to the server over a period of time. It seems like it should be theoretically possible to do that though, but it would require browser capabilities that we don't have at the moment.
- jacques_chester 12y ago
  > However you are right of course that it doesn't protect you against a malicious agent who has access to the server over a period of time. Or against starting with a malicious server.
josephg 12y ago
I love a lot of the outreach that Matasano does, but I strongly disagree with that article. Most of the points they make aren't fundamental problems of websites - they're just issues for poorly implemented websites. Some of it is out of date / plain wrong - for example, we've had a SRNG (window.crypto.getRandomValues) on the web since Chrome 11. Most of the rest of the complaints you could also reasonably level against installed apps with update mechanisms. The article compares web apps (and their update mechanism) with desktop apps (without their update mechanism). Then it points out flaws in update mechanisms in general (eg they can send you malicious code), then says the thats why the web is flawed. Yeah, nice try. The fundamental question is: How do you trust the code that I give you? No matter what platform you're on, at some level, you need to trust me. Lets say I'm writing a 'secure' todo list app. You have to trust that I'm not going to forward your todo list entries to any hooded figures. And I'm not going to change your shopping list to quietly add entries from my sponsors. Also both on the web and locally, apps can open mostly-arbitrary network connections and send any data anywhere we like. Its as simple as that. On the web, I send you code, you run my code, my code does something useful and might betray you. In native apps, I send you code (maybe via an app store or something). You run my code. My code does something useful but it might betray you. As far as I can tell there's only two fundamental weaknesses of web apps: 1. The JS isn't signed 2. The JS gets sent on every page load The combination of which makes it much more convenient to do spear-phishing type attacks. But that said, any threat that looks like "but on the web you might send malicious code to user X" is also true of other app update mechanisms. Even on the iOS App Store, nothing is stopping me from writing code which says `if (hash(username+xyz) == abc123) { send data to NSA(); }`. I can't think of any binary-downloading systems (app stores, aptget, etc) which would discover that code. And remember - desktop app code is potentially much more dangerous. Desktop apps can take photos with your webcam, record audio, record keystrokes and access every file in your home directory. Its definitely true that most web apps are poorly implemented - they dynamically load 3rd party JS and they don't use SSL / HSTS. Its also embarrassing how many desktop apps have simple buffer overflow exploits. But the solution isn't to go back to desktop apps - the solution is to push for better best practices on the web. In my opinion, the biggest security problem with the web is that most web apps store all your data in plaintext on someone else's computers. This is a problem that we we need to start addressing systematically via projects like CryptDB. Ie, we need more serious security work done on the web. Not less.

ionwake 12y ago

but cant you perform a MITM on SSL anyway?

leereeves 12y ago
It's possible, but usually prohibitively difficult. (Superfish was scandalous because made MITM attacks easier on affected computers.) TLS and SSL use X.509 certificates[1] to identify who you're talking with. They're cryptographically signed by a Certificate Authority (CA), who must be one of a list of CAs stored on your computer. A MITM attack requires something rather difficult, like breaking the cryptography algorithm, access to the CA's private key, access to install a new CA certificate on your computer, or an insecure CA already on your computer (like Superfish). Edit: As jacques_chester reminded me, it's not difficult for the owner of computer to set up a MITM server, but I don't call that an "attack". 1: http://en.wikipedia.org/wiki/X.509 http://en.wikipedia.org/wiki/X.509
- jacques_chester 12y ago
  I'm working on a client project right now. Their corporate firewall MITMs all SSL traffic. Their standard OS images all have SSL and root CA certificates installed to make this happen invisibly. The client staff we're working with had no idea this was happening.
  - leereeves 12y ago
    Yeah, not many people know about the CA store, and even if you do, and check it, there are so many pre-installed certificates that it's easy to miss a new one. No one at the company had tried to use the network with a computer they bought for themselves?
    - jacques_chester 12y ago
      Their VPN is very restrictive (no Google, several CDNs are blocked so half the internet is broken) and hard to configure. So they just use the supplied machines. They learnt it from us because we have our own machines.

maaaats 12y ago

You forget one case: Here, the server will never know the content of the encrypted data.

detaro 12y ago
Unless it is the one delivering you faulty javascript. It does help if someone gets only read access to the server though (hacked user account, stolen backup, confiscated server...)
new299 12y ago
Unless the attacker has access to the server for a period of time, in which case they just replace the JS with their own code. Seems like there should be a way to sign the JS offline (away from the server) and prevent that, but I don't think there's any browser mechanism for that. I think that would be neat though.

new299 12y ago

Or you do both. If your using SSL you still have to trust the server, or anyone who gets access to it. Encrypting in browser at least means the server doesn't intensionally have access to the plaintext. That means if the server is stolen/ceased the plaintext can't be accessed. However you are right of course that it doesn't protect you against a malicious agent who has access to the server over a period of time. It seems like it should be theoretically possible to do that though, but it would require browser capabilities that we don't have at the moment.

jacques_chester 12y ago
> However you are right of course that it doesn't protect you against a malicious agent who has access to the server over a period of time. Or against starting with a malicious server.

josephg 12y ago

I love a lot of the outreach that Matasano does, but I strongly disagree with that article. Most of the points they make aren't fundamental problems of websites - they're just issues for poorly implemented websites. Some of it is out of date / plain wrong - for example, we've had a SRNG (window.crypto.getRandomValues) on the web since Chrome 11. Most of the rest of the complaints you could also reasonably level against installed apps with update mechanisms. The article compares web apps (and their update mechanism) with desktop apps (without their update mechanism). Then it points out flaws in update mechanisms in general (eg they can send you malicious code), then says the thats why the web is flawed. Yeah, nice try. The fundamental question is: How do you trust the code that I give you? No matter what platform you're on, at some level, you need to trust me. Lets say I'm writing a 'secure' todo list app. You have to trust that I'm not going to forward your todo list entries to any hooded figures. And I'm not going to change your shopping list to quietly add entries from my sponsors. Also both on the web and locally, apps can open mostly-arbitrary network connections and send any data anywhere we like. Its as simple as that. On the web, I send you code, you run my code, my code does something useful and might betray you. In native apps, I send you code (maybe via an app store or something). You run my code. My code does something useful but it might betray you. As far as I can tell there's only two fundamental weaknesses of web apps: 1. The JS isn't signed 2. The JS gets sent on every page load The combination of which makes it much more convenient to do spear-phishing type attacks. But that said, any threat that looks like "but on the web you might send malicious code to user X" is also true of other app update mechanisms. Even on the iOS App Store, nothing is stopping me from writing code which says `if (hash(username+xyz) == abc123) { send data to NSA(); }`. I can't think of any binary-downloading systems (app stores, aptget, etc) which would discover that code. And remember - desktop app code is potentially much more dangerous. Desktop apps can take photos with your webcam, record audio, record keystrokes and access every file in your home directory. Its definitely true that most web apps are poorly implemented - they dynamically load 3rd party JS and they don't use SSL / HSTS. Its also embarrassing how many desktop apps have simple buffer overflow exploits. But the solution isn't to go back to desktop apps - the solution is to push for better best practices on the web. In my opinion, the biggest security problem with the web is that most web apps store all your data in plaintext on someone else's computers. This is a problem that we we need to start addressing systematically via projects like CryptDB. Ie, we need more serious security work done on the web. Not less.