5 ms·

What about hosting HTTP content because you verify GPG signatures upon download? These content would then be super easy to cache on the local network. HTTPS def

by pwnna 9y ago

What about hosting HTTP content because you verify GPG signatures upon download? These content would then be super easy to cache on the local network. HTTPS defeats this and makes it uncachable. I hardly ever see people talk about this use case and how to solve it with https everywhere. AND it's super widely used: e.g. debian repositories.

vertex-four 9y ago
Clients for this aren’t web browsers. Making browsers warn about them doesn’t break anything.
geofft 9y ago
HTTPS doesn't make it uncacheable - you can still mirror an HTTPS repository with another HTTPS repository (with its own domain name and certificate), and preserve the PGP signatures inside the repository. apt works fine with exactly this model: you use HTTPS for transport-layer protection and GPG for the existing things Debian's security model was already good at. The Debian repository is behind HTTPS at https://deb.debian.org https://deb.debian.org - in existing Debian releases you may need to install apt-transport-https, and then just set your sources.list to deb https://deb.debian.org/debian stable main HTTPS cannot be used as a replacement for PGP in this scenario, but that's the wrong way to see HTTPS. It doesn't provide purpose-built security for people who have custom threat models and need to build security infrastructure anyway (e.g., Debian verifies PGP signatures on sets of packages uploaded by developers, and then builds those packages and puts them into signed archives). HTTPS is baseline security - it's the security that every web connection should just have. It's not surprising that some specific use case like Debian repositories needs more-than-baseline security. And because HTTPS is nothing more than baseline security, it's possible to automate it with things like Let's Encrypt and not add any more checking beyond current control of DNS or HTTP traffic to the domain. (Another confusion along these lines is assuming HTTPS is useful as an assertion that a site isn't malware. It asserts no such thing, only that the site is who it claims to be and network attackers are not present. If I am the person who registered paypal-online-secure-totes-legit.com, I should be able to get a cert for it, because HTTPS attests to nothing else.)
- pwnna 9y ago
  I'm not talking about a mirror, which has a different domain name. I'm talking about a transparent cache like squid. This will mean I don't have to change the OS images that I might not even control in order to get traffic savings, whereas under your model I would have to, which again, may not even be feasible.
madeofpalk 9y ago
> What about hosting HTTP content because you verify GPG signatures upon download If you're doing this, then you've made your own HTTP client so you can do whatever you want. "HTTPS Everywhere" is a web browser thing.
- pwnna 9y ago
  So it's just bad naming. Everywhere to me implies everywhere, not just everywhere in the browser. Regardless, it looks like there are still people confused about it like me discussing in this thread, tho.
jen20 9y ago
There are a variety of attacks against GPG-signed repositories - an article [1] by Joe Damato explains them, and that all can be trivially mitigated by serving the repositories with TLS. [1]: https://blog.packagecloud.io/eng/2018/02/21/attacks-against-secure-apt-repositories/ https://blog.packagecloud.io/eng/2018/02/21/attacks-against-...
- jwilk 9y ago
  On HN: https://news.ycombinator.com/item?id=16432435 https://news.ycombinator.com/item?id=16432435
jopsen 9y ago
I'm actually surprised debian repos are still HTTP. Don't get me wrong GPG signatures with pinned public key is a lot better than trust TLS of a random mirror. But isn't it nice to have two layers, the two key systems are independent and orthogonal that seems like a solid win. Need I remind of Heartbleed (openssl) or the very debian specific gpg key derivation bug years ago. There will always be bugs, we can only hope they aren't exposed concurrently :)
- zenhack 9y ago
  That, and the way gpg is used for apt provides no confidentiality at all, just authenticity & integrity. Someone who can see the traffic will still know which packages you've downloaded.
  - asdbffg 9y ago
    Indeed. The same is also true for repositories, served via SSL. Majority of HTTPS traffic is sniffable and largely non-confidential, unless you pad every file and web-request to several gigabytes in size. Does your website use gzip? Good, now padding won't help you either, — unless it is way bigger than original content. Oh, and make sure, that you defend against timing attacks as well! Passive sniffers totally won't identify specific webpage based on it's generation time, will they?! As for authenticity… Surely, you are going to use certificate pinning (which is already removed from Google Chrome for political reasons). And personally sue certificate issuer, when Certificate Transparency logs reveal, that one of Let's Encrypt employees sold a bunch of private keys to third parties. Of course, that won't protect authenticity, but at least, you will avenge it, right? SSL-protected HTTP is just barely ahead of unencrypted HTTP in terms of transport-level security. But it is being sold as golden bullet, and people like you are the ones to blame.
    - jopsen 9y ago
      TLS is getting better and there is a LOT of momentum to this. I bet the SNI issues will eventually be fixed too. And yes, with momentum behind certificate transparency, it could definitely hold CAs to the fire :) TLS is no silver bullet, but it's a good base layer to always add.
staticassertion 9y ago
> What about hosting HTTP content because you verify GPG signatures upon download? Because the rest of the content is not verified?????? That's the whole point of HTTPS????????
- pwnna 9y ago
  I didn't downvote this and this is a valid misunderstanding. The whole point of having GPG is that you (as the distributor/debian repo/whatever) have already somehow distributed the public key to your clients (customers/debian installations/whatever). Having HTTPS is redundant as it is presumed that initial key distribution was done securely.

