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

Acme, a brief history of one of the protocols which has changed the Internet

blog.brocas.org

Post reply on HN
Print view View original

11–20 of 91 posts

Re: Acme, a brief history of one of the protocols which has changed the Internet

#11

Post by stavros »

tiagod wrote: post #9
gerdesj wrote: post #6

I remember deploying SSL on NetWare in the late 1990s and being given ... something that the US allowed to be exported as a munition! I don't recall the exact details but it was basically buggered - short key length. Long enough to challenge a 80386 Beowulf cluster but no match for whatever was humming away in a very well funded machine room. You could still play with all the other exciting dials and knobs, SANs and…

A few years ago a client of mine gave me a big-ish APC UPS. I recently got new batteries for it after the outage here in Portugal, and to turn on SSH I had to agree that I was not a terrorist organisation's nor in a country where encryption can not be exported to.

I'm glad it had that. If you were, say, a member of ISIS and used the UPS, they'd be able to successfully sue you for breach.

Re: Acme, a brief history of one of the protocols which has changed the Internet

#12

Post by ryandv »

wakawaka28 wrote: post #10
dbt00 wrote: post #7

Earlier quoted context omitted.

A signature on a certificate doesn't allow CA to snoop. They need access to the private key for that, which ACME (and other certificate signing protocols in general) doesn't share with the CA.

I know that. But presumably, Let's Encrypt could participate in a MITM attack since they can sign another key, so that even the visitor who knows that you use them as a CA can't tell there is a MITM. Checking multiple signatures on the same key could raise the bar for a MITM attack, requiring multiple CA's to participate. I can't be the first person to think of this. I'm not even a web security guy. It might be inter…

The signing keys used by the Certificate Authority to assert that the client (leaf) certificate is authentic through cryptographic signing differ from the private keys used to secure communication with the host(s) referenced in the x509 CN/SAN fields.

Re: Acme, a brief history of one of the protocols which has changed the Internet

#13

Post by neilv »

wakawaka28 wrote: post #5

Has anyone considered the possibility that a CA such as Let's Encrypt could be compromised or even run entirely by intelligence operatives? Of course, there are many other CAs that could be compromised and making money off of customers on top of that. But who knows... What could defend against this possibility? Multiple signatures on a certificate?

Even funnier, if one SIGINT team built a centralized "encryption everywhere" effort (before sites get encryption elsewhere), but that asset had to be need-to-know secret, so another SIGINT team of the same org, not knowing the org already owned "encryption everywhere", responded to the challenge by building a "DoS defense" service that bypasses the encryption, and started DoS driving every site of interest to that service.

(Seriously: I strongly suspect that Let's Encrypt's ISRG are the good guys. But a security mindset should make you question everything, and recognize when you're taking something on faith, or taking a risk, so that it's a conscious decision, and you can re-evaluate it when priorities change.)

Re: Acme, a brief history of one of the protocols which has changed the Internet

#14

Post by wakawaka28 »

ryandv wrote: post #12
wakawaka28 wrote: post #10

Earlier quoted context omitted.

I know that. But presumably, Let's Encrypt could participate in a MITM attack since they can sign another key, so that even the visitor who knows that you use them as a CA can't tell there is a MITM. Checking multiple signatures on the same key could raise the bar for a MITM attack, requiring multiple CA's to participate. I can't be the first person to think of this. I'm not even a web security guy. It might be inter…

The signing keys used by the Certificate Authority to assert that the client (leaf) certificate is authentic through cryptographic signing differ from the private keys used to secure communication with the host(s) referenced in the x509 CN/SAN fields.

I know that. At issue is the fact that the signing keys can be used to sign a MITM key. If there were multiple signatures on the original key, it would (or could) be a lot harder to MITM (presumably). Do you trust any CA enough to never be involved in this kind of scandal? Certainly government CA's and corporate CA's MITM people all the time.

Edit: I'm gonna be rate limited, but let me just say now that Certificate Transparency sounds interesting. I need to look into that more, but it amounts to a 3rd party certificate verification service. Now, we have to figure out how to connect to that service securely lol... Thanks, you've given me something to go read about.

Re: Acme, a brief history of one of the protocols which has changed the Internet

#15

Post by coffee-- »

wakawaka28 wrote: post #14
ryandv wrote: post #12

Earlier quoted context omitted.

The signing keys used by the Certificate Authority to assert that the client (leaf) certificate is authentic through cryptographic signing differ from the private keys used to secure communication with the host(s) referenced in the x509 CN/SAN fields.

I know that. At issue is the fact that the signing keys can be used to sign a MITM key. If there were multiple signatures on the original key, it would (or could) be a lot harder to MITM (presumably). Do you trust any CA enough to never be involved in this kind of scandal? Certainly government CA's and corporate CA's MITM people all the time. Edit: I'm gonna be rate limited, but let me just say now that Certificate T…

This is where Certificate Transparency -- and it being mandatory for browser trust -- comes in to save the day.

Re: Acme, a brief history of one of the protocols which has changed the Internet

