Discuss: Understanding SSL
by Shalini Gupta
Great article Shalini!
Hi,
A well written article there, clear and precise. One thing which you might wish to include as part of a follow up article is the way wildcard SSL certs work. It is something not many people understand clearly but it makes a good deal of business sense for a large server base. Looking at your writing style am sure you can add value to that area.
Checkout http://wiki.cacert.org/wiki/VhostTaskForce for a pointer on what I'm referring to.
Looking forward to read more of your work!
hi shalini it's a good article about ssl.can u emphasis on some more points of the ssl certificate verification process in detail.in ur post u mentioned the client verifies the server's certificate my question is how.does the server first create his digital signature by creating a hash of the certificate and then encrypting the hash with it's private key.the server then attaches this encrypted hash to the certificate and sends it along with it's public key.the client then decryptes the digital signature using the public key in the certificate and hashes the certificate and compares the hash values proving thus the identity of the server and the authenticity of the data that it was not tampered in the path.kindly write back to clarify on this.thank you for giving information on this critical topic.
sushil
I disagree with the statement the SSL is immune to man in the middle attacks. If the attacker is able to capture the intial key exchange then SSL cannot protect the confidentiality of the data transmitted. any thoughts ?
sushilmenon wrote:
can u emphasis on some more points of the ssl certificate verification process in detail.
Thanks for the nice words, Sushil. Here're more details of the certificate verification process.
A server certificate contains the digital signature of the issuing CA.
The core idea of a certificate is that a CA takes the server’s public key, signs the public key with its own private key, and returns the information to the server as a server certificate. When the server sends the certificate to client, it signs the certificate with its (server’s) private key.
The client extracts the certificate (containing the CA signature) with the server's public key. By using the CA public key (embedded in the client’s application) and the CA signature on the extracted certificate, the client can validate the CA signature.
If the digital signature validates the certificate, the certificate is recognized as intact and authentic. If it is valid, the public key used to extract the certificate is recognized as good.
To verify the digital signature on a certificate, client must have the public key of the issuing CA. Because public keys are distributed in certificates, client must have a certificate for the issuing CA that is signed by the issuer.
CRV wrote:
I disagree with the statement the SSL is immune to man in the middle attacks. If the attacker is able to capture the intial key exchange then SSL cannot protect the confidentiality of the data transmitted. any thoughts ?
Let's see why Man-in-middle is not possible with SSL.
The whole idea in SSL is about protecting the transmission right from handshake to data transmission.
As mentioned in the article a temporary, random Session key (symmetric key) is sent from client after encrypting it with the public key (asymmetric key) of the server. If man-in-middle intercepts the encrypted session key, he will see scrambled data. In order to decrypt the contents he need server’s private key (which is just with the server) and if he tries to break the code to decrypt the data, it will take him a few MILLION years to do that given the current capabilities of such hardware and software. Each session uses a different session key, so even the theft (quite difficult) of one key does not result in multiple sessions eavesdropping or tampering.
In SSL, the overall cryptographic strength is related to the security of either the public/private key or symmetric key algorithms. In order to get ‘Session key’ attacker needs to break either of them:
- public/private key pair (to read the session key during transmission) or
- session key itself.
Let’s see the probability of getting these attacks successful!
Attack 1: Deriving private key from the public key (One break for all encrypted transaction). With current standards (RSA/ECC) it is quite difficult to generate the private key from the public key. Mathematically it is possible to do the same and the only thing is the time and money taken to get it. It (should) take much more time to do it with the key (or one-way) than to brute-force the cipher. With current encryption schemes the difference factor should be multi-digit orders of magnitudes. A 1024-bit key could fall to a machine costing $1 billion. The cost of such a machine is beyond the reach of most individuals.
Attack 2: Breaking Symmetric key (one break for each single encrypted transaction). SSL uses 128-164 bit keys. Such a key is realistically impossible to crack by brute force methods using current computing technologies. We don't have a computer fast enough to break the key in any reasonable length of time. At lease to the best knowledge of current cryptanalysis, 168-bit Triple DES and 128-bit Blowfish are safe. All new browsers now come with 128 bit encryption.
Mathematics: Using keys that are 128 bits long means that there are 2^128 possible keys to search through, whereas with a 40 bit key there are only 2^40 keys, making the 40 bit key encryption 2^88 ( approximately 3x10^26) times easier to crack. Every extra key bit doubles the search space, so it doubles the time for a brute force attack. e.g. the EFF's DES cracker broke 40-bit encoded data in an average 5.9 secs and DES 56-bit key in 57 hours. Make the key 96 bits, 32 bits longer. The brute force attack now takes 2^32 seconds, just over a century. Go to 128. Now the attacker needs 2^32 centuries, roughly the lifetime of the universe. That is, for large enough key sizes, available computing resources are insufficient to break the keys in anything like a short enough time to be useful.
Good read at:
ftp://ftp.rsasecurity.com/pub/cryptobytes/crypto4n2.pdf
http://www.rsasecurity.com/rsalabs/node.asp?id=2100
lot of signing from varied sources. i have few queries and some gaps in understanding the signing process. is it possible to explain in simple points...just taking an example of the actual data, let us say the message is "abc company will procure xyz company". how does this message appear in each stage of signing before it arrives at the destination and how it is decoded. what will be the requirement and configuration at both source and destination. who should have what keys for the message exchange. why is the message digest signed with a private key..before that what happens to a message after signing??
Very nice article. It helped me to clear the dust in some concepts.
a gr8 article shalini.
I have a question to u. If i want to implement SSL communication between a client and a server, which language will be the best choice. and which are the steps that one has to implement?
sslexample.com is a parked webpage..
can u give other example of SSL page
Hi Shalini,
That was one of the best explanations of SSL I have seen. I am still confused.
If my PC is on a hub sniffing in promiscuous mode all traffic to and from the client PC, I will see every aspect of the transaction. I will see the same public and private keys that the client received. The server will decrypt the client's random number using the same keys that the client used to encrypt it in the first place. I have seen those same keys the client used and should therefore be able to unencrypt the random number. I just do not see how the connections are secure in this instance.
Thanks in advance,
-Paul