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

New Intermediate Certificates

letsencrypt.org

Post reply on HN
Print view View original

41–50 of 57 posts

Re: New Intermediate Certificates

#41

Post by michaelt »

patmorgan23 wrote: post #31
Wowfunhappy wrote: post #23

Earlier quoted context omitted.

What prevents the user from simply setting their clock forward? (I do agree cert pinning is bad overall.)

If the user wants to ignore cert error they're going to ignore cert errors

Pinning your CA's certificate protects against two things:

1. All-powerful NSA types who've managed to steal a CA's private key or get a certificate mis-issued. It's a nigh-irreplaceable attack opportunity, but the moment they use it it'll be revoked within hours, so naturally it's reserved for the absolute highest value target. For example, [1]

2. Users trying to reverse-engineer your app.

You can imagine which of these is the most common - perhaps you don't want the user to be able to bypass the pin, even intentionally.

[1] https://www.eff.org/deeplinks/2011/08/iranian-man-middle-att...

Re: New Intermediate Certificates

#42

Post by jcalvinowens »

toast0 wrote: post #38
jcalvinowens wrote: post #30

Earlier quoted context omitted.

Absolutely, I agree with everything you said. Pinning is not an effective anti-reverse-engineer technique. It's just annoying obfuscation to anybody who knows what they're doing.

Pinning isn't really for anti-revere-engineering. It does discourage some reverse engineers, which is a bonus. But it's main purpose is to protect data integrity between the client and the server --- there's plenty of cases of CAs in system root stores that issued certs that could be used to intercept and manipulate traffic. There's also plenty of cases where something installed on the user's device adds itself to th…

That's sort of outside the threat model though, isn't it? If an attacker can install a root cert, the entire thing is compromised.

If you're concerned about that and want to pin, why have a chain of trust at all? Couldn't you just embed self-signed certs in the binary at that point?

If you mean preventing users from clicking through the SSL warnings in a browser if they're being MITM'd, that makes sense to me.

Re: New Intermediate Certificates

#44

Post by chaz6 »

mcpherrinm wrote: post #7
phantom784 wrote: post #2

Interesting that they wish to discourage key pinning. This is pretty commonly used by apps to make them harder to reverse engineer. It prevents you from installing your own cert in the system's trust store and then using that to man-in-the-middle the app's communication with its backend.

