4 ms·

why not provide an advanced feature that alerts you any time a cert changes Because certificates change ... all ... the ... time. Again ... and ... again ... a

why not provide an advanced feature that alerts you any time a cert changes Because certificates change ... all ... the ... time. Again ... and ... again ... and ... again. Years ago I tried using a Firefox addon called Certificate Patrol. I spent half my time approving changes. Here's a Stack Exchange question on exactly that topic. It's a few years old; I don't know if things have gotten better: https://security.stackexchange.com/questions/41578/why-does-google-ssl-cert-change-so-frequently https://security.stackexchange.com/questions/41578/why-does-...

posixplz 9y ago
I imagine things have only gotten "worse" with Let'sEncrypt issuing 90 certificates.
- Confiks 9y ago
  You pin a public key (of which the private key signs the leaf certificate, the sub-CA or the CA) with HPKP, not the certificate. With the default settings, LetsEncrypt re-uses the keypair for a new certificate.
wnevets 9y ago
>Years ago I tried using a Firefox addon called Certificate Patrol. yeah I too gave up on using that addon for the same reason
lucb1e 9y ago
> Because certificates change ... all ... the ... time. Not OP but I do see potential there. I've thought about it before. Try looking at it from a solution perspective rather than from "why don't we already" and "what would the issues be": certs change, yeah, but usually because they (almost) expired. We should check when Let'sEncrypt renews by default (is that 14 days before expiry?) and what common practice is, and go from there in triggering a warning. And if there is some uncommon reason to roll over (e.g. suspected compromise), a header could be set either in advance or one could be set that signs the new fingerprint with the old key. The new one shouldn't be pinned right away since an attacker might have misused a compromised key, and a warning symbol could be displayed similar to the mixed-content warning. If someone is suspicious and it can't be delayed, they can call their bank (or whatever it is) and they'd know about it and be able to confirm things out of band. I'm just conceptualizing but I don't see anything that's not easily solved. I think it could be a good addition.
- schoen 9y ago
  > We should check when Let'sEncrypt renews by default (is that 14 days before expiry?) 30 days in Certbot defaults, and I think that's an official Let's Encrypt recommendation for authors of other clients.
- user5994461 9y ago
  The big sites have multiple certificates for a single domain and you will get one randomly depending on what server you happen to it.
emmelaich 9y ago
Why not have it approve an ultimate CA instead? Or least one up in the chain.
saas_co_de 9y ago
I agree that the utility of this feature would be limited to a small percent of users for a small percent of cases. The SSH example comes to mind because that is a system that does something similar. In my experience every single SSH error on a key change has been a false positive but everyone accepts the high false positive rate because it is worth it to detect that one case where you are actually compromised.
- daira 9y ago
  But you don't detect that one case where you are actually compromised. You dismiss it like you do all the false positives. At best, when you get pwned you think back to having dismissed the key change warning and know what happened, but how does that actually help you?
  - scott00 9y ago
    I actually caught a semi-real one once. My new employer was MITMing all ssh traffic.
  - saas_co_de 9y ago
    this does not follow at all. any time a cert has changed i either know the cause or verify the cause before using the server.

posixplz 9y ago

I imagine things have only gotten "worse" with Let'sEncrypt issuing 90 certificates.

Confiks 9y ago
You pin a public key (of which the private key signs the leaf certificate, the sub-CA or the CA) with HPKP, not the certificate. With the default settings, LetsEncrypt re-uses the keypair for a new certificate.

wnevets 9y ago

>Years ago I tried using a Firefox addon called Certificate Patrol. yeah I too gave up on using that addon for the same reason

lucb1e 9y ago

> Because certificates change ... all ... the ... time. Not OP but I do see potential there. I've thought about it before. Try looking at it from a solution perspective rather than from "why don't we already" and "what would the issues be": certs change, yeah, but usually because they (almost) expired. We should check when Let'sEncrypt renews by default (is that 14 days before expiry?) and what common practice is, and go from there in triggering a warning. And if there is some uncommon reason to roll over (e.g. suspected compromise), a header could be set either in advance or one could be set that signs the new fingerprint with the old key. The new one shouldn't be pinned right away since an attacker might have misused a compromised key, and a warning symbol could be displayed similar to the mixed-content warning. If someone is suspicious and it can't be delayed, they can call their bank (or whatever it is) and they'd know about it and be able to confirm things out of band. I'm just conceptualizing but I don't see anything that's not easily solved. I think it could be a good addition.

schoen 9y ago
> We should check when Let'sEncrypt renews by default (is that 14 days before expiry?) 30 days in Certbot defaults, and I think that's an official Let's Encrypt recommendation for authors of other clients.
user5994461 9y ago
The big sites have multiple certificates for a single domain and you will get one randomly depending on what server you happen to it.

emmelaich 9y ago

Why not have it approve an ultimate CA instead? Or least one up in the chain.

saas_co_de 9y ago

I agree that the utility of this feature would be limited to a small percent of users for a small percent of cases. The SSH example comes to mind because that is a system that does something similar. In my experience every single SSH error on a key change has been a false positive but everyone accepts the high false positive rate because it is worth it to detect that one case where you are actually compromised.

daira 9y ago
But you don't detect that one case where you are actually compromised. You dismiss it like you do all the false positives. At best, when you get pwned you think back to having dismissed the key change warning and know what happened, but how does that actually help you?
- scott00 9y ago
  I actually caught a semi-real one once. My new employer was MITMing all ssh traffic.
- saas_co_de 9y ago
  this does not follow at all. any time a cert has changed i either know the cause or verify the cause before using the server.