3 ms·

> it is literally meaningless from a cryptographic security perspective. Care to elaborate?

jaytaylor 8y ago
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...
deleted 8y ago
[deleted]
femto113 8y ago
A certificate is essentially a cryptographic key that one entity (the "issuer") asserts was issued to some other entity (the "subject"). Whether that assertion is true now, was true a day ago, or was never true does not affect the strength or usefulness of that key for cryptography. Other attributes of the key, like its bit length, do matter, but when it was issued and when it "expires" absolutely do not. I find this misleading because the implied value of the certificate to the end user, that "you can be sure you are talking to the entity you think you are talking to and nobody else", is not really what the issuer is promising. They're just saying something like "we verified the company that bought this really is named XYZ". They are NOT saying that "the entity that operates the server you're communicating with is under the control of XYZ corp". It's entirely possible for a certificate to be sold to XYZ corp, which emails the certificate to a IT consultant, which FTPs it to a Word Press hosting company that deploys it to a server run by a cohosting company where it's used to market services that are fulfilled by independent contractors. The issuer doesn't touch on anything beyond the first step in that chain but the browser's freaking out and going full red screen the second the certificate "expires" might make you think that it does.
- pathseeker 8y ago
  >but when it was issued and when it "expires" absolutely do not. Of course it does. A certificate is more than a key. It's an attestation that the signer verified that the subject was the one receiving the key. Without expiration dates, I only need to control the domain for a short period of time to get a certificate that says I am that domain forever.
- femto113 8y ago
  A specific example--right now on disasterhousing.gov I get this message in Chrome Your connection is not private Attackers might be trying to steal your information ... This server could not prove that it is disasterhousing.gov; its security certificate expired 21 days ago. This may be caused by a misconfiguration or an attacker intercepting your connection. The first statement is extremely misleading, your connection is as "private" as it ever was, since the cryptography still works and the issuer never validated the end-to-end privacy of your information server in any way. That last statement is so misleading as to be mostly just wrong. 100% of expired certificate problems in my experience are due to an organization failing to renew because of inattention ("Bob bought the certificate 2 years ago and used an email he set up on gmail because we didn't have our own mail server back then but we do now and so no one ever looks at that email so we never saw the renewal notice"). I am not aware of any attack on SSL that leverages a certificate that is valid in every way except that it has expired, other than the possibility that an old certificate fell into the attacker's hands. However it is also entirely possible for an unexpired certificate to fall into attackers' hands, and because unexpired certificates are more valuable it is more likely that is what attackers actually will steal (or forge). I think users would be better served if certificate expiration was a more subtle warning, that perhaps slowly increases its panic-inducing-messaging over long time frames.
michaelt 8y ago
Certificate expiry is intended to address things like: * If at some point in the certificate's life it was leaked, but you didn't notice and so didn't get it revoked. * If there are old certs kicking around and you're not sure of the details. e.g. previous owners of the domain, previous sysadmin who was careless with their recordkeeping, and suchlike. * If a certificate has been revoked, but CRL distribution isn't as good as we'd like so people don't know about it. * If certificate issuance rules have updated/tightened, e.g. SHA1 Deprecation. * Limits the ability of CAs to back-date certificates to get around rule tightening (which they shouldn't be doing anyway, of course, but might hope to do undetected) All of these are slow-moving security issues, so you're no more at risk the day after the cert expires than you were the day before. And hopefully not many sysadmins have problems like lost certificates, which makes the protection cert expiry offers seem redundant.

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...

deleted 8y ago

[deleted]

femto113 8y ago

A certificate is essentially a cryptographic key that one entity (the "issuer") asserts was issued to some other entity (the "subject"). Whether that assertion is true now, was true a day ago, or was never true does not affect the strength or usefulness of that key for cryptography. Other attributes of the key, like its bit length, do matter, but when it was issued and when it "expires" absolutely do not. I find this misleading because the implied value of the certificate to the end user, that "you can be sure you are talking to the entity you think you are talking to and nobody else", is not really what the issuer is promising. They're just saying something like "we verified the company that bought this really is named XYZ". They are NOT saying that "the entity that operates the server you're communicating with is under the control of XYZ corp". It's entirely possible for a certificate to be sold to XYZ corp, which emails the certificate to a IT consultant, which FTPs it to a Word Press hosting company that deploys it to a server run by a cohosting company where it's used to market services that are fulfilled by independent contractors. The issuer doesn't touch on anything beyond the first step in that chain but the browser's freaking out and going full red screen the second the certificate "expires" might make you think that it does.

pathseeker 8y ago
>but when it was issued and when it "expires" absolutely do not. Of course it does. A certificate is more than a key. It's an attestation that the signer verified that the subject was the one receiving the key. Without expiration dates, I only need to control the domain for a short period of time to get a certificate that says I am that domain forever.
femto113 8y ago
A specific example--right now on disasterhousing.gov I get this message in Chrome Your connection is not private Attackers might be trying to steal your information ... This server could not prove that it is disasterhousing.gov; its security certificate expired 21 days ago. This may be caused by a misconfiguration or an attacker intercepting your connection. The first statement is extremely misleading, your connection is as "private" as it ever was, since the cryptography still works and the issuer never validated the end-to-end privacy of your information server in any way. That last statement is so misleading as to be mostly just wrong. 100% of expired certificate problems in my experience are due to an organization failing to renew because of inattention ("Bob bought the certificate 2 years ago and used an email he set up on gmail because we didn't have our own mail server back then but we do now and so no one ever looks at that email so we never saw the renewal notice"). I am not aware of any attack on SSL that leverages a certificate that is valid in every way except that it has expired, other than the possibility that an old certificate fell into the attacker's hands. However it is also entirely possible for an unexpired certificate to fall into attackers' hands, and because unexpired certificates are more valuable it is more likely that is what attackers actually will steal (or forge). I think users would be better served if certificate expiration was a more subtle warning, that perhaps slowly increases its panic-inducing-messaging over long time frames.

michaelt 8y ago

Certificate expiry is intended to address things like: * If at some point in the certificate's life it was leaked, but you didn't notice and so didn't get it revoked. * If there are old certs kicking around and you're not sure of the details. e.g. previous owners of the domain, previous sysadmin who was careless with their recordkeeping, and suchlike. * If a certificate has been revoked, but CRL distribution isn't as good as we'd like so people don't know about it. * If certificate issuance rules have updated/tightened, e.g. SHA1 Deprecation. * Limits the ability of CAs to back-date certificates to get around rule tightening (which they shouldn't be doing anyway, of course, but might hope to do undetected) All of these are slow-moving security issues, so you're no more at risk the day after the cert expires than you were the day before. And hopefully not many sysadmins have problems like lost certificates, which makes the protection cert expiry offers seem redundant.