by pwnna 9y ago

vertex-four 9y ago

Clients for this aren’t web browsers. Making browsers warn about them doesn’t break anything.

geofft 9y ago

HTTPS doesn't make it uncacheable - you can still mirror an HTTPS repository with another HTTPS repository (with its own domain name and certificate), and preserve the PGP signatures inside the repository. apt works fine with exactly this model: you use HTTPS for transport-layer protection and GPG for the existing things Debian's security model was already good at. The Debian repository is behind HTTPS at https://deb.debian.org https://deb.debian.org - in existing Debian releases you may need to install apt-transport-https, and then just set your sources.list to deb https://deb.debian.org/debian stable main HTTPS cannot be used as a replacement for PGP in this scenario, but that's the wrong way to see HTTPS. It doesn't provide purpose-built security for people who have custom threat models and need to build security infrastructure anyway (e.g., Debian verifies PGP signatures on sets of packages uploaded by developers, and then builds those packages and puts them into signed archives). HTTPS is baseline security - it's the security that every web connection should just have. It's not surprising that some specific use case like Debian repositories needs more-than-baseline security. And because HTTPS is nothing more than baseline security, it's possible to automate it with things like Let's Encrypt and not add any more checking beyond current control of DNS or HTTP traffic to the domain. (Another confusion along these lines is assuming HTTPS is useful as an assertion that a site isn't malware. It asserts no such thing, only that the site is who it claims to be and network attackers are not present. If I am the person who registered paypal-online-secure-totes-legit.com, I should be able to get a cert for it, because HTTPS attests to nothing else.)

pwnna 9y ago
I'm not talking about a mirror, which has a different domain name. I'm talking about a transparent cache like squid. This will mean I don't have to change the OS images that I might not even control in order to get traffic savings, whereas under your model I would have to, which again, may not even be feasible.

madeofpalk 9y ago

> What about hosting HTTP content because you verify GPG signatures upon download If you're doing this, then you've made your own HTTP client so you can do whatever you want. "HTTPS Everywhere" is a web browser thing.

pwnna 9y ago
So it's just bad naming. Everywhere to me implies everywhere, not just everywhere in the browser. Regardless, it looks like there are still people confused about it like me discussing in this thread, tho.

jen20 9y ago

There are a variety of attacks against GPG-signed repositories - an article [1] by Joe Damato explains them, and that all can be trivially mitigated by serving the repositories with TLS. [1]: https://blog.packagecloud.io/eng/2018/02/21/attacks-against-secure-apt-repositories/ https://blog.packagecloud.io/eng/2018/02/21/attacks-against-...

jwilk 9y ago
On HN: https://news.ycombinator.com/item?id=16432435 https://news.ycombinator.com/item?id=16432435

jopsen 9y ago

I'm actually surprised debian repos are still HTTP. Don't get me wrong GPG signatures with pinned public key is a lot better than trust TLS of a random mirror. But isn't it nice to have two layers, the two key systems are independent and orthogonal that seems like a solid win. Need I remind of Heartbleed (openssl) or the very debian specific gpg key derivation bug years ago. There will always be bugs, we can only hope they aren't exposed concurrently :)

zenhack 9y ago
That, and the way gpg is used for apt provides no confidentiality at all, just authenticity & integrity. Someone who can see the traffic will still know which packages you've downloaded.
- asdbffg 9y ago
  Indeed. The same is also true for repositories, served via SSL. Majority of HTTPS traffic is sniffable and largely non-confidential, unless you pad every file and web-request to several gigabytes in size. Does your website use gzip? Good, now padding won't help you either, — unless it is way bigger than original content. Oh, and make sure, that you defend against timing attacks as well! Passive sniffers totally won't identify specific webpage based on it's generation time, will they?! As for authenticity… Surely, you are going to use certificate pinning (which is already removed from Google Chrome for political reasons). And personally sue certificate issuer, when Certificate Transparency logs reveal, that one of Let's Encrypt employees sold a bunch of private keys to third parties. Of course, that won't protect authenticity, but at least, you will avenge it, right? SSL-protected HTTP is just barely ahead of unencrypted HTTP in terms of transport-level security. But it is being sold as golden bullet, and people like you are the ones to blame.
  - jopsen 9y ago
    TLS is getting better and there is a LOT of momentum to this. I bet the SNI issues will eventually be fixed too. And yes, with momentum behind certificate transparency, it could definitely hold CAs to the fire :) TLS is no silver bullet, but it's a good base layer to always add.

staticassertion 9y ago

> What about hosting HTTP content because you verify GPG signatures upon download? Because the rest of the content is not verified?????? That's the whole point of HTTPS????????

pwnna 9y ago
I didn't downvote this and this is a valid misunderstanding. The whole point of having GPG is that you (as the distributor/debian repo/whatever) have already somehow distributed the public key to your clients (customers/debian installations/whatever). Having HTTPS is redundant as it is presumed that initial key distribution was done securely.