22 ms·

The arguments are correct. APT does not need HTTPS to be secure. That said, if APT was designed today I'm sure it would use HTTPS. It's now the default things t

The arguments are correct. APT does not need HTTPS to be secure. That said, if APT was designed today I'm sure it would use HTTPS. It's now the default things to do, and Let's Encrypt makes it free and easy. However Debian, where APT is from, relies on the goodwill of various universities and companies to host their packages for free. I can see that they don't want to make demands on a service they get for free, when HTTPS isn't even necessary for the use case. Also since APT and Debian was created in the pre-universal HTTPS days, it does things like map something.debian.org to various mirrors owned by different parties. That makes certificate handling complicated.

stefan_ 8y ago
Why would it? As the site lays out, HTTPS is strictly inferior to the scheme used by APT. You can not get more security by adding a less secure mechanism to a better one. It's not additive.
- julian-klode 8y ago
  Of course you'd get more security. Analogy: It's like your hanging on a rope and also add a safety net. If the rope breaks, you only fall on the safety net instead of the ground. All software has bugs, so if you add two buggy security solutions, you might only be able to exploit a bug in one, but the other still gives you the safety.
  - kiallmacinnes 8y ago
    That's not always true though, and it can be really hard to tell if a particular combination is going to make things better or worse. e.g. the "Breach" HTTPS+Compression vulnerability. To continue your analogy: The rope gets tangled in the safety net, forcing you to jump or proceed up with a loose rope, because you can no longer move the rope..
  - marcosdumay 8y ago
    This is not the physical world. Digital security strength is measured on orders of magnitude, and two mechanisms providing security with very different orders of magnitude do not add in any practical sense.
    - julian-klode 8y ago
      If you've seen today's bug yesterday, or carefully looked at the previous CVEs, you would have seen that https would have significantly reduced the probability of exploitability.
  - diffeomorphism 8y ago
    > All software has bugs, so if you add two buggy security solutions, you might only be able to exploit a bug in one, but the other still gives you the safety. I am unconvinced about the last part. More commonly an exploit in either will cause security to fail, so adding more steps just adds more attack surface and leads to less security.
arghwhat 8y ago
It does not need HTTPS to be secure, but it would need HTTPS to add privacy, for which the protocol has none at the current time.
- Arnt 8y ago
  You're downloading form a third-party volunteer. What protocol can provide privacy given that condition?
  - rhacker 8y ago
    Instead of JUST that third party knowing what (possibly vulnerable) packages you have, you are now letting everyone know what possibly vulnerable packages you have.
    - altfredd 8y ago
      > you are now letting everyone know what possibly vulnerable packages you have. Erm, what? The number of people, who can listen to (much less — modify) your traffic is very small. It is basically your ISP (who is supposed to offers you services in good faith, not spy on you) and a number of engineers, who maintain Internet backbone. That's far from "everyone". Some SSL evangelists make it sound like everyone's traffic is permanently broadcasted to everyone else in the world, but it is not. As for "vulnerable packages", the most certain sign, that someone does not install security updates, is lack of traffic between them and update servers. But that's orthogonal to use of encryption.
      - DoctorOetker 8y ago
        "everyone" in this context obviously means everyone on the path, and any attackers that have compromised nodes along the path. See the Belgacom hack by 5 eyes...
        monocasa 8y ago
        And I those attackers can still tell everything based on the target IP and the payload sizes.
