Re: Verisign CRL single point of failure
Can someone explain to me why the expiring of a certificate causes new massive CRL queries? /r$ -- Rich Salz, Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: Verisign CRL single point of failure
>>I don't think you understood my question. Why is crl.verisign.com >>getting overloaded *now.* What does the expiration of one of their CA >>certificates have to do with it? Once you see that a cert has expired, >>there's no need whatsoever to go look at the CRL. The point of a CRL is >>to revoke certificates prior to their expiration. You are correct I did miss your point in haste. I cannot answer that, but I can tell you that disabling the function or uninstalling NAV that has CRL function, fixes the problem immediately. And if you watch your firewall as the clients open a file that requests a virus scan they all try to hit crl.verisign.com. This has been happening since the 7th when that cert expired. DK - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Verisign CRL single point of failure
dave kleiman wrote: Because the client has a Certificate Revocation Checking function turned on in a particular app (i.e. IE or NAV). I don't think you understood my question. Why is crl.verisign.com getting overloaded *now.* What does the expiration of one of their CA certificates have to do with it? Once you see that a cert has expired, there's no need whatsoever to go look at the CRL. The point of a CRL is to revoke certificates prior to their expiration. /r$ -- Rich Salz, Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Verisign CRL single point of failure
Rich Salz <[EMAIL PROTECTED]> writes: >Can someone explain to me why the expiring of a certificate causes new >massive CRL queries? Here's the reply straight from Verisign: -- Snip -- We wanted to pass on a notification that we have determined what we feel is the root cause of the CRL outage issue. It appears that at midnight GMT (4pm PST) on January 7, 2004, VeriSign experienced a sudden and dramatic increase in the number of requests by Windows-based clients to download a certificate revocation list (CRL). The CRL is a file which confirms the validity status of a set of certificates, and is used by applications and users to determine whether a particular certificate has been revoked between the time it was issued and the time it will expire. The CRL in question was for a code-signing application. VeriSign normally serves up several million CRLs per hour. These CRLs typically have one- to two-week validity periods, and client applications using CRLs will check for an update as the CRL expires. The Code Signing CRL was supplied to a large number of Windows clients. When that CRL expired, those clients simultaneously requested a particularly large CRL file, resulting in an eight-fold increase in traffic at the site crl.verisign.com, where VeriSign hosts all our CRLs. As a result, As a result, Windows-based browsers requesting status of certain server certificates have experienced intermittent delays. VeriSign has increased its capacity to handle these requests by 10 fold in the past 8 hours. As the particular code-signing CRL file is no longer a dynamically changing, there will be no need for clients, once they have downloaded this file, to request a new version of this particular CRL. While this does not represent a security risk, it may have represented a performance degradation for some users. VeriSign regrets the inconvenience caused to customers, and has implemented procedures both internally, and with our partners, to ensure that this problem does not reoccur. Please note that this problem is in no way related to the Intermediate CA expiration issue discussed on our site at < http://www.verisign.com/support/vendors/exp-gsid-ssl.html?sl=070807>. Although the expiration dates are the same, it is strictly a coincidence in timing. -- Snip -- ObComment again: Ahh, the wonders of doing an online CRL fetch that feeds you information that's two weeks out of date. I'm not sure what the "no longer dynamically changing" means, I assume they've made it even worse by giving it a much larger expiry period, so your online check gives you the status from last year instead of last week. Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Verisign CRL single point of failure
> I'm not sure what the "no longer > dynamically changing" means, I assume they've made it even worse by giving > it a much larger expiry period, so your online check gives you the status > from last year instead of last week. It means that they learned the lesson when the erroneously issued two MSFT certificates: In the future, VRSN patches will be issued as MSFT software updates. -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Verisign CRL single point of failure
Verisign incorrectly built the new certificate causing every SSL access on IE 5.x to request a new CRL (700k) on every single SSL access. This has been fixed, a new udated cert is available and the CRL storm is abating. See the versign site for more details on what they did to fix the problem, but nothing of course on what they did wrong. Note that two separte certs expired at the same time so there were two competing DOS attacks simultaneously. hth ..tom > Can someone explain to me why the expiring of a certificate causes new > massive CRL queries? > /r$ > > -- > Rich Salz, Chief Security Architect > DataPower Technology http://www.datapower.com > XS40 XML Security Gateway http://www.datapower.com/products/xs40.html > XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Verisign CRL single point of failure
On Jan 9, 2004, at 8:06 PM, Rich Salz wrote: dave kleiman wrote: Because the client has a Certificate Revocation Checking function turned on in a particular app (i.e. IE or NAV). I don't think you understood my question. Why is crl.verisign.com getting overloaded *now.* What does the expiration of one of their CA certificates have to do with it? Once you see that a cert has expired, there's no need whatsoever to go look at the CRL. The point of a CRL is to revoke certificates prior to their expiration. Though I have no particular experience with the virus-scan software; we've seen exactly this behavior with a couple of medical app's build onto the same libraries. Once any cert in the bundle is expired the software -insists- on checking with the CRL at startup. And it will hang if it cannot. When it gets the info back - It does not cache the (negative) information; nor does that seem to trigger any clever automated roll-over. We tried tricking it with flags like 'superseded' and cessationOfOperation in the reasons/cert status mask - but no avail. The only workaround we've found is to remove all expired certs from the system asap. My guess it is just a bug in a library; albeit a commonly used one. Dw. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
