4 ms·

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.

by 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.
pwnna 9y ago
Having two independent system while destroying traffic savings from a transparent caching system seems like a bad trade off to me. Consider you're a cloud provider running customer images. If everyone downloaded the same package via https over and over again, the incurred network utilization would be massive (to both you and the debian repository in general) compared to if everyone used http and verified via GPG, all from your transparent squid cache you setup on the local network.
- jopsen 9y ago
  I fear the trust issues with generic HTTP caching makes it infeasible. It would probably be better to use a distributed system design for this.. BitTorrent or who knows ipfs maybe..

by jopsen 9y ago

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.

pwnna 9y ago

Having two independent system while destroying traffic savings from a transparent caching system seems like a bad trade off to me. Consider you're a cloud provider running customer images. If everyone downloaded the same package via https over and over again, the incurred network utilization would be massive (to both you and the debian repository in general) compared to if everyone used http and verified via GPG, all from your transparent squid cache you setup on the local network.

jopsen 9y ago
I fear the trust issues with generic HTTP caching makes it infeasible. It would probably be better to use a distributed system design for this.. BitTorrent or who knows ipfs maybe..