3 ms·

They're probably trying to say the connection will still be securely encrypted, albeit without the guarantee that communication is between you and the party / i

They're probably trying to say the connection will still be securely encrypted, albeit without the guarantee that communication is between you and the party / identity you expect on the other end (possible MITM attack scenario).

Kalium 8y ago
That strikes me as potentially a non-trivial difference.
- abugheratwork 8y ago
  I think it's one of those arguments that disappears once you account for context. No, the datestamp doesn't affect the quality of the encryption. Yes, it might matter if the last time this certificate was vouched for was 100 years ago for one year.
  - Kalium 8y ago
    I mean, I'm one of those crazy people who thinks constantly auto-renewed certs with a one-hour lifetime are a good idea. Though really only achievable when you're working with a private CA, unfortunately. With a sufficiently short lifetime, you can throw up another barrier to compromises.
    - kondro 8y ago
      Whilst I'm sure you're right, I can't think of a single instance where a compromised private key was used to impersonate a website through MiTM. 2+ year expiry on certificates has been pretty commonplace until LetsEncrypt's 90 day policy. It's absolutely possible that this could occur, but practically, the difference between a correctly issued but expired cert and a non-expired one is minor.
Karunamon 8y ago
That brings up an interesting question I'd never thought to ask before. Is there a standard in what order the attributes of a cert are checked for correctness? Say I present a self-signed, expired certificate with a bad signature and the wrong domain name. Which one does the user get warned about? This has important practical concerns. A cert being T+1 second expired is irrelevant from a security standpoint, but if that short-circuits all the other checks...

3 ms·

They're probably trying to say the connection will still be securely encrypted, albeit without the guarantee that communication is between you and the party / i

by jaytaylor 8y ago

Kalium 8y ago
That strikes me as potentially a non-trivial difference.
- abugheratwork 8y ago
  I think it's one of those arguments that disappears once you account for context. No, the datestamp doesn't affect the quality of the encryption. Yes, it might matter if the last time this certificate was vouched for was 100 years ago for one year.
  - Kalium 8y ago
    I mean, I'm one of those crazy people who thinks constantly auto-renewed certs with a one-hour lifetime are a good idea. Though really only achievable when you're working with a private CA, unfortunately. With a sufficiently short lifetime, you can throw up another barrier to compromises.
    - kondro 8y ago
      Whilst I'm sure you're right, I can't think of a single instance where a compromised private key was used to impersonate a website through MiTM. 2+ year expiry on certificates has been pretty commonplace until LetsEncrypt's 90 day policy. It's absolutely possible that this could occur, but practically, the difference between a correctly issued but expired cert and a non-expired one is minor.
Karunamon 8y ago
That brings up an interesting question I'd never thought to ask before. Is there a standard in what order the attributes of a cert are checked for correctness? Say I present a self-signed, expired certificate with a bad signature and the wrong domain name. Which one does the user get warned about? This has important practical concerns. A cert being T+1 second expired is irrelevant from a security standpoint, but if that short-circuits all the other checks...