In terms of secure Internet communication, https is used with SSL and digital certificates to ensure transmission and authentication security. This article focuses on this mode.
First, explain the terms above:
- Https:A secure HTTP protocol based on HTTP (Hypertext Transfer Protocol), which can be called a Secure Hypertext Transfer protocol. The HTTP protocol is directly placed on the TCP protocol, while the HTTPS protocol adds an encryption layer between HTTP and TCP. From the sending end, this layer is responsible for encrypting the HTTP Content and sending it to the lower-layer TCP. From the receiver's perspective, this layer is responsible for decrypting the data sent by TCP and restoring it to the HTTP content.
- SSL (Secure Socket Layer ):It is a security transfer protocol designed by Netscape mainly for web. From the name, we can see that it is responsible for implementing the encryption layer mentioned above in the HTTPS protocol stack. Therefore, an HTTPS protocol stack is roughly like this:
- Digital Certificate:The name of a document, like the signature of an organization or person, can prove the authenticity of the organization or person. The information contained in it is used to implement the above functions.
- Encryption and authentication:Encryption means that the communication parties will encrypt the plaintext into ciphertext to prevent the sensitive information from being eavesdropped by a third party on the channel. If the third party cannot decrypt the plaintext, it will be powerless to obtain the ciphertext; authentication refers to the identity confirmation method adopted by both parties to confirm that the other party is a trusted message sender or receiver, rather than a fake identity. Communication security can be ensured only when both encryption and seriousness are performed at the same time. Therefore, both of them should be applied in the SSL communication protocol.
Therefore, the relationship between the three is clear: https relies on an implementation method. Currently, SSL is common, and digital certificates are files that support this secure communication. In addition, TLS and WTLS are derived from SSL. The former is generated after Ieft standardizes SSL (tsl1.0), which is slightly different from SSL and the latter is used in TSL in wireless environments.
How to encrypt
- Symmetric cryptographic algorithms: the same key is used for encryption and decryption. Typical cryptographic algorithms include des, RC5, idea, and RC4 );
- Asymmetric cryptographic algorithms: public key encryption algorithms use different keys for encryption and decryption (public keys are used for encryption and private keys are used for decryption ). For example, if a sends and B receives the message, a wants to ensure that only B sees the message. B needs to generate a pair of public and private keys and obtain B's public key. So a uses this public key to encrypt the message, and B receives the ciphertext and decrypts it with its own matching private key. In turn, you can use the private key to encrypt the public key for decryption. That is to say, a given public key can be decrypted only by matching the private key. For a given private key, only the matching public key can be decrypted. Typical algorithms include RSA, DSA, and DH;
- Hash Algorithm: Hash transformation refers to converting the file content into a fixed-length value (hash value) through a public algorithm. This process can be used or disabled. This type of hash transformation is irreversible, that is, it cannot be changed from the hash value to the original text. Therefore, hash transformation is usually used to verify whether the original text is tampered. Typical algorithms include MD5, Sha, base64, and CRC.
SSL encryption process
Hash algorithms (also known as digest algorithms) have two concepts: Strong collision-free and weak collision-free. The weak and non-collision operator is used to calculate the given message X, that is, the same digest information for the plaintext you want to forge. That is to say, you can control the plain text content. Strong and zero-collision means that the same abstract information can be found, but the forged plaintext is unknown.
The efficiency of non-symmetric encryption and decryption algorithms is much lower than that of symmetric encryption and decryption algorithms. Therefore, SSL uses asymmetric cryptographic algorithms to negotiate keys during the handshake process, and uses symmetric encryption and decryption methods to Encrypt transmission of HTTP content. The following is a metaphor for the image of this process (from http://blog.chinaunix.net/u2/82806/showart_1341720.html ):
Assume that a communicates with B, A is an SSL client, B is an SSL server, and encrypted messages are placed in square brackets  to highlight the differences between plaintext messages. The handling actions of both parties are enclosed in parentheses.
A: I want to talk to you securely. The symmetric encryption algorithms here include des, RC5, RSA and DH, and MD5 and Sha.
B: We have a good combination of DES-RSA-SHA.
This is my certificate. It contains my name and public key. You can verify my identity (send the certificate to ).
A: Check whether the name of B on the certificate is correct, and verify the authenticity of B's certificate through an existing digital certificate. If one of them is incorrect, issue a warning and disconnect, this step ensures the authenticity of B's public key)
(A private message is generated. After processing, the message is used as a symmetric encryption key, encryption initialization vector, and HMAC key. This private message-the per_master_secret in the protocol-is encrypted with the public key of B and encapsulated into messages called clientkeyexchange. Because the public key of B is used, the third party cannot intercept data)
I generated a secret message and encrypted it with your public key to you (send clientkeyexchange to B)
Note: I will use an encrypted method to send messages to you next!
(Process the secret message, generate the encryption key, encrypt the initialization vector and the HMAC key)
[I have finished]
B: (use your own private key to decrypt the secret message in clientkeyexchange, process the secret message, generate the encryption key, encrypt the initialization vector, and HMAC key, at this time, both parties have negotiated a set of encryption methods securely)
Note: I am also starting to send messages to you through encryption!
[I have finished]
A: [my secret is...]
B: [what other people won't hear...]
From the above process, we can see how the SSL protocol uses asymmetric cryptographic algorithms to negotiate keys, and uses keys to encrypt and transmit plaintext. There are also the following additions:
1. B uses a digital certificate to package his public key and other information and send a. A verifies B's identity. Next we will talk about how a verifies it.
2. A generates an encryption key, an encryption initialization vector, and an HMAC key, which are used by both parties to encrypt and abstract plaintext. The encryption initialization vector and HMAC key are first used to encrypt the plaintext Digest (to prevent plaintext tampering), and then the digest and plaintext are put together and transmitted with the encryption key.
3. Because only B has a private key, only B can decrypt the clientkeyexchange message and obtain the subsequent communication key.
4. In fact, in the above process, B does not verify the identity of a. If necessary, SSL is also supported. At this time, a also needs to provide its own certificate, which will not be expanded here. When setting SSL require for IIS, the default value is igore client certification.
As discussed above, digital certificates act as identity authentication and key distribution during SSL transmission. What is a digital certificate?
In short, a digital certificate is a file on the network that certifies the identity of the holder and contains a public key. On the one hand, since it is a file, it may be "forged", so the authenticity of the certificate requires a verification method; on the other hand, the validators need to agree with this authentication method.
For the first requirement, the current solution is that certificates can be issued by internationally recognized certificate organizations, which are recognized as trusted organizations and client applications that verify certificates.Program: Such as browsers and email clients, which fully trust the certificates issued by these organizations. Of course, if you want to ask these organizations to issue certificates, you have to pay "to us". Generally, when you deploy a Windows system, the client will install the root certificate of our own server, in this way, the client can also trust our certificates.
For the second requirement, client programs usually maintain a "root trusted organization list" and check whether the certificate is issued by an organization in the list when a certificate is received, if yes, the certificate is trustable; otherwise, the certificate is untrusted.
Therefore, an HTTPS site must be bound with a certificate. In any case, a certificate must always be issued by an organization, which can be an internationally recognized certificate authority, it can also be a computer installed with the Certificate Service. Whether the client can trust the certificate of this site depends first on whether the client program has imported the root certificate of the certificate issuer. This process is described as follows:
Sometimes a Certificate Authority may authorize another certificate authority to issue a certificate, so that a certificate chain appears.
When verifying the certificate, ie will give a warning from the following three aspects.
- Whether the Certificate Issuer is in the "root trusted Certificate Authority List"
- Certificate Expired?
- Whether the certificate holder is consistent with the website
In addition, the browser regularly checks the certificate revocation list published by the certificate issuer. If a certificate meets the preceding conditions, it is listed by the issuer in the Certificate Revocation List, A warning is also given. For each certificateCRL distribution pointThe field shows the URL for viewing this list. However, Windows is "insensitive" to this list, that is, Windows APIs cache this list, the new list will not be downloaded from the CRL distribution point until the set cache expires. Currently, the Windows client can be "sensitive" only by setting the validity period as small as possible (at least one day) on the certificate issuing server. The specific setting method is (winserver2003 ):
Go to administrator tools-> Certificate Authority-> right-click the "revoked certificate" directory under a certificate service-> properties:
Change the CRL release cycle to one day according to the settings in the figure.
Deploy a digital certificate-based HTTPS website in IIS
The following key steps are required to build an HTTPS website in IIS6:
- Install CA Certification Service: This step is not necessary. If you have not installed the CA certification service for that host on the network, or you need to create a new CA Certification Service, you need to install the CA Certification Service for a host. This is a built-in function of windows and is not installed by default. If it is installed, it means that this host has the ability to issue certificates, as long as the client that installs the root certificate of this host will trust the certificate issued by this host. Installation Steps in Windows Server 2003, see http://jeffyyko.blog.51cto.com/28563/140518
- Submit a certificate application to the CA Certification Service and bind the obtained certificate to the Website: see the http://jeffyyko.blog.51cto.com/28563/141322
- Require the client to import the root certificate so that the client trusts the certificate: see http://jeffyyko.blog.51cto.com/28563/142280
Certificate and key
InSSL encryption processIn this section, we know that to implement SSL encrypted communication, both parties must negotiate the key. SSL uses non-symmetric encryption for key exchange. In this process, the public key sent by the server to the client is included in the certificate. The client encrypts the self-generated key with the public key, and the server is used to decrypt the private key matching the public key. Therefore, the server saves a private key and is also bound to an HTTPS site.
A certificate bound to or not bound to a private key
From whether the certificate holder owns the private key of the certificate, there are two types of certificates: for example,The figure on the left shows the private key of the certificate on the local machine. Otherwise, the figure on the right is shown.:
As you can see, the picture on the left shows "you have the private key that matches the Certificate", but the picture on the right does not. The certificate to be bound to the HTTPS site must be in the form of a picture on the left, and the certificate to be delivered to the client should be in the form of a picture on the right instead of a picture on the left.
For the certificate in the left diagram, you can export the. pfx format containing the private key,Used to back up certificates or distribute certificatesThe steps are as follows:
Select export private key at the same time
The password entered here must be entered during the re-installation, so you need to comfirm it.
Select a file to store. The suffix is. pfx.
For common certificates, the. pfx format containing the private key cannot be exported. Only the following formats can be exported:
This article summarizes the basic concepts related to https/SSL/digital certificates, describes the implementation principle of the SSL protocol, and describes the role of digital certificates in it.
Labor fruit, reproduced please indicate the source: http://www.cnblogs.com/P_Chou/archive/2010/12/27/https-ssl-certification.html