#16

Post by wakawaka28 »

neilv wrote: post #13
wakawaka28 wrote: post #5

Has anyone considered the possibility that a CA such as Let's Encrypt could be compromised or even run entirely by intelligence operatives? Of course, there are many other CAs that could be compromised and making money off of customers on top of that. But who knows... What could defend against this possibility? Multiple signatures on a certificate?

Even funnier, if one SIGINT team built a centralized "encryption everywhere" effort (before sites get encryption elsewhere), but that asset had to be need-to-know secret, so another SIGINT team of the same org, not knowing the org already owned "encryption everywhere", responded to the challenge by building a "DoS defense" service that bypasses the encryption, and started DoS driving every site of interest to that se…

Sounds like Cloudflare honestly. There are many issues with CA trust in the modern Internet. The most paranoid among us would do well to remove every trusted CA key from their OS and build a minimal set from scratch, I suppose. Browsers simply make it too easy to overlook CA-related issues, especially if you think a CA is compromised or malicious.

Re: Acme, a brief history of one of the protocols which has changed the Internet

#17

Post by 336611629 »

wakawaka28 wrote: post #10
dbt00 wrote: post #7

Earlier quoted context omitted.

A signature on a certificate doesn't allow CA to snoop. They need access to the private key for that, which ACME (and other certificate signing protocols in general) doesn't share with the CA.

I know that. But presumably, Let's Encrypt could participate in a MITM attack since they can sign another key, so that even the visitor who knows that you use them as a CA can't tell there is a MITM. Checking multiple signatures on the same key could raise the bar for a MITM attack, requiring multiple CA's to participate. I can't be the first person to think of this. I'm not even a web security guy. It might be inter…

This problem was solved in the mid 2010s by Certificate Transparency. Every issued certificate that browsers trust must be logged to a public append-only certificate transparency log. As a result, you can scan the logs to see if any certs were issued for your domain for keys that you don't control (and many tools and companies exist to do this).

Re: Acme, a brief history of one of the protocols which has changed the Internet

#18

Post by zzo38computer »

dbt00 wrote: post #7
wakawaka28 wrote: post #5

Has anyone considered the possibility that a CA such as Let's Encrypt could be compromised or even run entirely by intelligence operatives? Of course, there are many other CAs that could be compromised and making money off of customers on top of that. But who knows... What could defend against this possibility? Multiple signatures on a certificate?

A signature on a certificate doesn't allow CA to snoop. They need access to the private key for that, which ACME (and other certificate signing protocols in general) doesn't share with the CA.

If the CA is somehow able to control the communication (I think usually they don't, but if they are being run by intelligence operatives then maybe they have that capability, although they probably do not use it a lot if so (in order to reduce the chance of being detected)), they could substitute a certificate with their own keys (and then communicate with the original server using the original keys in order to obtain the information required). However, this does not apply if both sides verify by an independent method that the key is correct (and if not, would allow to detect it).

Adding multiple signatures to a certificate would be difficult because the extensions must be a part of the certificate which will be signed. (However, there are ways to do such thing as web of trust, and I had thought of ways to do this with X.509, although it does not normally do that. Another way would be an extension which is filled with null bytes when calculating the extra signatures and then being filled in with the extra signatures when calculating the normal signature.)

(Other X.509 extensions would also be helpful for various reasons, although the CAs might not allow that, due to various requirements (some of which are unnecessary).)

Another thing that helps is using X.509 client certificates for authentication in addition to server certificates. If you do this, then any MITM will not be able to authenticate (unless at least one side allows them to do so). X.509 client authentication has many other advantages as well.

In addition, it might be helpful to allow you to use those certificates to issue additional certificates (e.g. to subdomains); but, whoever verifies the certificate (usually the client, but it can also be the server in case of a client certificate) would then need to check the entire certificate chain to check the permissions allowed by the certificate.

There is also the possibility that certificate authorities will refuse to issue certificates to you for whatever reasons.

Re: Acme, a brief history of one of the protocols which has changed the Internet

#20

Post by throw0101a »

dbt00 wrote: post #7
wakawaka28 wrote: post #5

Has anyone considered the possibility that a CA such as Let's Encrypt could be compromised or even run entirely by intelligence operatives? Of course, there are many other CAs that could be compromised and making money off of customers on top of that. But who knows... What could defend against this possibility? Multiple signatures on a certificate?

A signature on a certificate doesn't allow CA to snoop. They need access to the private key for that, which ACME (and other certificate signing protocols in general) doesn't share with the CA.

> They need access to the private key for that, which ACME (and other certificate signing protocols in general) doesn't share with the CA.

Modern TLS doesn't even rely on the privacy of the private key 'as much' as it used: nowadays with (perfect) forward secrecy it's mainly used to establish trust, and after which the two parties generate transient session keys.

* https://en.wikipedia.org/wiki/Forward_secrecy

So even if the private key is compromised sometime in the future, past conversation cannot be decrypted.

Post reply on HN