DoctorOetker 8y ago
It depends on the threat model, here TM1 and TM2: TM1: attacker does not posses zerodays to installed software TM2: attacker possesses speccific (perhaps OS, perhaps library, perhaps userland) zerodays, usage of which (including unsuccesful attempts) should be minimized to avoid detection in TM1: it's ok to use HTTP in the clear, as long as signatures are verified in TM2: everything should be fetched over encrypted HTTPS, since HTTP would leak information about available attack surface EDIT: not only would this increase security by not revealing what a user installs (perhaps download some noise as well such that it becomes harder to detect what a user is installing?), it could also improve security by turning the APT servers into honeypots, so that monitoring these can reveal zerodays...
- AstralStorm 8y ago
  TM3: attacker has a 0-day against a complex https server and they replace packages on some mirrors. TM4: attacker can impersonate a server using Lets Encrypt certificate and bypass their automated verification, creating a fake mirror or a bunch. (HTTP has same vector.) They can also make DNS fail or reroute. TM5: attacker has a 0-day against the more complex https client (e.g. curl). TM6: Attacker fingerprints network connections to given servers by size and os or os + tls fingerprinting data
  - DoctorOetker 8y ago
    TM3 and TM5 are specific subcases for TM2, and turn the APT server / client into a honeypot TM6: we should have an overlay onion router, and I agree that the current complexity is worrying, I'd love to see a minimalist version of TOR (with minimal I don't necessarily mean the code size should be small, but minimal assumptions, and that the safety of the system can be verified from the assumptions) TM4: I don't understand, Lets Encrypt does not calculate private keys for public keys...
mtgx 8y ago
> if APT was designed today I'm sure it would use HTTPS. Or it would use the much more modern and more secure Noise, like I think QUIC will end up using through nQUIC: https://dl.acm.org/citation.cfm?id=3284854 https://dl.acm.org/citation.cfm?id=3284854 https://noiseprotocol.org https://noiseprotocol.org
- tialaramex 8y ago
  Yeah, no. nQUIC is maybe an interesting approach for some specialist applications but more likely a dead end. The idea you can replace QUIC with nQUIC is like when Coiners used to show up telling us we're going to be using Bitcoin to buy a morning newspaper. Remember newspapers? nQUIC doesn't have a way for Bob to prove to Alice that he's Bob beyond "Fortunately Alice already knew that" which is the assumption in that ACM paper. So that's a non-starter for the web. nQUIC also doesn't have a 0-RTT mode. Noise proponents can say "That's a good thing, 0-RTT is a terrible idea". Maybe so, but you don't have one and TLS does. If society decides it hates 0-RTT modes because they're a terrible idea, we just don't use the TLS 0-RTT mode and nothing is lost. But if as seems far more likely we end up liking how fast it is, Noise can't match that. Doesn't want to. Noise is a very applicable framework for some problems, and I can see why you might think APT fits but it doesn't.
  - phlip9 8y ago
    > nQUIC is maybe an interesting approach for some specialist applications but more likely a dead end. Adding on to this, nQUIC (and Noise specifically) is significantly better for use-cases where CAs and traditional PKI don't make sense, e.g., p2p, VPN, TOR, IPFS, etc... I agree that APT is not one of these cases. Currently APT has a root trust set that is disjoint from the OS's root CA set, but they could easily do HTTPS and just explicitly change the root CA set for those connections. EDIT: from the nQUIC paper: > In particular nQUIC is not intended for the traditional Web setting where interoperability and cryptographic agility is essential. On another note, I think it would be helpful to expand some points for other readers: > nQUIC also doesn't have a 0-RTT mode. Noise proponents can say "That's a good thing, 0-RTT is a terrible idea". 0-RTT is dangerous because of replay attacks. It pushes low-level implementation details up the stack and requires users to be aware of and actively avoid sending non-idempotent messages in the first packet. > Maybe so, but you don't have one and TLS does. If society decides it hates 0-RTT modes because they're a terrible idea, we just don't use the TLS 0-RTT mode and nothing is lost. One major point of using Noise protocol is to _simplify_ the encryption and auth layers, remove everything that's not absolutely necessary, and make it hard to fuck up in general. Things like ciphersuite negotiation, x509 certificate parsing and validation, and cryptographic agility have been the source of many many security critical bugs. From an auditability perspective, Noise wins easily. You can write a compliant Noise implementation in <10k loc, vs. OpenSSL ~400k loc. > But if as seems far more likely we end up liking how fast it is, Noise can't match that. Doesn't want to. HTTP is insecure, but faster than HTTPS. Most sites now use HTTPS regardless. 0-RTT is insecure and while it might be OK for browsing HN, removing 0-RTT makes it much harder to fuck up.
fyjvd90 8y ago
The argument isn’t correct, what does a user do when the download is damaged by an injection? A re-download results in exactly the same tampered with file.
mr__y 8y ago
>I can see that they don't want to make demands on a service they get for free, when HTTPS isn't even necessary for the use case you could imagine a situation where https would be optional for APT mirrors. Then the package manager would have a config flag to use any mirror or only https-enabled mirrors (probably enabled by default). This would allow to use https without creating any demands to organizations that host those mirrors - if they can they would enable it, but it would not be required. The https-enabled hosts could also provide plain http for backwards compatibility.

stefan_ 8y ago

Why would it? As the site lays out, HTTPS is strictly inferior to the scheme used by APT. You can not get more security by adding a less secure mechanism to a better one. It's not additive.

julian-klode 8y ago
Of course you'd get more security. Analogy: It's like your hanging on a rope and also add a safety net. If the rope breaks, you only fall on the safety net instead of the ground. All software has bugs, so if you add two buggy security solutions, you might only be able to exploit a bug in one, but the other still gives you the safety.
- kiallmacinnes 8y ago
  That's not always true though, and it can be really hard to tell if a particular combination is going to make things better or worse. e.g. the "Breach" HTTPS+Compression vulnerability. To continue your analogy: The rope gets tangled in the safety net, forcing you to jump or proceed up with a loose rope, because you can no longer move the rope..
- marcosdumay 8y ago
  This is not the physical world. Digital security strength is measured on orders of magnitude, and two mechanisms providing security with very different orders of magnitude do not add in any practical sense.
  - julian-klode 8y ago
    If you've seen today's bug yesterday, or carefully looked at the previous CVEs, you would have seen that https would have significantly reduced the probability of exploitability.
- diffeomorphism 8y ago
  > All software has bugs, so if you add two buggy security solutions, you might only be able to exploit a bug in one, but the other still gives you the safety. I am unconvinced about the last part. More commonly an exploit in either will cause security to fail, so adding more steps just adds more attack surface and leads to less security.

arghwhat 8y ago

It does not need HTTPS to be secure, but it would need HTTPS to add privacy, for which the protocol has none at the current time.

Arnt 8y ago
You're downloading form a third-party volunteer. What protocol can provide privacy given that condition?
- rhacker 8y ago
  Instead of JUST that third party knowing what (possibly vulnerable) packages you have, you are now letting everyone know what possibly vulnerable packages you have.
  - altfredd 8y ago
    > you are now letting everyone know what possibly vulnerable packages you have. Erm, what? The number of people, who can listen to (much less — modify) your traffic is very small. It is basically your ISP (who is supposed to offers you services in good faith, not spy on you) and a number of engineers, who maintain Internet backbone. That's far from "everyone". Some SSL evangelists make it sound like everyone's traffic is permanently broadcasted to everyone else in the world, but it is not. As for "vulnerable packages", the most certain sign, that someone does not install security updates, is lack of traffic between them and update servers. But that's orthogonal to use of encryption.
    - DoctorOetker 8y ago
      "everyone" in this context obviously means everyone on the path, and any attackers that have compromised nodes along the path. See the Belgacom hack by 5 eyes...
      - monocasa 8y ago
        And I those attackers can still tell everything based on the target IP and the payload sizes.

DoctorOetker 8y ago

It depends on the threat model, here TM1 and TM2: TM1: attacker does not posses zerodays to installed software TM2: attacker possesses speccific (perhaps OS, perhaps library, perhaps userland) zerodays, usage of which (including unsuccesful attempts) should be minimized to avoid detection in TM1: it's ok to use HTTP in the clear, as long as signatures are verified in TM2: everything should be fetched over encrypted HTTPS, since HTTP would leak information about available attack surface EDIT: not only would this increase security by not revealing what a user installs (perhaps download some noise as well such that it becomes harder to detect what a user is installing?), it could also improve security by turning the APT servers into honeypots, so that monitoring these can reveal zerodays...

AstralStorm 8y ago
TM3: attacker has a 0-day against a complex https server and they replace packages on some mirrors. TM4: attacker can impersonate a server using Lets Encrypt certificate and bypass their automated verification, creating a fake mirror or a bunch. (HTTP has same vector.) They can also make DNS fail or reroute. TM5: attacker has a 0-day against the more complex https client (e.g. curl). TM6: Attacker fingerprints network connections to given servers by size and os or os + tls fingerprinting data
- DoctorOetker 8y ago
  TM3 and TM5 are specific subcases for TM2, and turn the APT server / client into a honeypot TM6: we should have an overlay onion router, and I agree that the current complexity is worrying, I'd love to see a minimalist version of TOR (with minimal I don't necessarily mean the code size should be small, but minimal assumptions, and that the safety of the system can be verified from the assumptions) TM4: I don't understand, Lets Encrypt does not calculate private keys for public keys...

mtgx 8y ago

> if APT was designed today I'm sure it would use HTTPS. Or it would use the much more modern and more secure Noise, like I think QUIC will end up using through nQUIC: https://dl.acm.org/citation.cfm?id=3284854 https://dl.acm.org/citation.cfm?id=3284854 https://noiseprotocol.org https://noiseprotocol.org

tialaramex 8y ago
Yeah, no. nQUIC is maybe an interesting approach for some specialist applications but more likely a dead end. The idea you can replace QUIC with nQUIC is like when Coiners used to show up telling us we're going to be using Bitcoin to buy a morning newspaper. Remember newspapers? nQUIC doesn't have a way for Bob to prove to Alice that he's Bob beyond "Fortunately Alice already knew that" which is the assumption in that ACM paper. So that's a non-starter for the web. nQUIC also doesn't have a 0-RTT mode. Noise proponents can say "That's a good thing, 0-RTT is a terrible idea". Maybe so, but you don't have one and TLS does. If society decides it hates 0-RTT modes because they're a terrible idea, we just don't use the TLS 0-RTT mode and nothing is lost. But if as seems far more likely we end up liking how fast it is, Noise can't match that. Doesn't want to. Noise is a very applicable framework for some problems, and I can see why you might think APT fits but it doesn't.
- phlip9 8y ago
  > nQUIC is maybe an interesting approach for some specialist applications but more likely a dead end. Adding on to this, nQUIC (and Noise specifically) is significantly better for use-cases where CAs and traditional PKI don't make sense, e.g., p2p, VPN, TOR, IPFS, etc... I agree that APT is not one of these cases. Currently APT has a root trust set that is disjoint from the OS's root CA set, but they could easily do HTTPS and just explicitly change the root CA set for those connections. EDIT: from the nQUIC paper: > In particular nQUIC is not intended for the traditional Web setting where interoperability and cryptographic agility is essential. On another note, I think it would be helpful to expand some points for other readers: > nQUIC also doesn't have a 0-RTT mode. Noise proponents can say "That's a good thing, 0-RTT is a terrible idea". 0-RTT is dangerous because of replay attacks. It pushes low-level implementation details up the stack and requires users to be aware of and actively avoid sending non-idempotent messages in the first packet. > Maybe so, but you don't have one and TLS does. If society decides it hates 0-RTT modes because they're a terrible idea, we just don't use the TLS 0-RTT mode and nothing is lost. One major point of using Noise protocol is to _simplify_ the encryption and auth layers, remove everything that's not absolutely necessary, and make it hard to fuck up in general. Things like ciphersuite negotiation, x509 certificate parsing and validation, and cryptographic agility have been the source of many many security critical bugs. From an auditability perspective, Noise wins easily. You can write a compliant Noise implementation in <10k loc, vs. OpenSSL ~400k loc. > But if as seems far more likely we end up liking how fast it is, Noise can't match that. Doesn't want to. HTTP is insecure, but faster than HTTPS. Most sites now use HTTPS regardless. 0-RTT is insecure and while it might be OK for browsing HN, removing 0-RTT makes it much harder to fuck up.

fyjvd90 8y ago

The argument isn’t correct, what does a user do when the download is damaged by an injection? A re-download results in exactly the same tampered with file.

mr__y 8y ago

>I can see that they don't want to make demands on a service they get for free, when HTTPS isn't even necessary for the use case you could imagine a situation where https would be optional for APT mirrors. Then the package manager would have a config flag to use any mirror or only https-enabled mirrors (probably enabled by default). This would allow to use https without creating any demands to organizations that host those mirrors - if they can they would enable it, but it would not be required. The https-enabled hosts could also provide plain http for backwards compatibility.