Hacker News new | past | comments | ask | show | jobs | submit login

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.

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

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.

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

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-...

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

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.

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.

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.

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.

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..

> 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.

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.

> 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????????

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.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact