5 ms·

Old... but interesting, I guess. From the bug report: > We don't require update.rdf files to be signed when they're served over HTTPS, since HTTPS provides t

Old... but interesting, I guess. From the bug report: > We don't require update.rdf files to be signed when they're served over HTTPS, since HTTPS provides the same level of verification as an updateKey, and we don't see significant benefit to the additional level of verification. I'm kind of confused by that comment - Mozilla are saying that signing the software itself is somehow the same as serving it over HTTPS? Think about other software repositories. That's like saying serving Fedora packages over HTTPS is the same as signing the RPM's... it's not, and it's kind of an absurd thing to suggest. You can independently verify the signature of the RPM itself, offline, outside of the browser. I can't see how that could be considered anything but a significant benefit.

fastball 12y ago
I think the idea is that you don't need the extra security of signing, because if the file was served over HTTPS then you can be secure in the knowledge that it has not been modified. The reason you sign packages is to ensure that the file you want and the file you get are actually the same. If you have a secure connection to the trusted host of said file, you don't need to worry about that.
- throwawayaway 12y ago
  A MITM attack? What then? Seems you need signing then.
  - Iburinoc 12y ago
    Perhaps I misunderstand you but since it's HTTPS, in theory there are no MITM attacks.
    - holdenk 12y ago
      So with the system of mirrors that is in place with distributing some open source software (e.g. debian, ubuntu, etc.) this is less true. A local mirror could selectively serve bad packages (and serve the correct packages to the verification bots).
      - ckuehl 12y ago
        Debian has a pretty nice mirroring system. Not only are all packages signed, but the Release file (which includes checksums of package lists) is also signed, preventing a mirror from omitting packages. For repositories which receive security updates (say, wheezy-updates), the index is valid for only few days in the future, which helps to prevent mirrors from withholding security updates [1]. If a mirror isn't updated, the user is eventually warned during updates: > E: Release file for http://mirrors/debian/dists/wheezy-updates/Release http://mirrors/debian/dists/wheezy-updates/Release is expired (invalid since 1h 20min 30s). Updates for this repository will not be applied. It mostly negates the need for https mirrors for authenticity, although many still offer it. To my knowledge, most projects with mirror networks operate similar to this. [1] e.g. https://mirrors.ocf.berkeley.edu/debian/dists/wheezy-updates/Release https://mirrors.ocf.berkeley.edu/debian/dists/wheezy-updates... has the pseudo-header Valid-Until: Tue, 02 Dec 2014 20:50:35 UTC
        Xylakant 12y ago
        Actually, there's no requirement that .deb packages are signed. The system still provides a strong guarantee, because the releases file contains a list of checksums for each package, so it's impossible to tamper with the package, even though it's unsigned. However, if you manually download the package, all bets are off. RPMs are usually signed directly.
    - bigiain 12y ago
      Unless, as the article points out, the attacker has your private SSL key (perhaps leaked via Heartbleed). Without cert pinning here's also the problem of the attacker convincing some browser-trusted CA to issue an SSL cert for addons.mozilla.org, then MITMing you with that. (And with 600+ trusted roots, many of which are owned by various governments, against state level attackers an ssl connection's claim of authenticity has to be considered very close to worthless...)
      - bzbarsky 12y ago
        > Without cert pinning In the case of Firefox connecting to addons.mozilla.org, there is cert pinning.
        bigiain 12y ago
        I didn't know that, thanks. (In retrospect, it's such an obvious thing for them to do - I don't know why I didn't assume it was likely enough to be implemented and check before I posted that...)
        bzbarsky 12y ago
        To be fair, I _think_ the pinning was only added in Firefox 32, back in September. So it's a pretty recent development.
    - timschmidt 12y ago
      Someone better tell these guys to stop selling SSL MITM hardware, then. http://www.wired.com/2010/03/packet-forensics http://www.wired.com/2010/03/packet-forensics
    - n09n 12y ago
      In this situation, addons.mozilla.org is the hypothetical man in the middle so https doesn't protect you.
    - click170 12y ago
      Its possible to MITM an HTTPS connection, trick you into thinking it is secure by providing a green lock favicon, and intercepting or sniffing everything you do over that connection. And it will work on nearly every website in existance. More people should be aware of SSL Strip and how to protect yourself against it. http://www.thoughtcrime.org/software/sslstrip/ http://www.thoughtcrime.org/software/sslstrip/
      - bzbarsky 12y ago
        > Its possible to MITM an HTTPS connection Not in the case of Firefox connecting to AMO, because it uses a pinned certificate for that.
        click170 12y ago
        Are you sure? I perform HTTPS interception on all out-bound traffic on my network and I don't recall making an exception for AMO, and I have a number of add-ons installed. Though, it wouldn't be the first time I've forgotten about something like that.
        bzbarsky 12y ago
        Did you install your addons before updating to Firefox 32? That's when the pinning was introduced.
    - throwawayaway 12y ago
      http://arstechnica.com/information-technology/2013/11/quantum-of-pwnness-how-nsa-and-gchq-hacked-opec-and-others/ http://arstechnica.com/information-technology/2013/11/quantu... All they need is an authorised certificate.