It's important to note that this is preventing pinning /intermediates/ which are re-issued about annually. It is usually a mistake to do that. It is possible that due to a large-scale incident, we'd have to revoke an intermediate immediately and switch to a backup. While we don't recommend key pinning, there's nothing to prevent pinning Let's Encrypt's root CAs. (I work for Let's Encrypt)

Do clients generally check for revocation for every cert in the chain? You would think you would definitely want to as a compromised root cert would be highly damaging!

Re: New Intermediate Certificates

#45

Post by toast0 »

jcalvinowens wrote: post #42
toast0 wrote: post #38

Earlier quoted context omitted.

Pinning isn't really for anti-revere-engineering. It does discourage some reverse engineers, which is a bonus. But it's main purpose is to protect data integrity between the client and the server --- there's plenty of cases of CAs in system root stores that issued certs that could be used to intercept and manipulate traffic. There's also plenty of cases where something installed on the user's device adds itself to th…

That's sort of outside the threat model though, isn't it? If an attacker can install a root cert, the entire thing is compromised. If you're concerned about that and want to pin, why have a chain of trust at all? Couldn't you just embed self-signed certs in the binary at that point? If you mean preventing users from clicking through the SSL warnings in a browser if they're being MITM'd, that makes sense to me.

> If you're concerned about that and want to pin, why have a chain of trust at all? Couldn't you just embed self-signed certs in the binary at that point?

Not if you need to serve https traffic to clients and browsers from the same servers / same hostnames.

> If you mean preventing users from clicking through the SSL warnings in a browser if they're being MITM'd, that makes sense to me.

That comes from HSTS, not from cert pinning. Cert pinning in browsers is only available if you can convince the browser to include it in their static lists, which means you've got to be big... so that is what it is.

Re: New Intermediate Certificates

#46

Post by thrtythreeforty »

schoen wrote: post #27
gray_-_wolf wrote: post #26

Earlier quoted context omitted.

> Please don't pin roots So what would be the recommended way to protect against government MitM by using some obscure CA?

Currently CT logs: https://certificate.transparency.dev/ Monitor CT for your domain name and if you find an "obscure CA" misissuing for your domain, report it! This may result in the obscure CA getting explicitly distrusted. At some level this is not that great a solution, but it's really so much better than what we had 13-14 years ago.

I'm curious: What's the defense mechanism for a dodgy CA not publishing a CT log entry for the misused domain?

Re: New Intermediate Certificates

#47

Post by woodruffw »

thrtythreeforty wrote: post #46
schoen wrote: post #27

Earlier quoted context omitted.

Currently CT logs: https://certificate.transparency.dev/ Monitor CT for your domain name and if you find an "obscure CA" misissuing for your domain, report it! This may result in the obscure CA getting explicitly distrusted. At some level this is not that great a solution, but it's really so much better than what we had 13-14 years ago.

I'm curious: What's the defense mechanism for a dodgy CA not publishing a CT log entry for the misused domain?

A CT-honoring client should reject an end-entity certificate that isn't accompanied by a SCT. In other words: a dodgy CA that skips CT to avoid disclosure of their mis-issued certificate should be unable to convince any CT-honoring client to accept that certificate.

Re: New Intermediate Certificates

#48

Post by vbezhenar »

aaomidi wrote: post #15
vbezhenar wrote: post #11

Earlier quoted context omitted.

You must pin your own key, not certbot key.

What does this mean?

By certbot key I mean letsencrypt key, sorry for confusion.

That means that you need to hard-code the public key of the certificate that you're using in the client application. That certificate might be signed by letsencrypt or any other CA, it doesn't matter. If you're pinning CA key, you put trust into entity which you don't control. They can replace any of their keys. They can stop signing your certificate. It makes little sense to pin CA certificates.

Just make sure to have a plan for key rotation in case you need to revoke your key.

Re: New Intermediate Certificates

#49

Post by vbezhenar »

withinboredom wrote: post #40
djbusby wrote: post #14

Earlier quoted context omitted.

What is improper about them? Works for 100% of my use case, well known, trusted, compatible.

What I mean is, if you want to pin certificates, purchase a certificate that expires in years, not months.

You pin public key, not certificate. You can keep your private key for whatever period you want and issue multiple certificates with the same public key.

Re: New Intermediate Certificates

#50

Post by tomputer »

jcalvinowens wrote: post #25
tialaramex wrote: post #22

Earlier quoted context omitted.

I'd recommend pinning (your) keys because knowing cert SHAs ahead of time means you need the certificates themselves and in a nasty situation the CAs you relied on to issue those certs may be out of the picture, if you're pinning a key that's fine, CA #5 will cheerfully issue you a brand new certificate against the same key you were using with CA #1 before something went badly wrong - but with cert SHAs you have to b…

I completely disagree with you: reusing private keys is an enormous vulnerability. It's really important to rotate them. It's very easy to avoid the pitfall you mentioned by having multiple valid certs with different expiry dates. You can easily use multiple CAs. Done your way, a single leaked private key means your entire site is compromised indefinitely. That's unacceptable to me.

> reusing private keys is an enormous vulnerability.

As long as the private key is stored/handled safely and RSA/ECC is not broken, it is not vulnerable.

I do agree that key rotation is better/recommended practice.

> a single leaked private key means your entire site is compromised

The leak is the actual vulnerability. As long as the leak is still there and you are not aware of the compromised private key, a fresh new private key will probably leak again.

However, the chances of leaking may be greater if a private key has to be used in multiple locations.

Post reply on HN