Pinning and SHA1 migration


#1

Continuing the discussion from Pros and cons of 90-day certificate lifetimes:

I think it should be possible to satisfy your pins even during this transition. For instance, did you have a backup key? You should be able to get that key signed by a SHA-2 CA and have things work.


Pros and cons of 90-day certificate lifetimes
#2

We didn’t a second backup key but I think we were changing key length at the same time so I’m not sure we would have been able to get away with it anyway ? We’ve always seen certificates (And key-pairs) as being throw-away for the reason that a key which is rotated more often exposes less data if (When) it is broken.

@piano
That’s a very big if. Why would you trust the CA trust model?

It’s thoroughly broken for the purposes of defending against nation-states, and partly broken even for defending against smaller attackers.

Well if you don’t trust the CA trust model, there’s little point in using commercial certificates in my opinion. Yes the model has its flaws but security will always have it’s limitations and you have to draw the line somewhere. I personally draw that line at the CA trust model as suspect that this is a common place where people draw the line. A CA’s reputation (Which is everything to a CA) is on the line, so if they break that trust for the sake of snooping they have too much to lose to make it a truly viable attack vector - A CA might as well close its doors rather than meet a request to sign a false certificate for a snooping agency.


#3

Not at all. The unreliability of one trust model does not mean it is worthless, it means it needs to be bolstered and complemented by extra methods.

The point in using a CA is so users can access the site without browser warnings, and to raise the bar (slightly) for attackers. Which doesn’t mean that’s enough on its own.

Do you really believe that? With all the resources and pressure that such an agency has to throw at the problem?

Not to mention that persuading a CA to co-operate is not the only option (hacking, infiltration, secret legal orders).

Not to mention that an attacker only needs to compromise one of the huge number of CAs in order to be successful.

Take a look at how many there are:
https://notary.icsi.berkeley.edu/trust-tree/

Some of those are probably owned by snooping agencies, never mind compromised.

I repeat, all it takes is one of them to be hacked, bribed, infiltrated, court ordered or pressured to undermine the whole thing.

It’s broken.


#4

Yes I do believe that. As soon as a CA is detected as having been compromised, it’s removed from the major browsers faster than you can … well pin a certificate. There have been a number of CAs that have been compromised in one way or another and it ended the same for them all.

There’s another disadvantage I can think of and it is if you have multiple load-balanced servers. If you’re automatically issuing certificates on each server, you’ll end up with a different certificate on each server. Each server will pin its own key and these will differ unless you start sharing the key between servers some how, or performing the certificate requests at a centralised location and pushing them out across all of the servers. (Which may even be in different countries)


#5

Depends on your definition of compromised. Various CAs have “accidentally” issued certificates for major websites, and are still trusted. Symantec is one of the more recent examples: https://googleonlinesecurity.blogspot.co.at/2015/10/sustaining-digital-certificate-security.html
I guess “Too Big To Fail” applies to CAs as well. :smiley:

It’s not too far-fetched to think that multiple CAs were compromised (pwned via exploits or by various agencies) for targeted attacks in the past, without anyone noticing. Certificate Transparency and pinning mechanisms will go a long way here.


#6

I wasn’t aware of those issues with Symantec but it is very interesting to see how it was handled. It sounds like the staff responsible were fired (“Finally, we have already enforced accountability given that we take a“no compromise” approach to violations of our policies.”) and Symantec have to just through a number of serious hoops to retain their trust status. I’m not sure how the other browsers reacted, but I suspect that they were satisfied with Google’s response and demands.

I would have believe that if these certificates had have been exposed or mi-used and weren’t one-day test certificates the response would have been much more serious, given how serious the response was even for this somewhat harmless breach of policy. (By that I mean that it was very serious, but didn’t have any repercussions on users at this time)

Perhaps I was wrong in suggesting that pinning offers little benefit, but I stand by my thoughts that the benefits of pinning do not outweigh the negatives. (For end users that is, I guess that for machine-to-machine usage pinning makes more sense.)


#7

My personal opinion is that pinning’s advantages outweigh its benefits, but it depends on the site and the circumstances. When I was at Twitter, I implemented move from HTTP to HTTPS-by-default, which included pinning. We pinned to several CAs and a backup key to ensure that we could always serve a certificate that satisfied our pins. Other than some very occasional problems with a subdomain that hosted a different certificate, we never had a problem.

That said, there’s a big risk when pinning, especially if you choose to pin leaf keys instead of CAs. I think we probably won’t see a world where every HTTPS site pins, but I think that’s okay.


#8

So would I be right in thinking that your suggested pinning would be against “Let’s Encrypt Authority X1” and “Let’s Encrypt Authority X2” ? I had always read that you should always pin on certificates that you control as you don’t know how the CA may rotate keys, but I suppose if the CA themselves define this process then it would be safe and would get around the load balanced server and leaf certificate key rotation issues.

What is Let’s Encrypt’s policy on key rotation for these two certificates ? Am I right in thinking that X2 is never expected to be unintentionally exposed as it isn’t currently in use and that if X1’s key is exposed, it will be revoked and X2 will take over as-is ? Will the X1 and X2 keys ever be rotated at the same time and if not what is the minimum gap between rotations for setting the pinning expiry ?


#9

More detailed HPKP advice is in HPKP best practices if you choose to implement, which I helped edit.

LEAX1 and LEAX2 will always have the same keys. In the future we may generate new intermediates with new keys, and sign from those.


#10

Thank you Jacob, will respond with some further queries in that thread.