3 ms·

Yes, however isn't this sort of what HTTPS is supposed to accomplish?

jonpaul 13y ago
Not as far as I know... I could run a server that serves up HTML/JS and if that JS was modified by an attacker who hacked the server, consumers of my HTML/JS wouldn't know regardless of whether it's served up on HTTPS or not. Please correct me if I'm wrong.
- jonknee 13y ago
  If the server is compromised you're SOL.
  - jonpaul 13y ago
    Exactly. That's why I'm advocating for a signed JavaScript/HTML/webapp standard of some sort.
  - bradleyland 13y ago
    That is not true if you're using code signing. If someone compromises the server, they can overwrite the files, but they cannot forge code signing without additional access to code signing private keys. Security is achieved through layers. No single layer can protect you from everything, but we lay down the gauntlet in the hopes that an attacker will encounter a road block that they cannot pass.
untothebreach 13y ago
HTTPS just tells you that you are talking to the 'right' server. It doesn't tell you anything about the validity of the javascript that the server is sending you.
- tlrobinson 13y ago
  In both cases you're using a private key, which you need to protect, to authenticate you are who you say you are. I suppose the difference is a JS bundle could be signed offline and uploaded to a potentially insecure server/CDN/app store/whatever.
  - bradleyland 13y ago
    The fact that a private key is used doesn't mean HTTPS and code signing are the same. HTTPS says, "The communications you send to the server cannot be intercepted and changed between the client and server, and the identity of the server you're connecting to has been verified by one of your trusted certificate authorities." HTTPS promises that your communications cannot be snooped on, and the person you're talking to is verified by a mutually agreed upon third-party. Code signing does something entirely different. Code signing says, "The code you're about to run was written by the developer specified in the signing certificate, and has not been modified since it was signed. The identity of the developer has been verified by one of your trusted certificate authorities." So the practical difference is this: Say your browser requests https://domain.com/random.js https://domain.com/random.js. HTTP ensures that you're connecting to domain.com, and that your communications won't be changed or observed in transit. However, it does not guarantee that some malicious third-party didn't overwrite random.js on the server. With code signing, you can accomplish that. An author can "sign" a code package so that any alterations to the code itself would cause a certificate invalidation.

Not as far as I know... I could run a server that serves up HTML/JS and if that JS was modified by an attacker who hacked the server, consumers of my HTML/JS wouldn't know regardless of whether it's served up on HTTPS or not. Please correct me if I'm wrong.

jonknee 13y ago
If the server is compromised you're SOL.
- jonpaul 13y ago
  Exactly. That's why I'm advocating for a signed JavaScript/HTML/webapp standard of some sort.
- bradleyland 13y ago
  That is not true if you're using code signing. If someone compromises the server, they can overwrite the files, but they cannot forge code signing without additional access to code signing private keys. Security is achieved through layers. No single layer can protect you from everything, but we lay down the gauntlet in the hopes that an attacker will encounter a road block that they cannot pass.

untothebreach 13y ago

HTTPS just tells you that you are talking to the 'right' server. It doesn't tell you anything about the validity of the javascript that the server is sending you.

tlrobinson 13y ago
In both cases you're using a private key, which you need to protect, to authenticate you are who you say you are. I suppose the difference is a JS bundle could be signed offline and uploaded to a potentially insecure server/CDN/app store/whatever.
- bradleyland 13y ago
  The fact that a private key is used doesn't mean HTTPS and code signing are the same. HTTPS says, "The communications you send to the server cannot be intercepted and changed between the client and server, and the identity of the server you're connecting to has been verified by one of your trusted certificate authorities." HTTPS promises that your communications cannot be snooped on, and the person you're talking to is verified by a mutually agreed upon third-party. Code signing does something entirely different. Code signing says, "The code you're about to run was written by the developer specified in the signing certificate, and has not been modified since it was signed. The identity of the developer has been verified by one of your trusted certificate authorities." So the practical difference is this: Say your browser requests https://domain.com/random.js https://domain.com/random.js. HTTP ensures that you're connecting to domain.com, and that your communications won't be changed or observed in transit. However, it does not guarantee that some malicious third-party didn't overwrite random.js on the server. With code signing, you can accomplish that. An author can "sign" a code package so that any alterations to the code itself would cause a certificate invalidation.