Well but make sure you throw out the machine's power cord before throwing in that towel! This gives you some chances (although this attack decreases them significantly).
Alpha particles cause errors in memory chips - see jargon file:
Intel could not explain random bit drops in their early chips, and one hypothesis was cosmic rays. So they created the World's Largest Lead Safe, using 25 tons of the stuff, and used two identical boards for testing. One was placed in the safe, one outside. The hypothesis was that if cosmic rays were causing the bit drops, they should see a statistically significant difference between the error rates on the two boards. They did not observe such a difference. Further investigation demonstrated conclusively that the bit drops were due to alpha particle emissions from thorium (and to a much lesser degree uranium) in the encapsulation material. Since it is impossible to eliminate these radioactives (they are uniformly distributed through the earth's crust, with the statistically insignificant exception of uranium lodes) it became obvious that one has to design memories to withstand these hits.
Obviously, modern memory chips are designed to be properly shielded from those, otherwise as memory densities increase, memory errors caused by that radiation would render them useless.
That said, I still don't think this attack is so important. If you have the file system mounted, and an attacker gains access to your computer, the files are already there!
This attack is important because until now it has been perceived, that if in a last effort you pull the plug out of your box and render it powerless, your encrypted filesystems will be safe.
The common opinion was that when the DRAM modules get their power cut off and their refreshing stops, all contents are almost immediately lost, at most in a matter of seconds. Now it turns out that not, it's actually a matter of minutes, enough to make this kind of attack practical.
This attack emphasizes the importance of keeping your keys in memory only when they are actually needed and the data is accessed, and properly overwriting the memory when the keys are released.
Does anybody know whether all current cryptographic implementation properly overwrite memory regions that contained keys when the keys are no longer needed?
I wonder if LUKS (Linux Unified Key Setup) does that properly when you do a "cryptsetup luksClose"?
Once the encrypted filesystem is unmounted and the encrypted device removed, and the encryption key properly overwritten in memory, I figure at that moment you are safe from that attack?
Citing your own self, the previous post and this one:
... any cert can be compromised within seconds after it is issued...
...All of these presume an untruth; that the cert itself must be compromised...
You're directly contradicting yourself.
Then you go on about attacking other things, not the certificate itself:
If I get into your root (by any means -- remote or local)
I presume that you mean gaining root on my server that has the server certificate issued by an authority installed (in this particular problem area there are multiple concepts under the name of "root", so "getting into root" may mean multiple things: there's the root of DNS system; the root of certification hierarchy, the root user on the server machine and on the client machine and so on).
Well, if you could do that, sure, you'd basically could do anything with the site, deface it and so on, you'd be able to do many very bad things without even touching the certificate. All this is patently obvious. How is this in any way relevant in a discussion about CA authorities?
If you imply that you can take control of any server on the planet or even most of them, then I think we'd have a much larger problem than that with CAs. However, I think you'd still have a hard time with my servers, as I keep all of them up to date and use SELinux in enforcing mode on all Internet-exposed hosts. Try breaking that. As to physical security, this can be more of a problem, but the building is more or less guarded and under constant surveillance.
I can also replace the browser; either eliminating its tests, or modifying them.
Can you really do that so easily for an arbitrary person? Even one who browses the web using lynx-SSL from an OpenBSD box without X11?
It's true that if a user is an easy target you can do all sorts of bad things to him. Still, I fail to see any relevance in a discussion about CA authorities. You said that any cert can be compromised within seconds - obviously at that moment you completely didn't understand how public key infrastructure works, or public key cryptography, or the SSL protocol for that matter. I hope that now you've read relevant articles on Wikipedia and are a bit more informed.
The bottom line is that these certificates cannot provide the kind of security they want you to think they do
Well being a professional I understand fairly well what problems is the PKI aimed at and that it doesn't solve all security problems of all systems. I think nobody in the field worth his salt thinks that certificates magically make everything involved secure against all possible threats. That would be unrealistic even for a layperson.
On the other hand, when you know exactly what certification accomplishes and what are its uses and limitations, it becomes a powerful tool in your security toolbox.
the question is now, what *do* they guarantee? And the answer is exactly what I said above: They guarantee that the conversation between the two ends of the connection is encrypted. Not that the encryption is secure; not that the other end is who you think it is;
You still don't understand the basics of how PKI works. Go read on the subject instead of spreading bullshit on Internet forums, making an idiot out of yourself. What you just have written is exactly the opposite of truth. The very purpose of certificates is to guarantee that the other end is who you think it is. This is exactly the problem for which they were designed. Encryption is another thing, closely related, but it's not the purpose of having a certificate. Go educate yourself finally!
And even *that* is subject to a browser hack that puts up a lock and modifies the URL to read https to the in
I think that the new system would need to significantly simplify the reissuance procedure.
With X.509, when you want to prolong a certificate, it's a standard procedure - the CA simply lays a new digital signature on the same data (even certificate serial number) as before, only with new begin/end dates.
If I understand OpenPGP correctly, after changing the expiration date, you'd have to collect all the signatures from all the parties that signed our key again as the old signatures would be no longer invalid. Am I missing something?
Yes, the difference is mainly in the number of parties that need to give their signatures in order to authorize the change. With a web of trust this operation seem significantly more costly (and in general, all that relates to managing a certificate lifecycle).
BTW you might get an impression that I don't like the web of trust idea. In fact it's the opposite, I'd really like to see a replacement for the hierarchical PKI we have in place now because it's too centralized and inflexible. I just wonder how to design a system that doesn't introduce its own new problems while fixing old ones.
I'm a GPG user myself and I'm quite disappointed and frustrated that it didn't catch on on a larger scale. I think the complexity and laboriousness of properly managing keys and trust are mostly to blame. This would need to be solved properly for the new system.
Well false positives could be minimized by applying some sort of "tenure score" to all GMail accounts - the older an account and the more legitimate mail it has emitted, the more trustworthy it is and this contributes to a "whitelist" score on the filters (both outgoing and internal GMail -> GMail).
Recently created "throw-away" accounts would start with a low score and their outgoing mail would be much more likely to trigger blocking, provided that it also scores on some spam characteristics. I think that legal initial activity on webmail accounts can be identified and contribute to whitelisting too - after all, users often send "test" messages to their other accounts or their friends after they open a new account. While the spammers go right to mass sending.
Which gives me another idea. I understand that the spammers make a large number of new accounts and not necessarily send large amounts of messages from a single one. However, they probably send massive amounts of nearly identical messages from different throw away accounts. I think that GMail could try to correlate this data (e.g. using some message fingerprinting tehchniques similar to Pyzor/Vipul's Razor) and identify not single accounts that send out spam, but entire spam account clusters operated by single spammers at once!
Heck, this could be improved even further by buffering suspect outgoing messages and delaying sending them to external systems a couple of seconds (e.g. half a minute) in order to try to detect whether they are more of them coming from other accounts as a part of larger campaign. The system could hash, group, count and sum their amounts to decide whether this is actually a spam mass mailing. It would then bounce them, then start refusing to accept everything that looks the same, right at the sender (in the initial SMTP session from the MUA or in the web UI). This way some spam would not only be identified, but successfully learnt automatically by the whole system, and rejected from now on.
Of course, not working at Google, I can only speculate, they probably are doing all this, yet still it's not enough.
Well, they could try cooperating with some spam-fighting and anti-phishing communities (like the underfunded, yet still effective "pain in the phishers' ass" CastleCops). Actually, I've suggested this to a colleague who works at Google and he suggested that to someone else, but it seems the idea didn't catch on then. Maybe Google should realize by now that even they cannot beat the spam problem all by themselves?
There are lots of ideas I think that would make GMail's spam filters much more effective. After all, being such an integrated service and having such an efficient infrastructure, they have lots of useful data and mechanisms at their disposal.
BTW, the MIT PGP Public Key Server's FAQ is a nice list illustrating the most serious shortcomings of the OpenPGP PKI infrastructure based on PGP keyservers. Revocation can become quite a problem if it's the responsibility of a key holder himself and there's no central authority.
Why, by revoking it of course, and uploading it to the key servers. Possibly by using a paper printout of my pre-generated revocation certificate. It's my understanding that the technical aspects of this are solved; are you telling me it isn't true?
The technical aspects are theoretically solved. The OpenPGP/GPG infrastructure, based on keyservers and various client applications, hasn't been put to an extensive test involving financially sensitive use scenarios.
There are some obvious problems with the current state of this infrastructure. Fore example, most clients I saw don't regularly pull the key data from the keyservers to check for revocations and changes in trust. The user has to do this by hand. Realistically speaking, how many users understand that need and do that regularly before checking someone's signature on something?
Who is responsible for making sure this information gets propagated to all interested parties? Keyservers? The notarius? You yourself (contacting all your fiends, your bank(s), the government etc to tell them to disregard that key)?
Me of course, via the keyservers. I suppose it would be nice if I could ask the government to do it for me, in case I died or lost my mind, but that's optional.
By looking at how the current keyservers replicate, I can say that the current infrastructure would need lots of improvements. The keyservers don't replicate fast enough. With the current schedule, some changes in keys require days before they reach all the keyservers involved.
By that time a phisher with a stolen key could do gobs of easy cash and get away.
And apart from that, as I've already mentioned, current client applications don't make enough use of the keyservers, they don't refresh the keys automatically and the users may very well end up trusting compromised keys for months.
It's all because there wasn't significant need for fortifying this infrastructure against attacks, because there were no significant attacks, and that's because the OpenPGP infrastructure isn't used currently in scenarios that would motivate those attacks financially. OpenPGP isn't used for protecting financial operations now as far as I know, not on a wide scale anyway.
When/if it began to be used in this context, it would require significant upgrades - both to the infrastructure and to the client base (software-wise). And you'd probably end up with an infrastructure that needs more or less the same amount of money and resources that the X.509 infrastructure that's the subject of this discussion. So you'd end up in the same situation, and have wasted lots of time and effort to basically reinvent the same thing you were trying to replace.
The problem with PKI is that it requires a complex infrastructure in order to really be resilient against all possible ways in which things can go wrong.
You might know more about this than I do, but you don't indicate what. As far as I know, PKI is this infrastructure, and it exists today.
For an example of what, see the other comments in this thread: this one and this one and this one.
For the last two, you have to extrapolate and put those in a different context since they describe hypothetical attacks against current hierarchical infrastructure and its standards and implementations. It seems to me that some of those attacks would get easier with a web of trust infrastructure (but this of course depends on how well the web of trust get designed and implemented, which we yet have to see).
Really I'm talking about adopting the model, not necessarily the current software, from PGP's PKI trust network.
Yes, I think it would be wiser to adapt the X.509 infrastructure to this concept, since it's based on more extensible and general technologies. X.509 certificates are based on unambiguous and extensible ASN.1 notation so you can basically place any structured information that you like on them.
... Or it might treat a site getting a "untrustworthy" message as untrustworthy, while sending a confirmation request to whichever CA says so, and await an investigation or something, which might issue a retraction (or not).
The system that you describe sounds like it would be very expensive to maintain. Lots of parties have to expedite lots of effort to make this system work. It may be even more expensive than the plain X.509 system we have in place now. Fact, the costs are more equally distributed between all participants, instead of being concentrated in the CAs, so it might be apparently cheaper and thus more workable.
But the thing that looks unrealistic here is that you assume lots of parties are actively supporting the system, controlling it, greasing its gears; parties that need to be competent and resourceful. Where are you going to find them (apart from your ring of crypto PhD friends)? How much of the current population understands public key cryptography, goes to key signing parties and has a PGP/GPG key?
I don't see how your attack would succeed. Why would anyone trust someone they don't know they can trust? Whether they're desperate homeless people or just CS grad students with crushing gambling debts.
Well you may not be aware of that but one of your close but not so tech savvy friends may be much more trustful and easily fall for such a trick if it's done right. Thanks to the six degrees of separation effect you're quite close to various untrustworthy people. If your web of trust policy settings aren't tuned perfectly well you may unknowingly have some bad guys slip into the set of trusted ones simply by the means of less responsible actions of the others that you (have to) trust, who aren't as competent as you.
I think you have a significant misconception here.
Encryption without proper authentication of both parties (usually SSL cert to authenticate the server and login/password to authenticate the user) is worth almost nothing.
What good is your encryption if the users connecting to your service for the first time have no way to make sure that the site is not a scam? Their passwords may very well get harvested by a malicious third party. And what this encryption buys you then? Nothing.
Well, I've read some of your posts, and I can see that you aren't concerned with those attackers. Citing yourself:
"... non-profit groups, which will never have issues with domain typo scammers..."
"... applications that don't need this level of identity verification..."
"... academic and non-profit sites that need encryption..."
Let's connect the dots. You have a site that will never have issues with scammers (you say domain typo, but it seems you're completely unaware of the myriad of other attack scenarios that PKI successfully prevents), hosting application that doesn't require high level of server's identity verification (which is the purpose of the SSL server cert), but your clients somehow need encryption.
Tough noodles! You should realize that before FF3 you did it all wrong! Since the users saw a click-through warning, which they blissfully dismissed, the whole encryption you made was a waste of server's and clients' CPU cycles and wasting of electrical energy. Someone could direct them to a malicious proxy and they'd see an identical warning which they would happily click through and then use your site, but their login and password would already be in the wrong hands.
But if you're not concerned with such attackers, then simply turn encryption off! It's not good anyway, and it's a waste of time (your and your peers) and resources.
You're proposing an alternate low cost/low verification level CAs. To get around this problem. Are you fully aware that when you lower the financial and organizational barriers to obtaining a certificate, you open a large can of worms?
Suddenly not only non profit organizations, but all the cheap scammers can afford obtaining dozens of throw-away, fully valid certificates to perform their phishing scams. This time users won't see any warning, but a nice shiny lock icon in their browser that makes them feel safe and warm while they submit their financial details to a malicious site somewhere in Russia. Is this really what you want?
Realizing your proposal would really beat the purpose of this whole system - the public key infrastructure, the certificates and their chains, the encryption and SSL handshake, all this would cease to have any usefulness and would become dead weight.
True, there's one interesting potential solution that could be plugged into the existing infrastructure.
It's called a trust web and the likes of CAcert operate on a similar fashion. However, this idea has not been tested in a real world scenario where successfully attacking the system would promise significant financial gains (e.g. by masquerading as bank sites), unlike the X.509 system we have in place now.
It's uncertain whether a trust web would withstand concerted distributed attacks on its trust propagation from the criminal underground.
Yes, there were some high profile problems with the current X.509 infrastructure (like the Verisign-Microsoft Authenticode fiasco. But they were quickly plugged - look at the advisory I've linked to. This is where the cost of the certificate comes from. The issuers actually verify the identity of the requestor, and if they fail to do this from time to time, they still have backup systems in the form of fraud detection departments. That's why obtaining a certificate cannot be free and if it was free, that certificate wouldn't actually certify any useful information.
an attack on client's implementation of certificate handling (exploiting some potential yet unknown flaws in certificate handling routines of a popular browser so that a malicious certificate gets accepted as genuine)
a semantic attack on the user (e.g. a long URL that contains the name of hijacked site as initial part of HTTP Basic auth username, followed by lots of gibberish, and then the rest of actual URL that points to a malicious server with a cheap, yet valid throw away certificate for the malicious site's actual name)
These are probably the most likely to succeed - especially the second one since the human is usually the weakest link.
In a sane world, I would be able to simply walk over to my bank (or a notarius publicus or whatever), and have them sign my GnuPG key. That would be a start, at least.
Suppose you lose your private key to a malicious party. How are you going to organize its proper revocation? Who is responsible for making sure this information gets propagated to all interested parties? Keyservers? The notarius? You yourself (contacting all your fiends, your bank(s), the government etc to tell them to disregard that key)?
The problem with PKI is that it requires a complex infrastructure in order to really be resilient against all possible ways in which things can go wrong.
It was about $80.00, but that was for 10 years, not one.
Passports are for single persons, they don't fall under such strict renewal requirements as public websites that serve multiple people would do.
If you do malicious stuff with your passport, the damage is quite limited. But when you compromise a popular web server's private key... well, let's say the potential is obviously much higher (depends on the website of course).
the foremost aim of an SSL cert is to encrypt the communication so 3rd parties cant eavesdrop.
You got the concepts wrong.
The foremost aim of an SSL cert is to bind a public key to a common name which contains an identifying attribute, in this case a DNS domain name.
The public key can then be used to set up an encrypted channel between the client and the server by exchanging a one time session key (that's called an SSL handshake and I'm simplifying it a bit, since you seem to not even know what's the relation between encryption and a certificate).
The encrypted channel could theoretically be set up without any cert, just by means of exchange of public keys (actually, one public key from one side would suffice and the scenarios we're talking about are like this - no one uses client certificates on the public web; they are more common on corporate intranets with hardware tokens though).
However, using public keys without certificates would be susceptible to man in the middle attacks, since a malicious server (to which a client was redirected by DNS spoofing or traffic interception) could impose on the client that it is the real server and proxy all the requests from the client to the actual server, and record all data or modify it maliciously in real time.
This is where certificates kick in. If the SSL handshake is initiated between the unsuspecting client and the imposing malicious server, the malicious server has to feed its own public key to the client. This key cannot be bolted onto the real server's certificate, because this would violate CA's digital signature on that certificate and it wouldn't validate. So the best the malicious server is able to do is to provide its own certificate to the client. This certificate may be:
self-signed
signed by a cheapo obscure CA that signs certificate from anybody
In case 1, with Firefox was a warning popup they dismissed. With Firefox 3, they finally are properly warned that something is wrong in a way that they cannot mindlessly evade.
In case 2, well, that obscure CA's certificate shouldn't initially be in the trusted CA store the system or browser ships with, and users will get a warning - see case 1.
To sum up, I think that the change made in Firefox is actually an excellent move that has the chance to make the certificates actually worth paying for, which should bring more players to the certification market, stimulate competition and bring certification prices down. I just hope that Internet Explorer follows with similar improvements in the future.
the logic should be trying to prevent dns poisoning, or man in the middle via technical methods. not try to circumvent the issue by making some central authority(ies) decide whats genuine and what is not, and forcing all people to pay them for it.
So what technical solutions do you propose to the accountability and verifiability problem on the Internet? You don't seem to have provided any constructive alternative proposal, you just keep whining about big buck companies.
Intentions of the person/server you're communicating with is outside of the scope. No amount of money exchanging hands will change this fact, yet Verisign has obviously convinced a lot of people to the contrary.
Well it's said that the most accurate preserved records are tax records. Money exchanging hands is usually some indicator that a party puts some weight behind its efforts, and money trail is the hardest to falsify. This filters out cheap scum bags effectively.
There are lots of people who would sell the service of showing their ID to someone else for a crate of cheap wine.
I'm not saying that CAcert approach isn't viable, I'm saying that charging a credit card IMHO results in more accountability, since you need to ID yourself to get a credit card, and in addition you have to expedite some money to get that commercial cert.
When you've spent that money, you're less likely to use it for some illegal stuff that will get the paid certificate revoked and possibly involve yourself in some law enforcement problems should they trace the money trail back to you through the credit card company.
The problem with your argument is that you compare apples to oranges. The situations are different. With SSH, usually the initial connection to the machine (for the root user) is by the same person who is setting SSH up, so he/she may be quite confident that this initial connection it's intercepted. For the unprivileged logins, the users usually are involved with the sysadmin too (they get the password from him at that time, or a confirmation that he installed their public key in their.ssh). So it's usually safe to go "yes" on the initial connection and then the key gets cached.
On the web, OTOH, you connect to distant server, you usually have no way to verify that all is well and OK, you cannot get the admin tell you the server key's fingerprint, tail the logs and check that you log into the machine from the expected IP address and so on.
And one more thing about SSH. You say that this "trust first time" stuff that's in SSH is a good solution. But it's only good when you are competent and know what you are doing and you're careful enough. Otherwise, it only gives you false sense of security.
In our company, we do lots of security audits and I've seen misguided admins who use SSH like you describe. We have a wonderful trick that we show them. We ask them to log in to one of their servers (earlier, of course, we poison that switches ARP caches so that all the traffic passes through our laptop). They log in, then we tell them what their password is. When in horror they ask "HOW?", we calmly ask them whether they've seen the "server identity has changed" message and why did they continue connecting.
It's not as impressive if they use public key authentication instead of passwords, but it still works for intercepting the session and doing fancy stuff on their servers.
So if this scheme is unworkable for supposedly technically competent sysadmins, how on earth do you expect it to work for clueless web users (think Aunt Tillie)?
When issuing a certificate, Verisign supposedly (yes, I'm trying to be realistic) checks that the requesting organization is still in business, that it has rights to the domain name, that the request comes from someone who works for the organization, that the corporate contact is aware of the certificate request, that the technical contact is authorized to receive the certificate and they check the domain name for similarity (phishing-wise) to some established brands names.
I still highly doubt that with free or cheap certificates you would ever get that level of verifications. Much more likely the cheaper the certs, proportionally the more likely they would be to belong to malicious parties.
This idea is very interesting indeed. If I understand you correctly, you're proposing to move the web of trust PKI known from PGP/GPG to the arena currently occupied by X.509 and hierarchical PKI, right?
This could really lift the burden of managing the complexity of trust, life cycles, secure storage of central CA private keys from the CA. I can see that even Verisign has significant problems with that. Their certs don't seem to specify OCSP URLs yet, and they had some scaling problems with CRL distribution points. Distributing the PKI could solve lots of problems and the cost of maintaining that infrastructure would be more evenly distributed, too, which would lead to practically free certification (with some hidden costs, obviously, mostly in time and effort of participating parties).
There are potential problems here that I see, though.
Adapting the web of trust idea to the web for the HTTPS protocol would need preparing and constantly tweaking some variables. E.g. above what level of trust should Firefox's address bar turn yellow? How do you communicate the level of trust of the given site to the user so that he's likely to understand it correctly?
And how do you prevent coordinated abuse of that system? Note that the OpenPGP's web of trust has never been tested in the situation where successful attacks would be so highly rewarded as they currently are in the realm of HTTPS/X.509 (think phishers and other scammers).
For example, a network of criminals might recruit some number of homeless people from large cities around the world. These people have their IDs, and are willing to do anything for some money they need to spend on food/alcohol etc. It's quite common for those homeless with nothing to lose to get recruited, shaven, dressed and sent into bank offices to open small disposable credit accounts in their own names using their IDs, only to hand all the money they can get to their recruiters who give them some small percentage which they are going to quickly spend anyway. Then they run into trouble with law enforcement when it turns out they cannot pay, but hey, they didn't quite realize what was this all about, they weren't quite sober anyway.
Now the criminals might find it beneficial to recruit those people to go into key signing parties and obtain verified signatures on their keys/certificates practically for free (well, say one cheap wine per signed key). When they collect the necessary amount, they cross sign those keys to gain high enough level of trust and set up a large scale phishing site. They make gobs of quick cash before the web of trust reacts to the manipulation, which can require a significantly long time in a loose informal structure like this.
Would the idea that you propose be resilient against concerted efforts like this one?
It would be better if you just got a warning like "This site is probably not your bank"...
No, it would't. It would be much worse. Experience dictates that users, faced with vague, loosely defined indications such as "this might...", "this probably is/isn't" etc, simply lose any orientation about what to trust and what not to trust.
Then they simply start clicking OK/Yes/Add/Don't bug me anymore/ every time and this beats the purpose of the whole transmission encryption and authentication process. You could as well use plain HTTP.
The distinctions should be very clear, and the most clear variant has two options:
big green happy "all OK trusted verified and secured"
or big red "OMG run away from this site screaming!"
Only this leaves no room for doubt and incorrect interpretation.
Well, I was broadly generalizing because the issues of security and PKI are inherently complex and in order to convey what I've meant in a completely correct way, I'd have to allocate a whole day for writing my comment, and it would be longer than all other comments in this thread combined.
However, I'm well aware of all possible causes that a certificate may be revoked for. Still, all of them are because of some abnormal, unplanned circumstances. Let's take the example you've mentioned. Why would a certificate need to be reissued to use a new private/public key pair? In order to better define our hypothetical situation, let's say in the Netscape Cert Mgmt System nomenclature, that the original certificate was superseded (It's one of possible options when revoking a cert in NCMS).
This reissual needs to take place because the original certificate's private key has been destroyed/lost. It wasn't compromised to our knowledge (the "compromised" is another scenario that's clearly defined), but clearly something went wrong.
So this indicates that the holder of the certificate wasn't a serious, trustworthy party after all. Otherwise, he would plan accordingly and wouldn't let bad things to happen to his key, right? This applies even to seemingly innocent things, like moving to a new domain name and getting the old name's cert revoked. Trustworthy parties don't simply pull down old domains and web servers overnight. They keep them indefinitely for all the users that may have them bookmarked (at least until the certificates for the old domains expire peacefully).
So you see that even your argument confirms that high number of revocations usually correlates to low level of assurance. There's still something wrong going on, it's just that it may be wrong in a different way that most people will imagine/assume. The CA issues certificates to parties that shouldn't have those certificates issued to them.
How does this compare to other authorities like Verisign? How frequently does Verisign revoke a certificate? If it's not very often, should they be revoking more than they do?
Well, let's have a look.
Verisign has a much more complex pki hierarchy, so there are much more different CRLs. I've visited my local bank's site and had a look at their cert's chain. There were 3 levels of Verisign CAs above their x.509 cert and two of them had CRL distribution points specified (the top one, Verisign Class 3 Public Primary Certification Authority, had none, but I think it didn't need one since it's highly unlikely that the lower ones like Verisign's Class 3 Public Primary Certification Authority G5 will ever be compromised. They still have a 3rd level below and their 2nd level private keys are probably used only in high security, do-everything-manually-inside a-vault-by-a-highly-trusted-personnel-group context, not for signing any customer's certificate requests).
The fact is that any cert can be compromised within seconds after it is issued, and so can browsers, hosts lists, and a long list of other target; therefore, certs provide NO assurance you're connected to who the URL indicates you are. The idea that doubtful protection against "man in the middle" attacks are worth the cost of the CA infrastructure is ludicrous.
Would you care to somehow substantiate that claim? How are you going to compromise that cert? What do you mean by "compromise"? Without serious arguments and proofs you really sound like that crazy Time Cube guy.
Do you even have any understanding of how PKI works? Could you prove it by elaborating on it and presenting real attack scenarios? Because without that you just seem to be a troll.
Slashdot Mirror
Well but make sure you throw out the machine's power cord before throwing in that towel! This gives you some chances (although this attack decreases them significantly).
Alpha particles cause errors in memory chips - see jargon file:
Obviously, modern memory chips are designed to be properly shielded from those, otherwise as memory densities increase, memory errors caused by that radiation would render them useless.
See also: US patent 6531759 - Alpha particle shield for integrated circuit from IBM.
This attack is important because until now it has been perceived, that if in a last effort you pull the plug out of your box and render it powerless, your encrypted filesystems will be safe.
The common opinion was that when the DRAM modules get their power cut off and their refreshing stops, all contents are almost immediately lost, at most in a matter of seconds. Now it turns out that not, it's actually a matter of minutes, enough to make this kind of attack practical.
This attack emphasizes the importance of keeping your keys in memory only when they are actually needed and the data is accessed, and properly overwriting the memory when the keys are released.
Does anybody know whether all current cryptographic implementation properly overwrite memory regions that contained keys when the keys are no longer needed?
I wonder if LUKS (Linux Unified Key Setup) does that properly when you do a "cryptsetup luksClose"?
Once the encrypted filesystem is unmounted and the encrypted device removed, and the encryption key properly overwritten in memory, I figure at that moment you are safe from that attack?
Citing your own self, the previous post and this one:
You're directly contradicting yourself.
Then you go on about attacking other things, not the certificate itself:
I presume that you mean gaining root on my server that has the server certificate issued by an authority installed (in this particular problem area there are multiple concepts under the name of "root", so "getting into root" may mean multiple things: there's the root of DNS system; the root of certification hierarchy, the root user on the server machine and on the client machine and so on).
Well, if you could do that, sure, you'd basically could do anything with the site, deface it and so on, you'd be able to do many very bad things without even touching the certificate. All this is patently obvious. How is this in any way relevant in a discussion about CA authorities?
If you imply that you can take control of any server on the planet or even most of them, then I think we'd have a much larger problem than that with CAs. However, I think you'd still have a hard time with my servers, as I keep all of them up to date and use SELinux in enforcing mode on all Internet-exposed hosts. Try breaking that. As to physical security, this can be more of a problem, but the building is more or less guarded and under constant surveillance.
Can you really do that so easily for an arbitrary person? Even one who browses the web using lynx-SSL from an OpenBSD box without X11?
It's true that if a user is an easy target you can do all sorts of bad things to him. Still, I fail to see any relevance in a discussion about CA authorities. You said that any cert can be compromised within seconds - obviously at that moment you completely didn't understand how public key infrastructure works, or public key cryptography, or the SSL protocol for that matter. I hope that now you've read relevant articles on Wikipedia and are a bit more informed.
Well being a professional I understand fairly well what problems is the PKI aimed at and that it doesn't solve all security problems of all systems. I think nobody in the field worth his salt thinks that certificates magically make everything involved secure against all possible threats. That would be unrealistic even for a layperson.
On the other hand, when you know exactly what certification accomplishes and what are its uses and limitations, it becomes a powerful tool in your security toolbox.
You still don't understand the basics of how PKI works. Go read on the subject instead of spreading bullshit on Internet forums, making an idiot out of yourself. What you just have written is exactly the opposite of truth. The very purpose of certificates is to guarantee that the other end is who you think it is. This is exactly the problem for which they were designed. Encryption is another thing, closely related, but it's not the purpose of having a certificate. Go educate yourself finally!
I think that the new system would need to significantly simplify the reissuance procedure.
With X.509, when you want to prolong a certificate, it's a standard procedure - the CA simply lays a new digital signature on the same data (even certificate serial number) as before, only with new begin/end dates.
If I understand OpenPGP correctly, after changing the expiration date, you'd have to collect all the signatures from all the parties that signed our key again as the old signatures would be no longer invalid. Am I missing something?
Yes, the difference is mainly in the number of parties that need to give their signatures in order to authorize the change. With a web of trust this operation seem significantly more costly (and in general, all that relates to managing a certificate lifecycle).
BTW you might get an impression that I don't like the web of trust idea. In fact it's the opposite, I'd really like to see a replacement for the hierarchical PKI we have in place now because it's too centralized and inflexible. I just wonder how to design a system that doesn't introduce its own new problems while fixing old ones.
I'm a GPG user myself and I'm quite disappointed and frustrated that it didn't catch on on a larger scale. I think the complexity and laboriousness of properly managing keys and trust are mostly to blame. This would need to be solved properly for the new system.
Well false positives could be minimized by applying some sort of "tenure score" to all GMail accounts - the older an account and the more legitimate mail it has emitted, the more trustworthy it is and this contributes to a "whitelist" score on the filters (both outgoing and internal GMail -> GMail).
Recently created "throw-away" accounts would start with a low score and their outgoing mail would be much more likely to trigger blocking, provided that it also scores on some spam characteristics. I think that legal initial activity on webmail accounts can be identified and contribute to whitelisting too - after all, users often send "test" messages to their other accounts or their friends after they open a new account. While the spammers go right to mass sending.
Which gives me another idea. I understand that the spammers make a large number of new accounts and not necessarily send large amounts of messages from a single one. However, they probably send massive amounts of nearly identical messages from different throw away accounts. I think that GMail could try to correlate this data (e.g. using some message fingerprinting tehchniques similar to Pyzor/Vipul's Razor) and identify not single accounts that send out spam, but entire spam account clusters operated by single spammers at once!
Heck, this could be improved even further by buffering suspect outgoing messages and delaying sending them to external systems a couple of seconds (e.g. half a minute) in order to try to detect whether they are more of them coming from other accounts as a part of larger campaign. The system could hash, group, count and sum their amounts to decide whether this is actually a spam mass mailing. It would then bounce them, then start refusing to accept everything that looks the same, right at the sender (in the initial SMTP session from the MUA or in the web UI). This way some spam would not only be identified, but successfully learnt automatically by the whole system, and rejected from now on.
Of course, not working at Google, I can only speculate, they probably are doing all this, yet still it's not enough.
Well, they could try cooperating with some spam-fighting and anti-phishing communities (like the underfunded, yet still effective "pain in the phishers' ass" CastleCops). Actually, I've suggested this to a colleague who works at Google and he suggested that to someone else, but it seems the idea didn't catch on then. Maybe Google should realize by now that even they cannot beat the spam problem all by themselves?
There are lots of ideas I think that would make GMail's spam filters much more effective. After all, being such an integrated service and having such an efficient infrastructure, they have lots of useful data and mechanisms at their disposal.
BTW, the MIT PGP Public Key Server's FAQ is a nice list illustrating the most serious shortcomings of the OpenPGP PKI infrastructure based on PGP keyservers. Revocation can become quite a problem if it's the responsibility of a key holder himself and there's no central authority.
The technical aspects are theoretically solved. The OpenPGP/GPG infrastructure, based on keyservers and various client applications, hasn't been put to an extensive test involving financially sensitive use scenarios.
There are some obvious problems with the current state of this infrastructure. Fore example, most clients I saw don't regularly pull the key data from the keyservers to check for revocations and changes in trust. The user has to do this by hand. Realistically speaking, how many users understand that need and do that regularly before checking someone's signature on something?
By looking at how the current keyservers replicate, I can say that the current infrastructure would need lots of improvements. The keyservers don't replicate fast enough. With the current schedule, some changes in keys require days before they reach all the keyservers involved.
By that time a phisher with a stolen key could do gobs of easy cash and get away.
And apart from that, as I've already mentioned, current client applications don't make enough use of the keyservers, they don't refresh the keys automatically and the users may very well end up trusting compromised keys for months.
It's all because there wasn't significant need for fortifying this infrastructure against attacks, because there were no significant attacks, and that's because the OpenPGP infrastructure isn't used currently in scenarios that would motivate those attacks financially. OpenPGP isn't used for protecting financial operations now as far as I know, not on a wide scale anyway.
When/if it began to be used in this context, it would require significant upgrades - both to the infrastructure and to the client base (software-wise). And you'd probably end up with an infrastructure that needs more or less the same amount of money and resources that the X.509 infrastructure that's the subject of this discussion. So you'd end up in the same situation, and have wasted lots of time and effort to basically reinvent the same thing you were trying to replace.
For an example of what, see the other comments in this thread: this one and this one and this one. For the last two, you have to extrapolate and put those in a different context since they describe hypothetical attacks against current hierarchical infrastructure and its standards and implementations. It seems to me that some of those attacks would get easier with a web of trust infrastructure (but this of course depends on how well the web of trust get designed and implemented, which we yet have to see).
Yes, I think it would be wiser to adapt the X.509 infrastructure to this concept, since it's based on more extensible and general technologies. X.509 certificates are based on unambiguous and extensible ASN.1 notation so you can basically place any structured information that you like on them.
The system that you describe sounds like it would be very expensive to maintain. Lots of parties have to expedite lots of effort to make this system work. It may be even more expensive than the plain X.509 system we have in place now. Fact, the costs are more equally distributed between all participants, instead of being concentrated in the CAs, so it might be apparently cheaper and thus more workable.
But the thing that looks unrealistic here is that you assume lots of parties are actively supporting the system, controlling it, greasing its gears; parties that need to be competent and resourceful. Where are you going to find them (apart from your ring of crypto PhD friends)? How much of the current population understands public key cryptography, goes to key signing parties and has a PGP/GPG key?
Well you may not be aware of that but one of your close but not so tech savvy friends may be much more trustful and easily fall for such a trick if it's done right. Thanks to the six degrees of separation effect you're quite close to various untrustworthy people. If your web of trust policy settings aren't tuned perfectly well you may unknowingly have some bad guys slip into the set of trusted ones simply by the means of less responsible actions of the others that you (have to) trust, who aren't as competent as you.
I think you have a significant misconception here.
Encryption without proper authentication of both parties (usually SSL cert to authenticate the server and login/password to authenticate the user) is worth almost nothing. What good is your encryption if the users connecting to your service for the first time have no way to make sure that the site is not a scam? Their passwords may very well get harvested by a malicious third party. And what this encryption buys you then? Nothing.
Well, I've read some of your posts, and I can see that you aren't concerned with those attackers. Citing yourself:
Let's connect the dots. You have a site that will never have issues with scammers (you say domain typo, but it seems you're completely unaware of the myriad of other attack scenarios that PKI successfully prevents), hosting application that doesn't require high level of server's identity verification (which is the purpose of the SSL server cert), but your clients somehow need encryption.
Tough noodles! You should realize that before FF3 you did it all wrong! Since the users saw a click-through warning, which they blissfully dismissed, the whole encryption you made was a waste of server's and clients' CPU cycles and wasting of electrical energy. Someone could direct them to a malicious proxy and they'd see an identical warning which they would happily click through and then use your site, but their login and password would already be in the wrong hands.
But if you're not concerned with such attackers, then simply turn encryption off! It's not good anyway, and it's a waste of time (your and your peers) and resources.
You're proposing an alternate low cost/low verification level CAs. To get around this problem. Are you fully aware that when you lower the financial and organizational barriers to obtaining a certificate, you open a large can of worms?
Suddenly not only non profit organizations, but all the cheap scammers can afford obtaining dozens of throw-away, fully valid certificates to perform their phishing scams. This time users won't see any warning, but a nice shiny lock icon in their browser that makes them feel safe and warm while they submit their financial details to a malicious site somewhere in Russia. Is this really what you want?
Realizing your proposal would really beat the purpose of this whole system - the public key infrastructure, the certificates and their chains, the encryption and SSL handshake, all this would cease to have any usefulness and would become dead weight.
True, there's one interesting potential solution that could be plugged into the existing infrastructure.
It's called a trust web and the likes of CAcert operate on a similar fashion. However, this idea has not been tested in a real world scenario where successfully attacking the system would promise significant financial gains (e.g. by masquerading as bank sites), unlike the X.509 system we have in place now.
It's uncertain whether a trust web would withstand concerted distributed attacks on its trust propagation from the criminal underground.
Yes, there were some high profile problems with the current X.509 infrastructure (like the Verisign-Microsoft Authenticode fiasco. But they were quickly plugged - look at the advisory I've linked to. This is where the cost of the certificate comes from. The issuers actually verify the identity of the requestor, and if they fail to do this from time to time, they still have backup systems in the form of fraud detection departments. That's why obtaining a certificate cannot be free and if it was free, that certificate wouldn't actually certify any useful information.
At last a well researched reply :)
You've probably missed some hypothetical ones.
These are probably the most likely to succeed - especially the second one since the human is usually the weakest link.
Suppose you lose your private key to a malicious party. How are you going to organize its proper revocation? Who is responsible for making sure this information gets propagated to all interested parties? Keyservers? The notarius? You yourself (contacting all your fiends, your bank(s), the government etc to tell them to disregard that key)?
The problem with PKI is that it requires a complex infrastructure in order to really be resilient against all possible ways in which things can go wrong.
Passports are for single persons, they don't fall under such strict renewal requirements as public websites that serve multiple people would do.
If you do malicious stuff with your passport, the damage is quite limited. But when you compromise a popular web server's private key... well, let's say the potential is obviously much higher (depends on the website of course).
I don't see them in my CA collection that shipped with Firefox 3.0.1pre. What's their browser coverage?
You got the concepts wrong.
The foremost aim of an SSL cert is to bind a public key to a common name which contains an identifying attribute, in this case a DNS domain name.
The public key can then be used to set up an encrypted channel between the client and the server by exchanging a one time session key (that's called an SSL handshake and I'm simplifying it a bit, since you seem to not even know what's the relation between encryption and a certificate).
The encrypted channel could theoretically be set up without any cert, just by means of exchange of public keys (actually, one public key from one side would suffice and the scenarios we're talking about are like this - no one uses client certificates on the public web; they are more common on corporate intranets with hardware tokens though).
However, using public keys without certificates would be susceptible to man in the middle attacks, since a malicious server (to which a client was redirected by DNS spoofing or traffic interception) could impose on the client that it is the real server and proxy all the requests from the client to the actual server, and record all data or modify it maliciously in real time.
This is where certificates kick in. If the SSL handshake is initiated between the unsuspecting client and the imposing malicious server, the malicious server has to feed its own public key to the client. This key cannot be bolted onto the real server's certificate, because this would violate CA's digital signature on that certificate and it wouldn't validate. So the best the malicious server is able to do is to provide its own certificate to the client. This certificate may be:
In case 1, with Firefox was a warning popup they dismissed. With Firefox 3, they finally are properly warned that something is wrong in a way that they cannot mindlessly evade.
In case 2, well, that obscure CA's certificate shouldn't initially be in the trusted CA store the system or browser ships with, and users will get a warning - see case 1.
To sum up, I think that the change made in Firefox is actually an excellent move that has the chance to make the certificates actually worth paying for, which should bring more players to the certification market, stimulate competition and bring certification prices down. I just hope that Internet Explorer follows with similar improvements in the future.
So what technical solutions do you propose to the accountability and verifiability problem on the Internet? You don't seem to have provided any constructive alternative proposal, you just keep whining about big buck companies.
Well it's said that the most accurate preserved records are tax records. Money exchanging hands is usually some indicator that a party puts some weight behind its efforts, and money trail is the hardest to falsify. This filters out cheap scum bags effectively.
There are lots of people who would sell the service of showing their ID to someone else for a crate of cheap wine.
I'm not saying that CAcert approach isn't viable, I'm saying that charging a credit card IMHO results in more accountability, since you need to ID yourself to get a credit card, and in addition you have to expedite some money to get that commercial cert.
When you've spent that money, you're less likely to use it for some illegal stuff that will get the paid certificate revoked and possibly involve yourself in some law enforcement problems should they trace the money trail back to you through the credit card company.
The problem with your argument is that you compare apples to oranges. The situations are different. With SSH, usually the initial connection to the machine (for the root user) is by the same person who is setting SSH up, so he/she may be quite confident that this initial connection it's intercepted. For the unprivileged logins, the users usually are involved with the sysadmin too (they get the password from him at that time, or a confirmation that he installed their public key in their .ssh). So it's usually safe to go "yes" on the initial connection and then the key gets cached.
On the web, OTOH, you connect to distant server, you usually have no way to verify that all is well and OK, you cannot get the admin tell you the server key's fingerprint, tail the logs and check that you log into the machine from the expected IP address and so on.
And one more thing about SSH. You say that this "trust first time" stuff that's in SSH is a good solution. But it's only good when you are competent and know what you are doing and you're careful enough. Otherwise, it only gives you false sense of security.
In our company, we do lots of security audits and I've seen misguided admins who use SSH like you describe. We have a wonderful trick that we show them. We ask them to log in to one of their servers (earlier, of course, we poison that switches ARP caches so that all the traffic passes through our laptop). They log in, then we tell them what their password is. When in horror they ask "HOW?", we calmly ask them whether they've seen the "server identity has changed" message and why did they continue connecting.
It's not as impressive if they use public key authentication instead of passwords, but it still works for intercepting the session and doing fancy stuff on their servers.
So if this scheme is unworkable for supposedly technically competent sysadmins, how on earth do you expect it to work for clueless web users (think Aunt Tillie)?
You mean the VeriSign - Microsoft authenticode fraud ? Or some other, newer screwup that I haven't heard of?
When issuing a certificate, Verisign supposedly (yes, I'm trying to be realistic) checks that the requesting organization is still in business, that it has rights to the domain name, that the request comes from someone who works for the organization, that the corporate contact is aware of the certificate request, that the technical contact is authorized to receive the certificate and they check the domain name for similarity (phishing-wise) to some established brands names.
I still highly doubt that with free or cheap certificates you would ever get that level of verifications. Much more likely the cheaper the certs, proportionally the more likely they would be to belong to malicious parties.
This idea is very interesting indeed. If I understand you correctly, you're proposing to move the web of trust PKI known from PGP/GPG to the arena currently occupied by X.509 and hierarchical PKI, right?
This could really lift the burden of managing the complexity of trust, life cycles, secure storage of central CA private keys from the CA. I can see that even Verisign has significant problems with that. Their certs don't seem to specify OCSP URLs yet, and they had some scaling problems with CRL distribution points. Distributing the PKI could solve lots of problems and the cost of maintaining that infrastructure would be more evenly distributed, too, which would lead to practically free certification (with some hidden costs, obviously, mostly in time and effort of participating parties).
There are potential problems here that I see, though.
Adapting the web of trust idea to the web for the HTTPS protocol would need preparing and constantly tweaking some variables. E.g. above what level of trust should Firefox's address bar turn yellow? How do you communicate the level of trust of the given site to the user so that he's likely to understand it correctly?
And how do you prevent coordinated abuse of that system? Note that the OpenPGP's web of trust has never been tested in the situation where successful attacks would be so highly rewarded as they currently are in the realm of HTTPS/X.509 (think phishers and other scammers).
For example, a network of criminals might recruit some number of homeless people from large cities around the world. These people have their IDs, and are willing to do anything for some money they need to spend on food/alcohol etc. It's quite common for those homeless with nothing to lose to get recruited, shaven, dressed and sent into bank offices to open small disposable credit accounts in their own names using their IDs, only to hand all the money they can get to their recruiters who give them some small percentage which they are going to quickly spend anyway. Then they run into trouble with law enforcement when it turns out they cannot pay, but hey, they didn't quite realize what was this all about, they weren't quite sober anyway.
Now the criminals might find it beneficial to recruit those people to go into key signing parties and obtain verified signatures on their keys/certificates practically for free (well, say one cheap wine per signed key). When they collect the necessary amount, they cross sign those keys to gain high enough level of trust and set up a large scale phishing site. They make gobs of quick cash before the web of trust reacts to the manipulation, which can require a significantly long time in a loose informal structure like this.
Would the idea that you propose be resilient against concerted efforts like this one?
No, it would't. It would be much worse. Experience dictates that users, faced with vague, loosely defined indications such as "this might ...", "this probably is/isn't" etc, simply lose any orientation about what to trust and what not to trust.
Then they simply start clicking OK/Yes/Add/Don't bug me anymore/ every time and this beats the purpose of the whole transmission encryption and authentication process. You could as well use plain HTTP.
The distinctions should be very clear, and the most clear variant has two options:
Only this leaves no room for doubt and incorrect interpretation.
Well, I was broadly generalizing because the issues of security and PKI are inherently complex and in order to convey what I've meant in a completely correct way, I'd have to allocate a whole day for writing my comment, and it would be longer than all other comments in this thread combined.
However, I'm well aware of all possible causes that a certificate may be revoked for. Still, all of them are because of some abnormal, unplanned circumstances. Let's take the example you've mentioned. Why would a certificate need to be reissued to use a new private/public key pair? In order to better define our hypothetical situation, let's say in the Netscape Cert Mgmt System nomenclature, that the original certificate was superseded (It's one of possible options when revoking a cert in NCMS).
This reissual needs to take place because the original certificate's private key has been destroyed/lost. It wasn't compromised to our knowledge (the "compromised" is another scenario that's clearly defined), but clearly something went wrong.
So this indicates that the holder of the certificate wasn't a serious, trustworthy party after all. Otherwise, he would plan accordingly and wouldn't let bad things to happen to his key, right? This applies even to seemingly innocent things, like moving to a new domain name and getting the old name's cert revoked. Trustworthy parties don't simply pull down old domains and web servers overnight. They keep them indefinitely for all the users that may have them bookmarked (at least until the certificates for the old domains expire peacefully).
So you see that even your argument confirms that high number of revocations usually correlates to low level of assurance. There's still something wrong going on, it's just that it may be wrong in a different way that most people will imagine/assume. The CA issues certificates to parties that shouldn't have those certificates issued to them.
Well, let's have a look.
Verisign has a much more complex pki hierarchy, so there are much more different CRLs. I've visited my local bank's site and had a look at their cert's chain. There were 3 levels of Verisign CAs above their x.509 cert and two of them had CRL distribution points specified (the top one, Verisign Class 3 Public Primary Certification Authority, had none, but I think it didn't need one since it's highly unlikely that the lower ones like Verisign's Class 3 Public Primary Certification Authority G5 will ever be compromised. They still have a 3rd level below and their 2nd level private keys are probably used only in high security, do-everything-manually-inside a-vault-by-a-highly-trusted-personnel-group context, not for signing any customer's certificate requests).
So I downloaded both CRLs:
and then inspected them:
Would you care to somehow substantiate that claim? How are you going to compromise that cert? What do you mean by "compromise"? Without serious arguments and proofs you really sound like that crazy Time Cube guy.
Do you even have any understanding of how PKI works? Could you prove it by elaborating on it and presenting real attack scenarios? Because without that you just seem to be a troll.