6 ms·

Sounds like CAs will be forced to keep shrinking cert length until everyone standardizes on 1 month. They no longer have any real power.

floatingatoll 6y ago
A less labor-intensive approach would be require CAs to revalidate the 'proof of ownership' basis of issued certificates monthly, and publish a revocation via CRL if the validation times out or fails for 1 month + 1 day. This would further encourage automation of the ecosystem without requiring redeployment in the cases where automated verification passes each month.
- waheoo 6y ago
  Misses the point. The concern is all historic traffic being vulnerable to a single encryption failure. Short cert lives make certain decloaking much, kuch more difficult.
  - gpm 6y ago
    It looks like 84% of sites [1] use forward security with modern browsers, which should mean historic traffic is not vulnerable to a leaked key. It seems like driving this number up is a better way of dealing with historic traffic than quickly expiring certs. Limiting the duration of leaks of future traffic seems like the right justification for short lived certs. [1] https://www.ssllabs.com/ssl-pulse/ https://www.ssllabs.com/ssl-pulse/
    - tialaramex 6y ago
      However in TLS 1.2 and earlier in most cases there is also a potentially long-lived key inside the server to enable faster (1-RTT) resumption. Bad guys who obtain this key get to decrypt all TLS sessions protected with that key, even if the client never used resumption at all. This is fixed in TLS 1.3, where having that long term key only lets you see inside subsequent resumptions that don't redo the DH key exchange. That recent GnuTLS bug resulted in bad guys not even needing to steal that resumption key for any servers using affected versions of GnuTLS because GnuTLS was just initialising it to zero...
  - nyanpasu64 6y ago
    I heard perfect forward secrecy is intended to prevent decrypting past traffic.
- paranoidrobot 6y ago
  Less labour intensive for whom? Anyone using email validation now needs to click a link every month, or their cert goes away. I used to have the unfortunate task of managing a massive SAN cert used for white-label hosting with a bunch of our customer's domains. Getting every single customer to get their tech person to look at the mailbox and click a link was often a multi-month process.
  - floatingatoll 6y ago
    Less labor intensive than requiring validation and deploying a new signed certificate every month.
- yjftsjthsd-h 6y ago
  One of the arguments that I've seen for shorter-lived certs is that revocations aren't honored particularly well. If we could fix that, then your proposal would make sense (but I'm not sure that's doable)
- gruez 6y ago
  >and publish a revocation via CRL if the validation times out or fails for 1 month + 1 day. If you're in a position to MITM using a stolen certificate, you're probably also in a position to block the CRL response from going through. Since failing to get an updated CRL doesn't result in a security warning, your CRL proposal is essentially useless.
  - majewsky 6y ago
    > you're probably also in a position to block the CRL response from going through Not if the certificate is OCSP-Must-Staple.
Avamander 6y ago
CAs are resting all and every changes because it's easier, it makes sense.
- londons_explore 6y ago
  CA's are resisting because the only person to buy from them is someone who can't set up certbot and lets-encrypt. As soon as they cant issue for longer than a year, their market is being whittled away.
  - majewsky 6y ago
    > the only person to buy from [CAs] is someone who can't set up certbot and lets-encrypt Digicert is in the process of migrating their customers to ACME (the issuance protocol used by Let's Encrypt and certbot). Where's your god now? :)
    - Avamander 6y ago
      And that's two out of how many?
brnt 6y ago
Will browsers start allowing self signed certificates though?
- randall 6y ago
  No... web of trust is an important aspect to https.
  - AlexandrB 6y ago
    s/web of trust/centralization/
    - judge2020 6y ago
      s/centralization/validating ownership Without centralization I can MITM at the coffee shop and steal passwords.
      - yjftsjthsd-h 6y ago
        WoT would fix that, unless the other coffee shop patrons have (directly or indirectly) trusted you.
- cpach 6y ago
  As long as you first create a root certificate then you can create how many certificates you want.
  - dingaling 6y ago
    Assuming non-chained root CAs remain trusted. I can forsee the browsers eventually treating self-created CAs like they currently treat self-signed certs. if they're not traceable to a trusted root CA then there's no accountability, from a browser perspective, in the event of abuse or breach.
    - chongli 6y ago
tptacek 6y ago
Good!

floatingatoll 6y ago

A less labor-intensive approach would be require CAs to revalidate the 'proof of ownership' basis of issued certificates monthly, and publish a revocation via CRL if the validation times out or fails for 1 month + 1 day. This would further encourage automation of the ecosystem without requiring redeployment in the cases where automated verification passes each month.

waheoo 6y ago
Misses the point. The concern is all historic traffic being vulnerable to a single encryption failure. Short cert lives make certain decloaking much, kuch more difficult.
- gpm 6y ago
  It looks like 84% of sites [1] use forward security with modern browsers, which should mean historic traffic is not vulnerable to a leaked key. It seems like driving this number up is a better way of dealing with historic traffic than quickly expiring certs. Limiting the duration of leaks of future traffic seems like the right justification for short lived certs. [1] https://www.ssllabs.com/ssl-pulse/ https://www.ssllabs.com/ssl-pulse/
  - tialaramex 6y ago
    However in TLS 1.2 and earlier in most cases there is also a potentially long-lived key inside the server to enable faster (1-RTT) resumption. Bad guys who obtain this key get to decrypt all TLS sessions protected with that key, even if the client never used resumption at all. This is fixed in TLS 1.3, where having that long term key only lets you see inside subsequent resumptions that don't redo the DH key exchange. That recent GnuTLS bug resulted in bad guys not even needing to steal that resumption key for any servers using affected versions of GnuTLS because GnuTLS was just initialising it to zero...
- nyanpasu64 6y ago
  I heard perfect forward secrecy is intended to prevent decrypting past traffic.
paranoidrobot 6y ago
Less labour intensive for whom? Anyone using email validation now needs to click a link every month, or their cert goes away. I used to have the unfortunate task of managing a massive SAN cert used for white-label hosting with a bunch of our customer's domains. Getting every single customer to get their tech person to look at the mailbox and click a link was often a multi-month process.
- floatingatoll 6y ago
  Less labor intensive than requiring validation and deploying a new signed certificate every month.
yjftsjthsd-h 6y ago
One of the arguments that I've seen for shorter-lived certs is that revocations aren't honored particularly well. If we could fix that, then your proposal would make sense (but I'm not sure that's doable)
gruez 6y ago
>and publish a revocation via CRL if the validation times out or fails for 1 month + 1 day. If you're in a position to MITM using a stolen certificate, you're probably also in a position to block the CRL response from going through. Since failing to get an updated CRL doesn't result in a security warning, your CRL proposal is essentially useless.
- majewsky 6y ago
  > you're probably also in a position to block the CRL response from going through Not if the certificate is OCSP-Must-Staple.

Avamander 6y ago

CAs are resting all and every changes because it's easier, it makes sense.

londons_explore 6y ago
CA's are resisting because the only person to buy from them is someone who can't set up certbot and lets-encrypt. As soon as they cant issue for longer than a year, their market is being whittled away.
- majewsky 6y ago
  > the only person to buy from [CAs] is someone who can't set up certbot and lets-encrypt Digicert is in the process of migrating their customers to ACME (the issuance protocol used by Let's Encrypt and certbot). Where's your god now? :)
  - Avamander 6y ago
    And that's two out of how many?

brnt 6y ago

Will browsers start allowing self signed certificates though?

randall 6y ago
No... web of trust is an important aspect to https.
- AlexandrB 6y ago
  s/web of trust/centralization/
  - judge2020 6y ago
    s/centralization/validating ownership Without centralization I can MITM at the coffee shop and steal passwords.
    - yjftsjthsd-h 6y ago
      WoT would fix that, unless the other coffee shop patrons have (directly or indirectly) trusted you.
cpach 6y ago
As long as you first create a root certificate then you can create how many certificates you want.
- dingaling 6y ago
  Assuming non-chained root CAs remain trusted. I can forsee the browsers eventually treating self-created CAs like they currently treat self-signed certs. if they're not traceable to a trusted root CA then there's no accountability, from a browser perspective, in the event of abuse or breach.
  - chongli 6y ago

tptacek 6y ago

Good!