Alliance Chain Series-Https two-way authentication

Boost realizes two-way authentication solution

boost::asio::ssl::context

To perform mutual authentication with OpenSSL, it must be used on the client side and used SSL_VERIFY_PEER
on the server side SSL_VERIFY_PEER|SSL_VERIFY_FAIL_IF_NO_PEER_CERT. If it is only used on the server side SSL_VERIFY_PEER, it will only send the certificate request to the client, but if the client does not send back the certificate, it will silently accept it.
ctx.set_verify_mode(ssl::verify_peer); // client side
ctx.set_verify_mode (the verify_peer :: ssl | ssl :: verify_fail_if_no_peer_cert); // Server Side
- server certificate Common Namewas the ip|域名same
- only the server detects a client certificate root ca

set_verify_mode(ssl::verify_peer | ssl::verify_fail_if_no_peer_cert)	//配置启用双向认证   

// 也能用ssl_socket调用    (typedef ssl::stream<tcp::socket> ssl_socket)
ssl_socket.set_verify_mode(ssl::verify_peer | ssl::verify_fail_if_no_peer_cert) //配置启用双向认证   
ssl_socket.set_verify_callback(boost::asio::ssl::rfc2818_verification(url.server)); //验证证书与host是否匹配

load_verify_file(file)   //加载信任的根证书    文件
add_certificate_authority(buffer)		//加载信任的根证书 内容

use_certificate_chain_file		//加载自己的证书 文件

use_private_key_file			//加载自己的私钥 文件

openssl

OpenSSL uses ECDSA to authenticate the web browser

openssl s_client -connect wikipedia.org:443

OpenSSL realizes two-way authentication solution

The key points of mutual authentication are the following functions (the server and the client are the same)

SSL_CTX_set_verify ----配置启用双向认证

SSL_CTX_load_verify_locations ----加载信任的根证书

SSL_CTX_use_certificate_file ----加载自己的证书

SSL_CTX_use_PrivateKey_file ----加载自己的私钥

SSL_get_verify_result ----真正进行验证，一定要调用这个函数不然前面四个光配置而已并不会进行双向验证

The following is the specific process of the SSL handshake:

(1) The client sends its own SSL version number, encryption parameters, data related to the SSL session, and other necessary information to the server.

(2) The server sends its own SSL version number, encryption parameters, data related to the SSL session and some other necessary information to the client, and at the same time sends the client the server's certificate. If the server needs to verify the identity of the client , the server will also issue a request for the client to provide a security certificate.

(3) The client verifies the server certificate. If the verification fails, it will prompt that the SSL connection cannot be established. If successful, continue to the next step.

(4) The client generates a pre-master secret for this SSL session, encrypts it with the server's public key, and sends it to the server.

(5) If the server requires verification of the client's identity , the client must sign some other data and send it to the server together with the client certificate.

(6) If the server requires verification of the client's identity , it checks whether the CA (Certificate Authority) that signed the client's certificate is trustworthy. If it is not in the trust list, end this session. If the check is passed, the server decrypts the received pre-master secret with its own private key, and uses it to generate the master secret for this session through some algorithms.

(7) Both the client and the server use this master secret to generate the session key (symmetric key) for this session. After the end of the SSL handshake between the two parties, any message transmitted uses this session key. The main reason for this is that the computational complexity of symmetric encryption is more than an order of magnitude lower than that of asymmetric encryption, which can significantly improve the computational speed of both parties' conversations.

(8) The client informs the server that all messages sent afterwards are encrypted with this session key, and informs the server that the client has completed this SSL handshake.

(9) The server informs the client that all messages sent afterwards are encrypted with this session key, and informs the client that the server has completed this SSL handshake.

(10) The handshake process is over and the SSL session has been established. In the next session, both parties use the same session key to encrypt and decrypt the sent and received information respectively.