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...)
(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...)
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.
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.
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).
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:
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.
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.
