SSL key negotiation process analysis

I. Description

Despite done certificate generation, two-way authentication, SSL communication programming such things, but it has been unclear how to complete the SSL key exchange. Look online information are different opinions, talk to a recent study this issue and friends, and then deal with customer feedback happened last week when the SSL version is too low leadership also wanted to find out key exchange process SSL, so to some research.

 

Second, the key exchange procedure

The first step, the client to the server, Client Hello (Client Random + Session ID + Cipher Suites); Cipher Suites is a cipher suites supported by the client list.

The second step, after the service receives the Client Hello, remove the Session ID Session ID to see whether they know in the list.

              If, Server Hello is returned (Server Random + Session ID + Cipher Suite + Exist Key (Client Random)), require the use of existing communication key.

              If not, return Server Hello (Server Random + Cipher Suite + Certificate); wherein, if the server selected from the Cipher Suite made using RSA key exchange the entire Server Hello tcp returned as a package, if the DH key exchange do so Certificate so with a single return package tcp.

The third step, the client receives the Server Hello.

              If you see an existing key is required for communication, transmits Change Cipher (Exist Key (Server Random)); then sends a subsequent http requests directly.

              If you see a key agreement is required, check whether the certificate in question (such as format, valid, if the signer is trusted CA), no problem server selected cipher suite is removed; if RSA is a class, and then generates a random number using public key cryptography (i.e. premaster) to the server, the client-selected press member kit plus the calculated symmetric key. If the class is DH, the client generates a pair of DH key, the public key (plain text) is calculated symmetric key sent directly to the server, the client certificate using the public key and their DH private key.

The fourth step, the service receives the client response.

              If Change Cipher, then switches to an encryption mode, waiting client requests.

              If a key agreement, the RSA is selected and the original, using the original private key to decrypt PreMaster acquired random number and the cipher suite selected by the random number generator plus three symmetric key. If the original is selected DH, the public key with their own private key taken calculated symmetric key.

 

Third, the key exchange process stream

3.1 DH agreement key

 

 

3.2 RSA agreement key

 

3.3 Use an existing key

 

Some four key exchange process explained

 4.1 TCP / SSL / HTTPS What is the relationship between each other

We chase Road tcp stream of ssl look at the communication process, as shown below: After the first three-way handshake to establish tcp connection, and then ssl key negotiation process, and then transfer the contents of the application layer, the last four tcp still waving .

So the overall relationship is this: the original is "tcp + http" now is "tcp + ssl + http"; https is not a mere agreement, but "ssl + http"; if you like you can in any "tcp + xxx" interposed ssl formed xxxs, such ftps.

 

4.2 SSL Session ID in understanding how

I just started listening Session ID do not feel anything, and then analyzed using an existing key Client Hello and leadership feedback Shihai said, why the same Session ID and in front of this new tcp connection in the Session ID, then the leadership has regularly phrase awoken: Yes, of course Session ID is used beyond the tcp connection.

也就是说,前面说的使用已有密钥模式,其中的Random、Session ID、Cipher Suite都是之前的tcp三次握手和四次挥手使用过的;从编码角度看,如果原先已协商过密钥,那可以保存Random、Session ID、Cipher Suite后续在Session ID有效期内建立SSL连接,只要进行使用已有密钥过程即可,不需要进行密钥协商过程;但一般来说,我们都不是自己实现SSL过程而都是直接调用SSL库,所以这事也不归一般的应用开发人员管。

 

4.3 怎么探测服务端支持哪些SSL版本和加密套件

从原理上讲,使用某个版本的SSL发送Client Hello,如果服务器不支持该版本则会使用其支持的版本回Server Hello;对于加密套件,则可能是客户端声称其只支持某个加密套件,如果返回Server Hello则表明服务端支持该加密套件,如果返回Alert(Handshake Failure)则表明服务器不支持该加密套件。

当然,其实上边都是个人的猜测,并没有充分的证据;不过这里倒可以提供一个方便的方法探测服务端支持哪些SSL版本和加密套件,即使用nmap:

# -p是端口
nmap -p 443 --script ssl-enum-ciphers 192.168.220.128
# 可以用以下命令来查看帮助说明
# nmap -p 443 --script-help ssl-enum-ciphers

结果如下图所示,各套件末尾的A/D这种表示该加密套件的加密强度级别,A级的加密强度最好

 

Guess you like

Origin www.cnblogs.com/lsdb/p/11233394.html