Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ACME v2 and Wildcard Certificate Support is Live

community.letsencrypt.org

Post reply on HN
Print view View original

311–320 of 321 posts

Re: ACME v2 and Wildcard Certificate Support is Live

#311

Post by tracker1 »

asdbffg wrote: post #306
0x0 wrote: post #301

Earlier quoted context omitted.

Sounds like you just reinvented HTTPS with a null encryption cipher. I don't see how this makes anything easier or better.

I would love if null encryption ciphers actually worked in real life, but they don't (for the same reason why plaintext HTTP/2 does not — everyone disabled them under political pressure). By the way, — signing is not equal to "null encryption". Signing can be done in advance, once. Signed data can be served via sendfile(). It does not incur CPU overhead on each request. Signing does not require communicating with unt…

And how do you sign these requests? How do you get browsers to trust the signature? Oh, well, we already have a similar solution that also protects the entire connection from spying... it's called HTTPS.

Re: ACME v2 and Wildcard Certificate Support is Live

#312

Post by pwnna »

geofft wrote: post #135
pwnna wrote: post #78

Earlier quoted context omitted.

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…

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.

Re: ACME v2 and Wildcard Certificate Support is Live

#313

Post by pwnna »

staticassertion wrote: post #249
pwnna wrote: post #78

Earlier quoted context omitted.

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.

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

Re: ACME v2 and Wildcard Certificate Support is Live

#314

Post by pwnna »

madeofpalk wrote: post #168
pwnna wrote: post #78

Earlier quoted context omitted.

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.

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

Re: ACME v2 and Wildcard Certificate Support is Live

#315

Post by pwnna »

jopsen wrote: post #207
pwnna wrote: post #78

Earlier quoted context omitted.

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.

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 hop…

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.

Re: ACME v2 and Wildcard Certificate Support is Live

#316

Post by megous »

Karunamon wrote: post #271
megous wrote: post #225

Earlier quoted context omitted.

Where do you store the trust from all those people to be able to query the statistics? That's just another central point of failure.

It's not as if distributed hash stores are new...

That didn't answer anything. How can you trust the result if anyone can write there. How can you trust the individual store that it doesn't manipulate its contents, etc.

Re: ACME v2 and Wildcard Certificate Support is Live

#317

Post by Santosh83 »

snowwolf wrote: post #276
Santosh83 wrote: post #28

I do hope GitHub employs this for rolling out https for Pages sites using custom domains too.

Why do they need to support Wildcard Certificates for this? They have already starting rolling out https for custom domain GitHub Pages using LetsEncrypt - check your settings for an Enforce HTTPS option. All my GitHub Pages have it now.

That's great. I just checked and it isn't available/enabled here yet. I'm wondering if GitHub doesn't enable their own SSL if a user is providing that through a service like Cloudflare... perhaps I should disable the latter and see if that makes a difference.

Re: ACME v2 and Wildcard Certificate Support is Live

#318

Post by jopsen »

asdbffg wrote: post #304
zenhack wrote: post #234

Earlier quoted context omitted.

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…

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.

Re: ACME v2 and Wildcard Certificate Support is Live

#319

Post by jopsen »

pwnna wrote: post #315
jopsen wrote: post #207

Earlier quoted context omitted.

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 hop…

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…

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

Re: ACME v2 and Wildcard Certificate Support is Live

#320

Post by stargrazer »

asdbffg wrote: post #307
niij wrote: post #290

Earlier quoted context omitted.

There's a lot of countries I don't trust to keep sensitive data in. But my point is that Wosign was provably untrustworthy, rather than speculation on government interference in other CAs. I saw from your Github that you live in Kazakhstan, I would remind you the government is less than trustworthy as well[0] in regards to digital privacy. [0]: http://www.slate.com/blogs/future_tense/2015/12/14/kazakhsta...

I doubt, that any government is inherently more trustworthy than any other. It just coincidentally happens, that US controls 100% of root CAs and Kazakhstan (most likely) controls 0. So the later needs more audacious measures, while former can just issue a gag order to Symantec (or whoever is currently active in market). CA system is inherently vulnerable to government intervention. There is no point in considering d…

Maybe not 100%. Bermuda has a root CA: QuoVadis Global.
Post reply on HN