- mikeash 12y ago
  The difference is that signed code lets you keep the signing key offline, and therefore it can be much more secure. For a concrete example, consider the case where the server is compromised and an attacker wants to insert malware. HTTPS does nothing at all to help, here. The attacker has control over the server and can make it serve whatever it wants, and since the server still has its normal certificate and key, the attacker's malware-infested code will show up just like legitimate stuff would. If the code was signed using a key that isn't kept on the server (normally a code signing key will be kept on a developer's computer, and often protected by a password so it rarely exists in memory unencrypted) then the attacker can't force the server to serve malware that will be accepted by downloaders.
  - pserwylo 12y ago
    > If the code was signed using a key that isn't kept on the server (normally a code signing key will be kept on a developer's computer, and often protected by a password so it rarely exists in memory unencrypted) And to take this even further, you have the option of keeping the key on a machine that is completely disconnected from any network. In addition, this machine could use a Hardware Security Module to further increase the security of the signing key.
- snowwrestler 12y ago
  > The reason you sign packages is to ensure that the file you want and the file you get are actually the same. If you have a secure connection to the trusted host of said file, you don't need to worry about that. HTTPS provides a secure connection, in theory, but what if AMO is itself compromised? They are just a 3rd party host for the EFF's extension, after all. HTTPS or not, the only way to check that the code you get from AMO is the same code the EFF gave AMO, is to check it against the EFF's signature.
  - fastball 12y ago
    If AMO is compromised, then a bogus hash or whatever could be published as well.
- blcknight 12y ago
  All someone needs to do is hack the AMO servers and change out the XPI -- and no one would no the difference, because the packages aren't signed. Not to also mention, MITM attacks on the actual SSL connection. Serving over HTTPS isn't a valid package signing strategy.
  - bzbarsky 12y ago
    > Not to also mention, MITM attacks on the actual SSL > connection. The AMO cert is pinned in Firefox. If you MITM the connection, Firefox will refuse to connect to it.

fastball 12y ago

I think the idea is that you don't need the extra security of signing, because if the file was served over HTTPS then you can be secure in the knowledge that it has not been modified. The reason you sign packages is to ensure that the file you want and the file you get are actually the same. If you have a secure connection to the trusted host of said file, you don't need to worry about that.

throwawayaway 12y ago
A MITM attack? What then? Seems you need signing then.
- Iburinoc 12y ago
  Perhaps I misunderstand you but since it's HTTPS, in theory there are no MITM attacks.
  - holdenk 12y ago
    So with the system of mirrors that is in place with distributing some open source software (e.g. debian, ubuntu, etc.) this is less true. A local mirror could selectively serve bad packages (and serve the correct packages to the verification bots).
    - ckuehl 12y ago
      Debian has a pretty nice mirroring system. Not only are all packages signed, but the Release file (which includes checksums of package lists) is also signed, preventing a mirror from omitting packages. For repositories which receive security updates (say, wheezy-updates), the index is valid for only few days in the future, which helps to prevent mirrors from withholding security updates [1]. If a mirror isn't updated, the user is eventually warned during updates: > E: Release file for http://mirrors/debian/dists/wheezy-updates/Release http://mirrors/debian/dists/wheezy-updates/Release is expired (invalid since 1h 20min 30s). Updates for this repository will not be applied. It mostly negates the need for https mirrors for authenticity, although many still offer it. To my knowledge, most projects with mirror networks operate similar to this. [1] e.g. https://mirrors.ocf.berkeley.edu/debian/dists/wheezy-updates/Release https://mirrors.ocf.berkeley.edu/debian/dists/wheezy-updates... has the pseudo-header Valid-Until: Tue, 02 Dec 2014 20:50:35 UTC
      - Xylakant 12y ago
        Actually, there's no requirement that .deb packages are signed. The system still provides a strong guarantee, because the releases file contains a list of checksums for each package, so it's impossible to tamper with the package, even though it's unsigned. However, if you manually download the package, all bets are off. RPMs are usually signed directly.
  - bigiain 12y ago
    Unless, as the article points out, the attacker has your private SSL key (perhaps leaked via Heartbleed). Without cert pinning here's also the problem of the attacker convincing some browser-trusted CA to issue an SSL cert for addons.mozilla.org, then MITMing you with that. (And with 600+ trusted roots, many of which are owned by various governments, against state level attackers an ssl connection's claim of authenticity has to be considered very close to worthless...)
    - bzbarsky 12y ago
      > Without cert pinning In the case of Firefox connecting to addons.mozilla.org, there is cert pinning.
      - bigiain 12y ago
        I didn't know that, thanks. (In retrospect, it's such an obvious thing for them to do - I don't know why I didn't assume it was likely enough to be implemented and check before I posted that...)
        bzbarsky 12y ago
        To be fair, I _think_ the pinning was only added in Firefox 32, back in September. So it's a pretty recent development.
  - timschmidt 12y ago
    Someone better tell these guys to stop selling SSL MITM hardware, then. http://www.wired.com/2010/03/packet-forensics http://www.wired.com/2010/03/packet-forensics
  - n09n 12y ago
    In this situation, addons.mozilla.org is the hypothetical man in the middle so https doesn't protect you.
  - click170 12y ago
    Its possible to MITM an HTTPS connection, trick you into thinking it is secure by providing a green lock favicon, and intercepting or sniffing everything you do over that connection. And it will work on nearly every website in existance. More people should be aware of SSL Strip and how to protect yourself against it. http://www.thoughtcrime.org/software/sslstrip/ http://www.thoughtcrime.org/software/sslstrip/
    - bzbarsky 12y ago
      > Its possible to MITM an HTTPS connection Not in the case of Firefox connecting to AMO, because it uses a pinned certificate for that.
      - click170 12y ago
        Are you sure? I perform HTTPS interception on all out-bound traffic on my network and I don't recall making an exception for AMO, and I have a number of add-ons installed. Though, it wouldn't be the first time I've forgotten about something like that.
        bzbarsky 12y ago
        Did you install your addons before updating to Firefox 32? That's when the pinning was introduced.
  - throwawayaway 12y ago
    http://arstechnica.com/information-technology/2013/11/quantum-of-pwnness-how-nsa-and-gchq-hacked-opec-and-others/ http://arstechnica.com/information-technology/2013/11/quantu... All they need is an authorised certificate.
mikeash 12y ago
The difference is that signed code lets you keep the signing key offline, and therefore it can be much more secure. For a concrete example, consider the case where the server is compromised and an attacker wants to insert malware. HTTPS does nothing at all to help, here. The attacker has control over the server and can make it serve whatever it wants, and since the server still has its normal certificate and key, the attacker's malware-infested code will show up just like legitimate stuff would. If the code was signed using a key that isn't kept on the server (normally a code signing key will be kept on a developer's computer, and often protected by a password so it rarely exists in memory unencrypted) then the attacker can't force the server to serve malware that will be accepted by downloaders.
- pserwylo 12y ago
  > If the code was signed using a key that isn't kept on the server (normally a code signing key will be kept on a developer's computer, and often protected by a password so it rarely exists in memory unencrypted) And to take this even further, you have the option of keeping the key on a machine that is completely disconnected from any network. In addition, this machine could use a Hardware Security Module to further increase the security of the signing key.
snowwrestler 12y ago
> The reason you sign packages is to ensure that the file you want and the file you get are actually the same. If you have a secure connection to the trusted host of said file, you don't need to worry about that. HTTPS provides a secure connection, in theory, but what if AMO is itself compromised? They are just a 3rd party host for the EFF's extension, after all. HTTPS or not, the only way to check that the code you get from AMO is the same code the EFF gave AMO, is to check it against the EFF's signature.
- fastball 12y ago
  If AMO is compromised, then a bogus hash or whatever could be published as well.
blcknight 12y ago
All someone needs to do is hack the AMO servers and change out the XPI -- and no one would no the difference, because the packages aren't signed. Not to also mention, MITM attacks on the actual SSL connection. Serving over HTTPS isn't a valid package signing strategy.
- bzbarsky 12y ago
  > Not to also mention, MITM attacks on the actual SSL > connection. The AMO cert is pinned in Firefox. If you MITM the connection, Firefox will refuse to connect to it.