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

231–240 of 321 posts

Re: ACME v2 and Wildcard Certificate Support is Live

#231

Post by schoen »

peterwwillis wrote: post #219
schoen wrote: post #218

Earlier quoted context omitted.

We've been using TXT records to authenticate certificate requests since Let's Encrypt launched. That hasn't changed.

Without verifying who controls the IP space? If you don't verify who controls the IP space, then if you can control the DNS, you can generate certs. Certs that appear valid to unsuspecting users. Putting that kind of trust in DNS is pretty crazy considering how insecure most DNS setups are. Not to mention general attacks on DNS. There's even a potential chicken and egg problem, if you need DNS to secure your HTTPS, b…

I'm not quite sure how to answer this. DNS is used as ground truth for an enormous amount of certificate issuance by a broad range of CAs. This has been true for many years. Let's Encrypt didn't invent domain validation or the notion of relying on DNS as a basis for issuing DV certificates.

Re: ACME v2 and Wildcard Certificate Support is Live

#233

Post by cestith »

merb wrote: post #174
jsmthrowaway wrote: post #76

Earlier quoted context omitted.

What the gently caress does encrypting an HTTP connection have to do with morals or age? You are way outside the realm of making sense, man, and offer commentary that is openly harmful to securing the Internet. Please step back and revisit your woefully misinformed opinion on this. Most people who advocate for security, including myself, have worked on small teams and understand the resources involved. Putting a TLS…

> Putting a TLS certificate on your shit with LE takes minutes. Doing it through another CA is minutes if you have one server, yes. else it's the other way around, because if you have multiple servers you need to do a lot of fancy stuff. And LE also does not work in your internal network if you do not have some stuff publicy accessible. And it also does not work against different ports. Oh and it's extremly hard to h…

This new version issues wildcard certificates. Get one certificate. Use Puppet, Chef, Ansible, Salt, Bolt, multissh, or GNU parallel to put it on multiple servers for that domain.

If you need lots of different domains, use one of the auto certificate tools.

If you can't use one of those yourself, consider hosting on a platform that can automatically do this for you for all your sites, like cPanel (disclaimer: I work for cPanel, Inc).

If your stuff is never publicly accessible because you're in a fully private network, just run your own CA and add it to the trust root of your clients.

If you need an SNI proxy, search for 'sniproxy' which does exist.

If you're so small that you can't afford an infrastructure person, a consultant, or a few hours to set such things up yourself, then maybe you should shorten the HN thread bemoaning doing it and use the time to learn how.

Re: ACME v2 and Wildcard Certificate Support is Live

#234

Post by zenhack »

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…

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.

Re: ACME v2 and Wildcard Certificate Support is Live

#235

Post by amaccuish »

schoen wrote: post #165
vertex-four wrote: post #161

Earlier quoted context omitted.

It’s currently standard for CAs to host multiple verifiers in multiple jurisdictions, to reduce the chances of this happening, afaik.

Let's Encrypt is developing this feature but it might be a little premature to call it "standard"—it's not specified in the Baseline Requirements and I'm not sure whether there's any CA that has announced it as a part of all certificate issuance.

Most CAs aren't automated :) I believe any that do ensure that DNS requests are tried from multiple different locations to prevent this happening. Though you're right, the standards haven't caught up yet.

Re: ACME v2 and Wildcard Certificate Support is Live

#236

Post by pfg »

cm2187 wrote: post #211
belorn wrote: post #163

Earlier quoted context omitted.

Since the certificate need to be updated every three months they have access to exact number of how many people use ACMEv1. They also have as naturally part of the process the domain names of those users. This should allow them to very slowly watch as the number of v1 users drops until there is so few that they can try contact any remaining users before deciding to set an end-of-life to that version.

You are supposed to provide a valid email address when you register for a let's encrypt certificate. In theory they should be able to contact all v1 client users.

The email address is optional, though most clients tend to hide that fact (or make it mandatory).

Re: ACME v2 and Wildcard Certificate Support is Live

#237

Post by alwillis »

ocdtrekkie wrote: post #159
amaccuish wrote: post #150

Earlier quoted context omitted.

How so?

Presumably, someone could MITM a CA, and get their own domain validated certificate to another site. The cert may protect you from MITM in a coffee shop, but it doesn't necessarily help you against state-level actors.

>The cert may protect you from MITM in a coffee shop, but it doesn't necessarily help you against state-level actors.

I can use HPKP to pin the cert I get from Lets Encrypt; a cert issued for my domain some other way won’t be trusted due to the hash of its public key being different from the one I pinned.

From https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key...:

The Public Key Pinning Extension for HTML5 (HPKP) is a security feature that tells a web client to associate a specific cryptographic public key with a certain web server to decrease the risk of MITM attacks with forged certificates.

HPKP makes administration more complicated but if your threat model includes state-level actors, it prevents them from getting a CA to issue a valid certificate for your domain.

Certificate Authority Authorization (CAA) has been mandatory for CAs since September 2017; it uses DNS to specify which CAs are allowed to issue certificates for your domain: https://blog.qualys.com/ssllabs/2017/03/13/caa-mandated-by-c....

Re: ACME v2 and Wildcard Certificate Support is Live

#239

Post by pfg »

peterwwillis wrote: post #219
schoen wrote: post #218

Earlier quoted context omitted.

We've been using TXT records to authenticate certificate requests since Let's Encrypt launched. That hasn't changed.

Without verifying who controls the IP space? If you don't verify who controls the IP space, then if you can control the DNS, you can generate certs. Certs that appear valid to unsuspecting users. Putting that kind of trust in DNS is pretty crazy considering how insecure most DNS setups are. Not to mention general attacks on DNS. There's even a potential chicken and egg problem, if you need DNS to secure your HTTPS, b…

By "verifying who controls the IP space", do you mean verifying control over the IP a domain resolves to? In that case, what you're missing here is that control over DNS lets you alter that IP address to whatever you'd like. The attacker will have no difficulty demonstrating control over an IP address they own.

Re: ACME v2 and Wildcard Certificate Support is Live

#240

Post by pfg »

alwillis wrote: post #237
ocdtrekkie wrote: post #159

Earlier quoted context omitted.

Presumably, someone could MITM a CA, and get their own domain validated certificate to another site. The cert may protect you from MITM in a coffee shop, but it doesn't necessarily help you against state-level actors.

>The cert may protect you from MITM in a coffee shop, but it doesn't necessarily help you against state-level actors. I can use HPKP to pin the cert I get from Lets Encrypt; a cert issued for my domain some other way won’t be trusted due to the hash of its public key being different from the one I pinned. From https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key... : The Public Key Pinning Extension for HTML5…

It's worth noting that Chrome has plans to deprecate header-based pins in a few months and static pins (the ones baked into binaries) at some point after their Certificate Transparency policy covers all non-expired certificates. That'll make Firefox the only mainstream browser with HPKP support. (Mozilla hasn't announced their intentions so far.)
Post reply on HN