Recently, a friend of mine asked a question about key exchange in SSL without encrypting the key. His question came after examining a Key Usage certificate extension setting in the certificate template. There are two options: Allow key exchange only with key encryption and Allow key exchange without key encryption. How it can be possible that the key is not encrypted??? Here is an image of the respective setting:
Before I’ll explain the question, we need to become more familiar with the SSL subject.
When web browser connects to web server by using HTTPS address a lot of interesting things occur there collectively called SSL/TLS handshake.
Generally, the following procedure is performed:
The most interesting point here is random symmetric session key generation and transfer to peer.
Obvious question: who is responsible to generate the key? The answer may not be that obvious. It is impossible for server to be responsible for session key generation. Why? Because there is no secure way to tell that key to client.
Instead, the key is generated by client. Once generated, the client encrypts the key with server’s public key and sends the key to server. Server uses its own private key to decrypt the key and he is ready to start higher-level application protocol. This technique is called: key exchange with key encryption. There is no place for MITM (Man-In-The-Middle) attack, because an attacker cannot decrypt encrypted key as he do not have access to private key (which is held by server only).
This key exchange mechanism may have security issues. Only one peer has control over session key generation. No [perfect] forward secrecy: if secured traffic was recorded by an attacker and later he gets an access to a server’s private key, the hacker then will be able to decrypt session key and decrypt recorded traffic and data.
Another issue (not that important, but anyway): only two peers can communicate via single SSL tunnel. For example, if you need a shared SSL tunnel for more peers then you will have to establish as much as tunnels with unique session key in each tunnel. Key encryption generally is used in SSL protocol.
However, there is another way to securely exchange session key that supports:
This technique is called key agreement. The most popular key agreement protocols is Diffie-Hellman protocol which can be simplified to the following image (stolen from wikipedia):
Even if attacker records entire traffic, he will be unable to extract secret color by having mixture and common (public) color.
As you can see, natively Diffie-Hellman key exchange even do not require digital certificates to secure key exchange (however, they are required to authenticate peers). By using this technique, you can easily connect as much parties as you wish. Actual DH protocol implementation is more complex and can provide additional security features (like perfect forward secrecy), main principle is the same. Key agreement protocols are used in TLS protocol.
Today we discovered the difference between two common session key exchange techniques with and without key encryption, their advantages and disadvantages (where possible). Now we can conclude that key agreement key exchange protocol looks more interesting and preferred for secure connections.
Post your comment: