Re: [cryptography] MalwareBytes
>> What matters is not the certificate. The certificate is public. >> You can’t “steal" a certificate. >> >> What you *can* steal is the private key associated with a >> certificate, and the more time goes by the more likely it becomes >> that someone has done so. >> >> However, the expiration date is completely arbitrary. There’s >> nothing magic that happens on the expiration date that makes a cert >> significantly less secure the day after it expires than it was the >> day before > > In principal, I think it does. > > The CA's responsibility (warranty) ends when the certificate expires. > Once the certificate is expired it will not be added to a CRL, so it > could not be revoked. In fact, if it was revoked, then it will be > removed from the CRL. Your point has relevance when discussing server certificates. If the certificate expired yesterday then be cautious, but it's likely that someone just missed the renewal notice. If it expired three years ago then be far more cautious as the site itself is more likely to be unmaintained, unpatched, breached and owned. But in this case we're discussing a code-signing certificate, and the code is still as good as it was on the day it was signed by a valid certificate. Sure, the code may be getting a little old, but that doesn't necessarily mean that it's no longer good. It's a bit like an expired government ID with a date or birth on it. Sure, that driver's license can't be used to prove I should be allowed to drive a car, but if I was 21 ten years ago when the license was valid then it still proves I'm of legal age to purchase alcohol now. J ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] MalwareBytes
Ron Garret writes: > The whole idea of an expiration date (rather than an issue date) > on a certificate is a sort of a scam by the CAs to coerce people > into renewing (and hence paying for) their certificates on a regular > schedule. I think some CAs don’t even enforce the use of a new key > when a cert is renewed, which defeats the whole purpose. Certificate expiry is useful if there isn't a way to check whether a certificate has been revoked, or if some relying parties don't check in practice, or if the revocation channel is unreliable. It's also useful if certificate issuers think information in a certificate may become inaccurate over time, but can't or don't continually check whether the information has gone stale. It's also useful, as you mentioned, if there's an ongoing risk of an undiscovered private key compromise over time. In that case the private key should be changed periodically. Finally, certificate issuees rarely actively revoke certificates when they're no longer relevant. If certificates didn't expire, there would be an enormous pool of obsolete and disused certificates that were still valid and could still potentially have their private key out there somewhere (maybe in a backup or on a decommissioned server). This also has operational consequences for CAs both in terms of OCSP and CRLs: if the CA couldn't rely on expiry, it would have to keep signing all unrevoked certificates for OCSP freshness and keep including all revoked certificates in the CRL; both the lists of revoked and unrevoked certificates could grow without bound, taxing CA resources and the resources of CRL users. For example, VeriSign might still have an ongoing requirement to publish fresh data about certificates from 1995. -- Seth Schoen Senior Staff Technologist https://www.eff.org/ Electronic Frontier Foundation https://www.eff.org/join 815 Eddy Street, San Francisco, CA 94109 +1 415 436 9333 x107 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] MalwareBytes
John R. Levine writes: > >But all of this is rather a moot point nowadays. Now that letsencrypt is > >live, there is no reason to pay for a cert any more. > > Try getting a let's encrypt cert for your mail server. Or getting an EV > cert. EV certs are definitely not available from Let's Encrypt, but you can get a certificate for your mail server by using the DNS challenge type, which just requires you to place a specified record into your DNS zone. While the Certbot client doesn't support this mechanism, several other Let's Encrypt clients, such as acme.sh, do. -- Seth Schoen Senior Staff Technologist https://www.eff.org/ Electronic Frontier Foundation https://www.eff.org/join 815 Eddy Street, San Francisco, CA 94109 +1 415 436 9333 x107 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] MalwareBytes
Authors of ransomware as a service such as encryptor RaaS steal certificates all the time. On 6/24/2016 2:30 PM, Ron Garret wrote: What matters is not the certificate. The certificate is public. You can’t “steal" a certificate. What you *can* steal is the private key associated with a certificate, and the more time goes by the more likely it becomes that someone has done so. However, the expiration date is completely arbitrary. There’s nothing magic that happens on the expiration date that makes a cert significantly less secure the day after it expires than it was the day before. The whole idea of an expiration date (rather than an issue date) on a certificate is a sort of a scam by the CAs to coerce people into renewing (and hence paying for) their certificates on a regular schedule. I think some CAs don’t even enforce the use of a new key when a cert is renewed, which defeats the whole purpose. But all of this is rather a moot point nowadays. Now that letsencrypt is live, there is no reason to pay for a cert any more. rg On Jun 24, 2016, at 10:37 AM, John Levine wrote: In article <576d6d35.3080...@gmail.com> you write: Do you want to take chances in a world of stolen certificates? Why is this certificate more likely to be stolen today than it was a week ago? It's the same certificate, it hasn't changed. R's, John On 6/24/2016 11:09 AM, Jason Richards wrote: I just downloaded the new MBAM installer. Its certificate expired 6/19/2016. Should I just ignore that fact? I wouldn't ignore it at all. The certificate that signed the code expired? If the certificate was valid when the code was signed then there should be no issues. Nothing has changed. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] MalwareBytes
EV certs are definitely not available from Let's Encrypt, but you can get a certificate for your mail server by using the DNS challenge type, which just requires you to place a specified record into your DNS zone. While the Certbot client doesn't support this mechanism, several other Let's Encrypt clients, such as acme.sh, do. I'll take a look. Startcom provides free noncommercial certs through their web site, so I've been using those. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] MalwareBytes
On Fri, Jun 24, 2016 at 2:30 PM, Ron Garret wrote: > What matters is not the certificate. The certificate is public. You can’t > “steal" a certificate. > > What you *can* steal is the private key associated with a certificate, and > the more time goes by the more likely it becomes that someone has done so. > > However, the expiration date is completely arbitrary. There’s nothing magic > that happens on the expiration date that makes a cert significantly less > secure the day after it expires than it was the day before In principal, I think it does. The CA's responsibility (warranty) ends when the certificate expires. Once the certificate is expired it will not be added to a CRL, so it could not be revoked. In fact, if it was revoked, then it will be removed from the CRL. Whether that system works in practice is a colorful subject that Dr. Gutmann does a great job of poking fun at in his book Engineering Security (http://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf). Jeff ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] MalwareBytes
But all of this is rather a moot point nowadays. Now that letsencrypt is live, there is no reason to pay for a cert any more. Try getting a let's encrypt cert for your mail server. Or getting an EV cert. R's, John ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] MalwareBytes
What matters is not the certificate. The certificate is public. You can’t “steal" a certificate. What you *can* steal is the private key associated with a certificate, and the more time goes by the more likely it becomes that someone has done so. However, the expiration date is completely arbitrary. There’s nothing magic that happens on the expiration date that makes a cert significantly less secure the day after it expires than it was the day before. The whole idea of an expiration date (rather than an issue date) on a certificate is a sort of a scam by the CAs to coerce people into renewing (and hence paying for) their certificates on a regular schedule. I think some CAs don’t even enforce the use of a new key when a cert is renewed, which defeats the whole purpose. But all of this is rather a moot point nowadays. Now that letsencrypt is live, there is no reason to pay for a cert any more. rg On Jun 24, 2016, at 10:37 AM, John Levine wrote: > In article <576d6d35.3080...@gmail.com> you write: >> Do you want to take chances in a world of stolen certificates? > > Why is this certificate more likely to be stolen today than it was a > week ago? It's the same certificate, it hasn't changed. > > R's, > John > > >> On 6/24/2016 11:09 AM, Jason Richards wrote: > I just downloaded the new MBAM installer. > > Its certificate expired 6/19/2016. > > Should I just ignore that fact? I wouldn't ignore it at all. >>> The certificate that signed the code expired? If the certificate was >>> valid when the code was signed then there should be no issues. Nothing >>> has changed. > ___ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] MalwareBytes
In article <576d6d35.3080...@gmail.com> you write: >Do you want to take chances in a world of stolen certificates? Why is this certificate more likely to be stolen today than it was a week ago? It's the same certificate, it hasn't changed. R's, John >On 6/24/2016 11:09 AM, Jason Richards wrote: I just downloaded the new MBAM installer. Its certificate expired 6/19/2016. Should I just ignore that fact? >>> I wouldn't ignore it at all. >> The certificate that signed the code expired? If the certificate was >> valid when the code was signed then there should be no issues. Nothing >> has changed. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] MalwareBytes
Do you want to take chances in a world of stolen certificates? On 6/24/2016 11:09 AM, Jason Richards wrote: I just downloaded the new MBAM installer. Its certificate expired 6/19/2016. Should I just ignore that fact? I wouldn't ignore it at all. The certificate that signed the code expired? If the certificate was valid when the code was signed then there should be no issues. Nothing has changed. Or am I missing something? J ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] MalwareBytes
>> I just downloaded the new MBAM installer. >> >> Its certificate expired 6/19/2016. >> >> Should I just ignore that fact? > > I wouldn't ignore it at all. The certificate that signed the code expired? If the certificate was valid when the code was signed then there should be no issues. Nothing has changed. Or am I missing something? J ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] MalwareBytes
I wouldn't ignore it at all. On 6/21/2016 1:25 PM, rv...@insightbb.com wrote: I just downloaded the new MBAM installer. Its certificate expired 6/19/2016. Should I just ignore that fact? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
