Private Keys Stolen Within Hours From Heartbleed OpenSSL Site 151
Billly Gates (198444) writes "It was reported when heartbleed was discovered that only passwords would be at risk and private keys were still safe. Not anymore. Cloudfare launched the heartbleed challenge on a new server with the openSSL vulnerability and offered a prize to whoever could gain the private keys. Within hours several researchers and a hacker got in and got the private signing keys. Expect many forged certificates and other login attempts to banks and other popular websites in the coming weeks unless the browser makers and CA's revoke all the old keys and certificates."
Even root CA certificates may be at risk. (Score:4, Insightful)
Be aware that even the root CA certificates can be at risk right now, and that can really cause problems.
Re:Even root CA certificates may be at risk. (Score:5, Informative)
Depends. A website's SSL key may be slurped up. However, a root CA key should be either kept on an offline machine or kept in a hardware security module where the key won't be divulged, ever... the module will sign a key, and that's it.
I'm sure some places will have their root CA on an externally connected machine, then try to place blame, likely saying how insecure UNIX is (when it isn't any particular flavor of UNIX that is at fault.)
Re: (Score:2)
I'm sure some places will have their root CA on an externally connected machine, then try to place blame, likely saying how insecure UNIX is (when it isn't any particular flavor of UNIX that is at fault.)
Since this is in violation of the CA/Browser forum rules and Mozilla policies that pertain to trusted CA certificates; they are either lying, grossly negligent, OR both: if they have a root CA's private key ever loaded into an externally connected machine.
In fact.... a CA root certificate itself, is
Re: (Score:2)
You would not believe what VP's will force you to do to get their $20 million flagship project out the door and then quickly forgotten about after the guy that was forced to do it quits in disgust. There was a time when I'd be surprised by insanely stupid security vulnerabilities but after a few years in the trade I've learned never to be surprised by anything.
Re: (Score:3)
You would not believe what VP's will force you to do to get their $20 million flagship project out the door and then quickly forgotten about after the guy that was forced to do it quits in disgust.
Fraud that can get you in jail is not one of those things that some VP can force you to do.
The CA has to be validated by third party auditors, before it can even be trusted. One of the aspects that must be audited is the governance of that CA and the policies and controls of the CA designed to ensure the CA
Re: (Score:2)
The CA has to be validated by third party auditors, before it can even be trusted.
All those big box stores that got their credit card numbers hacked....
Validated by third party auditors.
IIRC, one of the stores was actively being exploited throughout the audit process and still passed.
Re:Even root CA certificates may be at risk. (Score:5, Funny)
That is BS. Nobody sane installs a root certificate on productive network-connected hardware, unless they are terminally stupid. Oh, wait...
Re: (Score:2)
https is dead (Score:5, Funny)
For all practical purposes, https is dead. There is no way browsers will carry around the hundreds of thousands of possibly-stolen-so-unsafe certificates fingerprints (to consider these tainted/revoked). The only way forward is probably to move away to an incompatible protocol. And if possible, cure some of the X509 wrong ways.
Re:https is dead (Score:5, Insightful)
Nah, the browsers will just reset 'zero epoch' for SSL certificates they'll accept to ONLY accept certificates issued after some date post-exploit, and all major SSL vendors will likely reboot their intermediate keychains so there's only a handful of 'revocation' certificates that will actually be needed due to the tree-of-trust model: Anything in the chain gets revoked everything below it goes away.
And yes, this means the folks that were Johnny on the Spot about reissuing their certs might have to re-issue them AGAIN due to fixing their issue so quickly, but that's honestly pretty minor compared to the huge swaths of forever-vulnerable sites that need to effectively have their SSL status revoked regardless of what they do or don't do.
WolfWings, who hasn't logged into SlashDot in YEARS.
Re: (Score:2)
Just like Apple stopped using certs signed by the compromised Comodo Root certificate to sign patches?
Oh wait.. they they kept using it for years. They might still be using it, even.
Certs are window dressing. Companies only care enough about them to make sure they don't throw warnings. If they can get away with it, they will invariably "solve" the issue by telling the users to reduce security settings.
Re: (Score:2, Interesting)
What do you mean, punish? Free certificates for all. The other AC is spot on. This is a make or break moment for the CAs. Unless they ensure that all vulnerable keys can no longer be used, the CA model is terminally damaged. The only way to make sure that all clients reject all vulnerable certificates is to change the root certificates and issue new certificates to everybody. If neither the CA nor the browser makers take this admittedly drastic step, I predict extensions soonish which will reject certificat
Re: (Score:2, Insightful)
It's only free if admin's time is free and CA's time is free. Issuing certificates is not something all CAs can simply do one-sidedly and automatically. I take it you never had to manage certificates, did you?
Only a week passed and already most Internet users won't see a site that didn't take care of that. The wave of reissuing and revoking is still growing, so most of vulnerable certificates will disappear pretty soon.
Meanwhile, you're talking about wasting billions on the off chance a site with a hundred
Re: (Score:2)
CAs dont control whether a cert can still be used. The client configuration does that.
Re:https is dead (Score:4, Interesting)
The problem with replacing HTTPS is that you will need to maintain regular HTTPS for all those clients that cant upgrade to a newer browser. (which exposes web sites to these threats) And you have to convince browser and web server vendors to support the new HTTPS replacement.
Google would probably do it (on desktop, ChromeOS, Android and its custom web/SSL server software) especially if it made it harder for the kind of man-in-the-middle-using-fake-certificates type attacks the NSA have been using (the ones that let the NSA serve up fake copies of popular web sites as a vector to infect other machines). Opera and others that use the Google rendering engine would probably use the Google support.
Mozilla would probably do it if you could convince them that its not just going to be bloat that never gets used.
Apache would probably support it via a mod_blah and if they dont, someone else would probably write one.
Other FOSS browsers and servers (those that do HTTPS) would probably support it if someone wrote good patches.
But good luck convincing commercial vendors like Microsoft and Apple to support a new protocol. And the Certificate Authorities would fight hard against anything that made them obsolete (which any new protocol really needs to do)
Re: (Score:2)
How safe are Perfect Forward Security (PFS) and other "per-session" encryption keys from this mess? Thanks
Re: (Score:2)
If the server (or client, for that matter) was hit with Heartbleed *during* (or shortly after) the session, the symmetric encryption key may have been retrieved and an attacker who had recorded the whole session could then decrypt it. If the session was ongoing and they were in position to do so, they could MitM it.
Similarly, if the attacker used Heartbleed during the key exchange, they might have leaked the private information (from either endpoint) needed to derive the symmetric key, even if for some reas
Re: (Score:2, Insightful)
Time for SHTTP. The useless certificate authorities can go and die in a dark hole. Your bank can send you their public key. For most places you wouldn't even need a password.
OpenSSH is developed by competent people and it has virtually no preauthentication attack surface.
Re: (Score:3)
Your bank can send you their public key.
That is the key problem with schemes that don't involve a CA. A bank will be sending me bits of paper anyway when I open a new account, the better ones will be sending me a fob for two-factor auth too in fact, so sending an extra bit of paper with "this is the fingerprint of our signing key, when your browser asks you to confirm a certificate make sure the signer finger-print matches this one" is no hardship. But what about sites that don't have any other comms channel with their users? How do they prove th
Re: (Score:3)
> But what about sites that don't have any other comms channel with their users?
They never have been secure and they will never be, because an early enough MITM attack renders checksums, certificates, and certificate authorities potentially irrelevant. You got your certificates from the internet or from a preinstalled OS which has likely been vetted by some agency. Your packets travel along thanks to routers with closed source OS. Your cellphone is designed as to permit the modem to do what heartbleed di
Re: (Score:2)
How do you know its your bank's public key and not someone elses?
Thats the ENTIRE problem that CAs attempt to solve.
Re: (Score:2)
It'll never happen. Look at how hard it was to finally kill IE6. Then add all those embedded web servers in APs, switches, routers, NAS, etc etc and imagine getting their firmware updated (not to mention the devices that are no longer updated by the manufacturer).
Oh, man, what a mess (Score:4, Interesting)
I do have to wonder if the task was made easier given the purpose of the server. After all, I'd think it wouldn't get traffic at all except for those people responding to the challenge. But, still, this proved it's possible.
So not only do those of us responsible for web servers need to generate new server certs for all of our servers... pretty much every current web server cert in existence also needs to be revoked. Are the CAs even willing/able to do something on that scale in a short amount of time?
Re:Oh, man, what a mess (Score:5, Interesting)
From the linked site: "He sent at least 2.5 million requests over the course of the day." So, no rate limiters, anti-DDS protection, or other active countermeasures in operation. Reasonable for this challenge but not overly realistic.
sPh
Re: (Score:3)
Re:Oh, man, what a mess (Score:5, Insightful)
So not only do those of us responsible for web servers need to generate new server certs for all of our servers... pretty much every current web server cert in existence also needs to be revoked. Are the CAs even willing/able to do something on that scale in a short amount of time?
Netcraft actually has an interesting article [netcraft.com] about that very situation.
Obviously, the CAs don't really have a choice in the matter, but I can't imagine they really have capacity issues in regards to the actual revoking/signing as that's all automated. If things get crazy busy, they can always queue things -- for most admins it doesn't really matter if the new cert is issued immediately or after 15 minutes.
Human-verified certs like org-verified and EV certs might have a bit of delays, but domain-validated certs should be quick to reissue.
Of course, revocation checking for browsers is really bad [netcraft.com]. Ideally, all browsers would handle revocation checking in real-time using OCSP and all servers would have OCSP stapling [wikipedia.org] enabled (this way the number of OCSP checks scales as the number of certs issued, not the number of end-users). Stapling would help reduce load on CA OCSP servers and enable certs to be verified even if one is using a network that blocks OCSP queries (e.g. you connect to a WiFi hotspot with an HTTPS-enabled captive portal that blocks internet traffic until you authenticate; without stapling there'd be no way to check the revocation status of the portal).
Also, browsers should treat an OCSP failure as a show-stopper (though with the option for advanced users to continue anyway, similar to what happens with self-signed certificates).
Sadly, that's basically the opposite of how things work now. Hopefully things will change in response to Heartbleed.
Re: (Score:2, Informative)
That's not how certificate signing requests work. The private key isn't handed over to the CA.
Re:Oh, man, what a mess (Score:5, Informative)
pretty much every current web server cert in existence also needs to be revoked. Are the CAs even willing/able to do something on that scale in a short amount of time?
Calm down. A majority of web servers are not vulnerable and never were. All in all... less than 30% of SSL sites need to revoke any keys.
Some websites are running with SSL crypto operations performed by a FIPS140-2 hardware security module; these are not vulnerable, since OpenSSL doesn't have access to the private key stored in the server's hardware crypto token.
Many web sites are running on Windows IIS. None of these servers are vulnerable.
Plenty of web sites are running under Apache with mod_nss, instead of mod_ssl. None of the websites using the LibNSS implementation of SSL are vulnerable.
Many web sites are running on CentOS5 servers with Redhat's openssl 0.9.x packages. None of these servers were ever vulnerable.
Many web sites are running on CentOS6 servers, that had not updated OpenSSL above 1.0.0. These websites weren't vulnerable.
Many websites are running behind a SSL offload load-balancer; instead of using OpenSSL. Many of these sites were not vulnerable.
Re: (Score:3)
All websites running under any publicly released version of SUSE Linux Enterprise Server using the distribution's openSSL package were not vulnerable to HeartBleed.
Re: (Score:2, Informative)
I believe the key point you made there is that anyone running IIS was never vulnerable except for all the times they were [google.com]
Here, FTFY.
PS: Mister Ballmer, we know you've got plenty of time on your hands now, but be subtler, please.
Re: (Score:3)
You are correct about there being other IIS security vulnerabilities. There have also been other OpenSSL, Apache, and Nginx remote code execution vulnerabilities.
The Nginx RCE could also be used to compromise key storage.... could do even better than that, could load an eavesdropping trojan into memory.
The past IIS vulns did not necessarily easily compromise key storage.
The Heartbleed bug is MUCH easier to exploit than any RCE bug, even though the RCE bugs are more useful for an attacker, if a ser
Re: (Score:3, Informative)
"secure commercial product"
I assume you implying that closed source is more secure.
Doe you really believe that? Why?
- Do you think security by obscurity is real security?
- Do you believe that closed source has more code audits?
- Do you believe that there is less change of NSA or other back doors in closed source software.
"IIS was never vulnerable..."
Really? Try a search for "IIS SSL vulnerability".
Re: (Score:2)
I think the technical term for his post is "troll". That is, you've been trolled.
Re: (Score:3)
Re: (Score:2)
They did not however, change any of their intermediate trust chain certs. I don't see Commodo really did anything except issue certs as requested, like always.
Re: (Score:2)
On the contrary, it may have made things harder.
Reading the private key relies on forcing malloc() to reuse some small block from the free block list with a lower address than the block containing the key, insteading of simply carving a new block out of free memory (with an address higher than the key).
That may be easi
I can't use cloudflare, connection is insecure (Score:1)
Interestingly enough, my browser (firefox) doesn't let me access https://www.cloudflarechallenge.com/ [cloudflarechallenge.com], complaining about the security certificate...?
Re: (Score:2, Informative)
Be glad...
I can see t with my browser, and this is, what I can read (among other things)
:
"Can you see this site? You shouldn't be able to, we have revoked the certificate. If you can still see this message, Certificate Revocation may be broken in your browser. See this post for more details."
Re:I can't use cloudflare, connection is insecure (Score:5, Informative)
Chrome turns the "check for revocation" option off by default, it seems.
Re: (Score:2)
You're right! But why!?!?
Why would it turn off checking revocation by default! Is there any possible reason that this is anything but grossly irresponsible?
Re: (Score:2)
Because it can massively slow down access to SSL sites.
Re: (Score:2)
I think my preference would be to always attempt the check and in the case of a soft-fail to indicate that there was a soft-fail so the user can still make an informed decision. Or at least a semi-informed one.
Re:I can't use cloudflare, connection is insecure (Score:5, Funny)
Internet Explorer for the win (my head asploded):
There is a problem with this websiteâ(TM)s security certificate.
This organization's certificate has been revoked.
Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server.
We recommend that you close this webpage and do not continue to this website.
Click here to close this webpage.
I feel like I've fallen into Bizarro world, where IE is the safe browser and IIS the safe server. Maybe I should grow a goatee?
Re: (Score:2)
Firefox noticed for me (Score:3)
Running Firefox 28 on Win7, it said the cert was revoked.
Re: (Score:3)
Same here, but using Firefox 28 on OSX, error message "Peer's Certificate has been revoked. (Error code: sec_error_revoked_certificate)".
Re: (Score:2)
In case no one noticed, MS view on security has changed a LOT since Windows 95 and IE 6.
Re: (Score:3)
On iOS I get no such warning...
And actually, the default OS X settings don't check revocation lists either. To enable that you need to open up "Keychain Access", go to "Preferences -> Certificates", and set both OCSP and CRL to "Best Attempt".
Re: (Score:2)
Not sure about iOS, but the last time I set CRL on OS X to "require" I couldn't install patches.
Re: (Score:2)
Hmm... I have a fully updated 10.6.8 (Snow Leopard) box that's been my media server for a number of years - it doesn't get used for anything else, even web browsing (it's an old MacBook Pro with a non-functional screen). Just now I connected to it using screen sharing, opened up Safari and went to the CloudFlare Challenge website. It loaded just fine, with no warnings whatsoever.
I put Firefox on it and went to the same URL - Firefox tells me the certificate has been revoked.
Re: (Score:2)
Re: (Score:2, Informative)
Chrome has online revocation check turned off by default - you can go to Settings -> Advanced and switch on "Check for server certificate revocation" under HTTPS/SSL section
Re: (Score:2, Insightful)
I'd guess "because online checking can be slow - as in literally _seconds_ before site starts loading!!11!" and "there's offline revocation list and Chrome updates often enough".
Or may be "because NSAMI6KGB paid us to weaken the security".
Re: (Score:2)
The internet is closed for renovations? (Score:1)
Until they revoke all potentially compromised CA's and roll out a brand new set I don't see how they can consider the breach closed even if the vuln itself is fixed.
Re: (Score:2)
Luckily the system is designed to be able to do that.
(And many sites have already done so).
Don't keep vulnerable servers running! (Score:2, Insightful)
Most sites don't have PFS enabled, and that means anyone who has recorded a site's traffic prior to the publication of the bug only needs a short time to get the key and can then decrypt all recorded sessions. The Heartbleed exploit doesn't just jeopardize the data that is currently flowing through OpenSSL while the attacker is reading server memory through malicious heartbeat requests. If you used a vulnerable server via a public Wifi hotspot in the past two years and someone else recorded your session, th
Re: (Score:3)
When I looked into my server, I found out:
The OpenSSL library I'm using wasn't vulnerable.
Thus, my keys are as "safe" as they were before.
Also, to enable PFS, I would have to upgrade - to one of those OpenSSL versions that is vulnerable (but obviously there are "fixed" ones now).
I would also only be able to use EC cryptography with PFS with OpenSSL. I don't trust EC personally, yet. It's just not been around long enough for me. And I find it suspicious that every time something happens, the answer is "Le
Re: (Score:2)
https://www.openssl.org/docs/a... [openssl.org] suggests that OpenSSL (the official upstream version at least) does in fact support DHE and PFS without EC.
Re: (Score:2)
I would also only be able to use EC cryptography with PFS with OpenSSL. I don't trust EC personally, yet. It's just not been around long enough for me.
The promise of PFS is that a private key compromised or lost after the fact does not compromise the contents of all sessions. Which means it's useless for an attacker to intercept thousands of SSH sessions, and then later make an attempt to break into the server --- they need private key at the time of any attack.
You're argument is the equivalent of say
There are people that tust SSL-certificates??? (Score:3)
Seriously, how out-of-touch can you get? That the X.509 global certificate system has been fundamentally compromised has been well-known for quire a few years to everybody that follows the news at least in a cursory fashion.
Re:There are people that tust SSL-certificates??? (Score:4, Informative)
There's a pretty big difference between 'because the system is pretty stupid, you can generate a valid certificate for any domain by knocking over any one of an alarming number of shoddy and/or institutionally captured CAs' and 'your private key, yours specifically, can be remotely slurped out of your system and used to impersonate it exactly'.
Re:There are people that tust SSL-certificates??? (Score:4, Insightful)
I am not sure it is a bigger issue, since many of these sites will not be publicly reachable. But it definitely is an issue foe example for large corporations that use SSL in their Intranet with self-signed certificates. They now have to wonder whether some of their staff has attacked their servers this way.
Re: (Score:2)
I was thinking 'bigger' in that only SSLed stuff accessed by excessively-trusting systems can be compromised by a rogue
Oh please... (Score:1)
Like this would come as a surprise?
Like heartbleed in itself is a surprise? For every major zero day like this out from the dark there is ten more in the forest.
General people just have no clue. Most organizations have no clue. Media have no clue. Just people in the dark know.
Anyone working in the industry would know better than to trust anything online or supposedly safe.
Secret stuff fares far better offline or in general "snail-mail", than online.
No software is safe, ever has been or ever will be.
The chai
And the cry goes up from ten thousand admins, (Score:5, Funny)
Fuck.
(Except here in the UK, we are more creative with our profanity.)
Re:And the cry goes up from ten thousand admins, (Score:4, Funny)
Re:And the cry goes up from ten thousand admins, (Score:4, Funny)
Bollocks!
Re:And the cry goes up from ten thousand admins, (Score:5, Funny)
Re: (Score:3)
Perkele!
Re: (Score:2)
As an atypically profane Brit, there's much to love even about the simple* word "fuck".
"You know, Minister, I believe that in the long view of history, the British Empire will be remembered only for two things... The game of soccer. And the expression 'fuck off'."
- The last Governor of South Yemen, in conversation with then-Defence Minister Denis Healey on the eve of South Yemen's independence.
Personally, members of my team are fond of variations along the lines of "Fuck, the fucking fucker's fucked!" since
Re: (Score:2)
All good suggestions, but none of them quite how I'd imagined it:
Bloody 'Ell! How'd he go and miss an unchecked length field? Now I'm in all weekend workin' me bollocks off updating every server 'cos some fuckin' wanker couldn't be arsed to get his security-critical code reviewed.
Obvious hack is obvious? (Score:2)
Tools for checking (Score:4, Informative)
There are a couple tools available at:
https://github.com/Lekensteyn/... [github.com]
It's python based so YMMV
They will tell you if you are vulnerable (See the README.md file)
Re: (Score:2)
The cool feature of Pacemaker is that it checks TLS *clients*, actually. There are other tools for server checks (one of which is included with Pacemaker) but it's actually very important to make sure any clients you have are invulnerable to Heartbleed as well. Software that ships with bundled or integrated OpenSSL libraries - and I've seen quite a few - could be vulnerable to this.
There is more where that came from (Score:5, Interesting)
Coverity is a static analysis tool. It was tested on the source code with the Heartbleed vulnerability and did not find it. The developers of Coverity made a proof-of-concept modification to treat variables as tainted if they're subjected to endianess conversion, based on the assumption that such variables contain external and thus potentially hostile data. With this modification, Coverity finds the Heartbleed bug, as described in this blog post [regehr.org]. Note the comment below the screenshot: "As you might guess, additional locations in OpenSSL are also flagged by this analysis, but it isn’t my place to share those here." This may just be a consequence of not detecting all ways in which a tainted variable is sanitized, or it may point to more problems.
Re: (Score:2)
Re:There is more where that came from (Score:5, Interesting)
A simple question - Can you provide simple answer? (Score:2)
Re: (Score:2)
How do I become a trusted root certificate authority ?
You ask the browser vendors, who respond by asking some very pointed questions about how trusted you are. These sorts of questions include "do you have regular audits to ensure that you're managing your keys correctly?" and "what policies do you have in place for dealing with a security breach that compromises one of the keys you've signed?" Convince enough people that you're really trustworthy, and congratulations, you're a root CA. At least until the next time they ask those questions. It's only really re
Re:The CA should not revoke the certificates, (Score:5, Insightful)
the user of the keys should do this. Would you want to pay for new certs even if you were not affected by heartbleed?
It's within the CA's right, however, to scan the URLS certified by each certificate, test for Heartbleed vulnerability --- and automatically revoke, if they determine that the site is vulnerable.
Re:The CA should not revoke the certificates, (Score:5, Insightful)
Which only tells us they're patched now, it doesn't tell them how much time the site was vulnerable.
Re:The CA should not revoke the certificates, (Score:4)
Which only tells us they're patched now, it doesn't tell them how much time the site was vulnerable.
There is probably still a great deal of unpatched openSSL deployments out there.. and it'll probably be a while before they're all patched (if ever)...
Re:The CA should not revoke the certificates, (Score:4, Interesting)
There is probably still a great deal of unpatched openSSL deployments out there..
I think you miss the GP point. I believe the GP is saying that the site could have been exploited for a while and the damage has already been done. The check just tell us that the site has been patched but NOT tell us how much the damage is done to users. As a result, some users do not know that their username/password have already been stolen by the exploitation (which is not caused by the user). I doubt that there is a gray area allowed in security. Once the security is breached, there is no guarantee to say that everything is now fine after the fixed/patched.
Re: (Score:2)
I think there is enough low hanging fruit that dealing with people who did patch and rekey their certificates immediately is overkill... Or at least less critical than dealing with those still exposed.
Re:The CA should not revoke the certificates, (Score:4, Interesting)
OK, then they should invalidate ALL certificates, test customers for the patch, give patched customers new certs, and refuse to give new certs to unpatched customers. It's their business to maintain a 'web of trust'.
Re: (Score:2)
Which only tells us they're patched now, it doesn't tell them how much time the site was vulnerable.
If they're patched now but were vulnerable 1 month ago; there is a pretty good chance >90% that the keys have not been stolen.
Re: (Score:3)
Which only tells us they're patched now, it doesn't tell them how much time the site was vulnerable.
That's true, BUT for the ones that are patched now --- the admin probably understands the issue. The sites with negligent, clueless, or sloppy admins, will be unpatched sites mostly (or sites running earlier releases before the vulnerable version).
Re:The CA should not revoke the certificates, (Score:5, Funny)
Pff now you're telling me the CA has the authority to tell me which certificates are bad??
Oh piss on that!
Re:The CA should not revoke the certificates, (Score:5, Insightful)
Yes... That's the entire point of a CA, to certify that a person really is that person. If the certificate is bad, they can no longer make that certification, so it really really really is their job to do that. It is in fact their only job.
Re: (Score:2)
I choose to read the AC as making a joke.
Re: (Score:3)
However, the CA should issue the new cert for free in this case. It costs a CA exactly nothing to issue a new cert. Its not a consumable commodity. Allowing them to indiscriminately cancel certs without proof of compromise gives them access to every site's checkbook.
With no PROOF of being hacked, even the the fact that at some point in time the site was running a vulnerable openssl version seems insufficient proof to cancel a certificate, and require payment for a new one. Remember, none of this can be t
Re:The CA should not revoke the certificates, (Score:5, Funny)
Pff now you're telling me the CA has the authority to tell me which certificates are bad??
If that is an issue, there is nothing stopping you, or anyone, from becoming their own Certifcate Authority. I've done this for my own sites, since I am at least 97% sure I am who I claim to be.
Re: (Score:3)
And you are in good company. Google, Apple, and Microsoft do the same.
Chances are your users are just a certain of who you are as Google users are certain of who Google is.
Re:The CA should not revoke the certificates, (Score:5, Informative)
It doesn't matter who revokes the keys. Right now only Firefox and Chrome ever check for revoked certs, and Chrome at least has this disabled by default. If you are running iOS or Android, your browser doesn't check the CRL before trusting the cert. So it's great if web sites revoke certs, but it doesn't actually change anything on the end user side, for the most part. I'm not saying anything about Windows platforms because I don't have access to any; it's possible that they do support CRLs. You can check whether your browser supports CRLs by going to this test URL [grc.com]. If you don't get a warning from your browser, your browser isn't checking CRLs.
Re:The CA should not revoke the certificates, (Score:5, Informative)
IE 11 (at least) works properly, right out of the box:
There is a problem with this website’s security certificate.
This organization's certificate has been revoked.
Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server.
We recommend that you close this webpage and do not continue to this website.
Click here to close this webpage.
Re: (Score:2)
So does IE10.
Internet Options -> Advanced -> Security (scroll near bottom) -> "Check for publisher's certificate revocation" and "Check for server's certificate revocation" are both checked for me. I know at least one of those options dates back to IE6, in fact, although it may have been inactive by default back then. I don't know when those options were made default, but at a guess I'd say IE8 or IE9.
As a side note, if you are running Vista or later but *not* on IE11, you have TLS 1.1 and 1.2 disa
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)