I don't understand how SSL can be secure. Aren't the keys for encrypting and decrypting transferred in the open before encryption can take place? If so, isn't a man-in-the-middle able to snoop those keys?
I like this analogy for how keys are exchanged and never exposed in transit:
I put my secret in a box and put a lock on it for which only I have the key and ship the box to you. When you receive the box you put your own lock on the box for which only you have the key and send the box now with two locks back to me. When I get the box I take my lock off and send it back to you. Finally you open the box by taking your lock off. The box is always locked in transit and no keys were ever out of the owners hands.
This principle is called Diffie-Hellman key exchange ( http://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange ) and is vulnerable to a man in the middle attack. The man in the middle would complete key exchanges with both Alice and Bob. All that A and B see are valid key exchanges.
This is why we have trusted third parties like Verisign.
The further problems with this are discussed in the article.
More correctly, this is how to send a message using commutative ciphers without ever exposing any keys - public or private.
This is the problem with analogies such as these. They can sort of be nearly right, and sort of give the right idea, but at the same time actually be quite misleading in the detail.
Here's what's actually equivalent to the analogy. We openly agree a large prime N (this is equivalent to agreeing on a style of box to use). I select a random number A (the padlock) and compute its multiplicative inverse A' (mod N) (the key). You do the same to compute B and B'.
I want to send you a message M. I compute W=M^A (mod N) [I put the message in the box and lock it with the padlock] and send that to you. You compute X=W^B (mod N) [you put your padlock on it] and send it back.
Now I compute Y=X^A' (mod N) [unlock with the key] and send you that, and finally you unlock with B' by taking Z=Y^B' (mod N).
We compute Z=Y^B'=(X^A')^B'=((W^B)^A')^B'=(((M^A)^B)^A')^B' but that's equal to M^(A.A'.B.B') which turns out to equal M. On the way any evesdropper will know M^A, M^(A.B) and M^B, but it is computationally infeasible (if P!=NP) currently to compute M, A or B from these.
The obvious method of attack is to use M^A and M^(AB) to try to deduce B and hence compute B', but that's equivalent (probably) to the discrete log problem ( http://en.wikipedia.org/wiki/Discrete_logarithm ) which is thought to be pretty similar to factoring integers.
Both RSA and Diffie-Hellman-Merkle-Williamson key exchange need different analogies. RSA usually uses the analogy that I give people open padlocks, and they use them to send me locked boxes. I can open them because I have the key.
I don't know a good analogy for the DHMW key exchange. It works like this. We agree a large prime N and a suitable base b. I choose a random A, compute X=b^A and send X to you. You choose a random B, compute Y=b^B and send that to me. I compute Y^A, you compute X^B, and we both end up with K, a shared secret which we can use in a symmetric cipher.
I now await the really clever people to correct my errors.
I don't think this is the method SSL uses, because what you're describing is just a variant of symmetric-key encryption. I think SSL uses asymmetric-key encryption. The better metaphor for that is a lock that anyone can lock, but only one person can unlock.
That’s how SSL/TLS does the authorization step, but the typical encryption of the actual content sent back and forth uses a symmetric-key block cipher (the two sides negotiate and it’s pretty modular, so I think you can do whatever kind of encryption you want on the messages, even just sending plain text after a TLS handshake if you want).
True, but my point was that the actual key exchange (that is, the exchange of the symmetric keys used for the bulk of the encryption) is done using asymmetric-key encryption. Since this was in response to the question of how keys are exchanged, I thought it was the relevant phase to discuss.
Except, not necessarily, no. Sorry, my grandparent post should have been clearer that using a public-key method is only one of the ways to do authentication in SSL/TLS. Either way, some symmetric cipher is used for all the content.
I've heard a different variation of the metaphor: I have box with two keys. When I use the first key to lock the box, it can only be opened with the second key, and vice versa. I keep the first key hidden, but publish details of how to make a box and the second key for all world to see. This means that anyone can send me a secure message by simply making a box to my specifications and locking it with the publically available key. Only I can unlock it. This is asymmetric key encryption.
Asymmetric key encryption is slow, and symmetric is fast, so we use the former to set up the conditions necessary for the latter: If we both have a box and keypair like this, then you can send me your secret phrase using mine and I can send you my secret phrase using yours. Now that we each know both secret phrases and nobody else knows either, we can combine the secret phrases and switch to symmetric. That's how SSL is set up.
This is the description of public key cryptography, or as you referred to it, asymmetric cryptography. It is a different technique and solves a different problem from the other metaphor above by asmithmd1, which is for Diffie-Hellman(-Merkle) key exchange.
Thank you, this is one of the most succinct explanations I've read. I understood how it worked in a roundabout concept, but you made the explanation simple like it should be.
The sender and receiver exchange public keys which can be visible by anyone. Only the private key can unlock what is locked with its associated public key. It would be like me sending you a locked box (that only I have the key to) with
a slot in the top to allow messages to go in but not come out. And then you send me a similar locked box with a slot in it for me to put messages in. Once a message goes in the slot, only the private key owner can unlock it.
There is still a problem with man in the middle attacks where an attacker steals each public key and sends his own public key back to both participants. This problem is somewhat solved by the use of certificate authorities who certify that the public keys belong to who they say they belong to. Some of these certificate authorities have delegated their powers to organizations which may not be trusted.
The answer to this question is simple: the "egg" key in this chicken in egg problem was distributed with your browser. If a man in the middle can mess with your browser installation, you have bigger problems than SSL.
I don't know enough about certificate revocation lists (CRLs) to be sure, but isn't it possible for individual browser users to import them?
In that case, couldn't the EFF or similar organizations take matters into their own hands, and release lists of certificates they think users should be cautious about?
I suspect libel laws make this more difficult, but perhaps not impossible, if revocation providers are careful not to overstate their case, but just say "here's a list of certificates of organizations who have been documented to meet the following criteria...".
[Edited to add:]
http://en.wikipedia.org/wiki/Revocation_list#Publishing_Revo... says that "To prevent spoofing or denial-of-service attacks, CRLs usually carry a digital signature associated with the CA by which they are published. To validate a specific CRL prior to relying on it, the certificate of its corresponding CA is needed, which can usually be found in a public directory." It's not clear whether the browser checks this signature, or whether the user is expected to. In the latter case, a CRL could be signed by the 3rd party revocation provider instead.
tl;dr - the article is about the susceptibility of SSL protected websites to man-in-the-middle attacks due to the CA trust model being only as strong as the least competent/trustworthy CA that a given browser, well, trusts.
Background: Browsers check for a man-in-the-middle attack by verifying that: a) remote site's certificate is signed by a certificate authority (CA) that the browser trusts; b) the URL matches the common-name attribute (CN) in the site's certificate.
So, for an attacker to get around this check, they need to: a) forge/spoof DNS (relatively easy); b) get a cert signed by a CA the browser trusts with a matching CN of the site to be spoofed (supposed to be relatively hard). (There is also Extended Validation, I won't go into that here.)
Unfortunately, these days, browsers trust _a lot_ of CA's, either directly or via chained certificates. Some of these chained certificates may be surprising to you.
The good news is that this isn't a problem with the SSL protocol so much as it is a problem with how the CA's and browser vendors have decided to configure SSL. Which means you can fix a lot of this by removing certs from your browser configuration.
"Whenever you're sending sensitive information online—say, your credit card number to Amazon or a message over Gmail—the content is encrypted before being sent and then decrypted by the Web site you sent it to. (Sites using this secure mode have URLs that start with "https," and browsers add a padlock icon as well to demonstrate you're communicating securely.) Every vendor has its own rules for how to scramble information so that only it, the intended recipient, can decode it."
SSL does not encrypt content and vendors don't all ahve their own rules about how SSL works. It's a standard. I really wish that journalists covering technical matters would do enough research to explain things properly.
So long as Verizon happily issues new CAs to Etisalat, the following is a weak measure, but for the moment: is there a way in various browsers to declare that you don't trust specific CAs? I can't practically remove the Verizon certificate (in my Certificate Authorities tab, I don't see Verizon, but I do see GTE Corporation which was its previous name, so I'll guess they're the same...), but could I declare "don't trust certificates containing these certificates"?
Yeah, you can usually delete certs, at least in third-party browsers, even if they're built in.
I'm not sure if you can delete any of the OS's built-in certs ('cept maybe on Linux); and I'm not sure I'd want to risk that. Verizon/GTE/whoever probably authenticates a lot of really useful people too... (Which is a risk with deleting the browser's root certs as well.)
I'm pretty sure the live version has mods that aren't in the public version. PG has said that he makes mods to improve various aspects, particularly things like detecting voting rings and other such gaming of the system.
