Foreword
Continued articles: What [ipsec] [crypto] a little different digital certificates in the end is
In this part mainly on an extension of the content. After the abstract to understand what the certificate is conceptually, we are going to
From a practical point of view, to two IKEv2 and TLS protocol as an example, familiarize yourself with the digital certificate authentication on the implementation of the agreement.
author: classic_tong, date:20190914
One IKE
I use strongswan to build such an experimental environment. Both parties is configured to use the certificate of the way.
For this reason I am a self-signed root certificate and IKE each of the parties to the signature of its certificate.
Generate a self-signed certificate ways to see: [ipsec] [strongswan] generate a self-signed certificate with strongswan pki tools
1.1 strongswan configuration
After generating a certificate is good, and placed into the specified location, using a configuration similar to the following:
connections { net-net { remote_addrs = 192.168.8.103 local { auth = pubkey certs = t129Cert.pem } remote { auth = pubkey id = "C=CH, O=t9, CN=t9.tong.localhost" }
Here we can see, id configuration, that is, the certificate subject. (Review the situation on the content of an article, the establishment of a clear chain of logic between the user and the name)
1.2 Analysis of the consultation process
First, referring to [ipsec] especially hard core ike / ipsec NAT traversal mechanisms analysis of the first chapter, please understand the premise IKE interaction, continued follow-up content.
See below, we can see, the authentication process takes place in the second interaction. ike both sides sent their names, and their name, and authentication message (encrypted by a private key of the content, in order to authenticate each other, they will pass
The public key to decrypt the certificate, in order to confirm the identity of our legal)
author: classic_tong, date:20190914
We use private key encryption of content, has agreed to advance the good in rfc. So the contents of the other party clearly decryption should look like, is correct. About the contents of the last packet is sent us (i.e. a first communication packet).
SUMMARY responder user authentication is the second communication data packet.
Specific content, see: https://tools.ietf.org/html/rfc7296#section-2.15
1.3 Pre-shared key authentication
By the way, pre-shared secret key authentication method. The basic principle is the same. But in the calculation of the authentication message, adding the pre-shared secret key information. This is a non-shared key people, we calculated
Digital signature authentication data segment. See RFC: https://tools.ietf.org/html/rfc7296#section-2.15
In addition, id information communication data is slightly different, see screenshot:
author: classic_tong, date:20190914
Two TLS
TLS authentication is a little bit complicated. Let's name it is part, as one said, the name by associating SAN URL and certificate of. Input domain name in the browser must be present in the SAN field in the certificate.
Order by name of the user to verify the logical chain. Then he went on to say the next section. First look at tls signaling interaction diagram:
We can see, server when verifying client, client certificates are sent a certificate and verify data to the server for verification, but we do not see the server sends designed to make certification
The message segment. The reason is this, TLS authentication mechanisms included in the mechanism complete with keys in the interaction of.
Reference: https://security.stackexchange.com/questions/139176/details-of-tls-certificate-verification
https://tools.ietf.org/html/rfc5246#section-7.4.9
RSA key points of consultation and DH keys consultations to discuss the two cases. (We are standing in the general https browsing application to think about this problem, so, here there is only a single client to discuss the verification server)
1. When using RSA key negotiation, client uses the public key to encrypt a set of proprietary content to the server to do the secret key agreement. If the server is not private. Consultations that are inconsistent, the last client to send
Past finish (11) messages will not be decrypted correctly, server could not disguise a correct decryption can be finished (13) sends a message back.
In RSA key exchange, the client generates a random sequence of bytes and performs RSA encryption using the public key from the server's certificate. Then the client sends the resulting ciphertext to the server and expects the server to decrypt it (using the private key corresponding to the public key from the certificate) and use the random value in a KDF, together with other values, to generate symmetric keys and send a Finished message encrypted with the resulting symmetric keys. The client verifies the Finished message. The server can only succeed in generating the expected symmetric keys by decryption RSA encrypted message. https://tools.ietf.org/html/rfc5246#appendix-F.1.1.2
2. When using DH, server message with a private key (4) made of a digital signature, client can be verified with the public key.
In DHE/ECDHE key exchange with PFS, the server signs its ephemeral key using the private key corresponding to the public key in the certificate and sends this in ServerKeyExchange. The client verifies the signature using the public key from the certificate. https://tools.ietf.org/html/rfc5246#appendix-F.1.1.3
author: classic_tong, date:20190914