Symmetric key encryption in HTTPS, public key encryption, digital certificate key
We call unencrypted content plaintext, and the encrypted content is called ciphertext.
In short, to encrypt a piece of plaintext, you can enter this content into an encryption function, output ciphertext. However, this simple encryption method has been stolen into the cryptographic function to crack the danger of clear text, and cryptographic functions are generally complex, once stolen replacement cost is higher.
So people came up with a way to add a parameter to the cryptographic function, which only the communication parties know that no parameters will be able to decrypt the password correctly. This parameter is called a key. For the same cryptographic function, the key value of the different encryption method is also different, the resulting ciphertext is different. This increases the security of the encryption system, and the cost of replacing the key after the key is stolen is much lower. The common scenario is that the cryptographic functions are public and the user needs to save only their own keys.
Symmetric key Encryption
Symmetric key encryption is the same key value that is used for encryption and decryption.
Popular symmetric key cryptography includes:
A symmetric key requires a shared key between the two sides of the communication. For Internet communication, different communication parties need different symmetric keys, if n users need to communicate with each other, the total number of keys required is n (N-1).
Public key Encryption
Symmetric key encryption exists the disadvantage of requiring too many key numbers and inconvenient delivery keys, so people study asymmetric key encryption technology, that is, encryption and decryption of the key does not need the same. One common form of this is called Public key encryption.
Public key encryption divides the encryption and decryption key at one end of the communication into two, where the encryption key can be published publicly, that is, anyone can use the encryption key for plaintext encryption, but to decrypt the plaintext can only rely on the end of the private decryption key. This resolves the disadvantage of symmetric key encryption. The encryption key that is exposed is called the public key, and the private decryption key is called the private key.
To ensure the availability of public key encryption, you must ensure that the private key cannot be computed in the following situations:
- have a public key;
- A section of ciphertext;
- A plaintext and ciphertext encrypted with a public key;
Popular public Key cryptography includes:
Public key Encryption Although more simple and secure, but its encryption algorithm is slow, so the general mixed use of public key encryption and symmetric key encryption use, that is, through public key encryption to obtain a symmetric key encryption key, and then through the symmetric key encryption transfer data. This is explained in the following article.
Digital signatures
Symmetric key encryption and public key encryption are all techniques for encrypting messages. But the encryption can do more than that, you can also use cryptographic algorithms to prove who wrote the message and did not be tampered with in the middle. Digital signatures are the technology.
A digital signature is a special cryptographic check code attached to a message. It uses a private key encryption to generate a check code, in addition to the sender of other people can not regenerate the corresponding check code, so that the identity of the message and no one in the middle of tampering.
Digital signatures are usually generated through public key technology, but in the opposite way. The sender first generates a message digest, uses the signature function and enters the private key as the parameter, encrypts the paper Digest, generates the signature and sends it along with the message. The receiver decrypts the signature by attaching the signature function inverse of the public key parameter, and compares it with the generated digest, and if the result is consistent, the message is correct.
RSA encryption systems can be used for public key encryption and digital signatures. The RSA encryption system uses the decoding function D as the signature function, and the encoded function e as the solution signature function.
Digital certificates
A digital certificate is a proof of identity on the network. Generally include the following:
- Certificate format version number
- Certificate serial number;
- Certificate Signature Algorithm;
- Certificate issuer;
- Valid
- Object name;
- The object exposes the key;
- The digital signature of the issuer of the certificate;
Where the issuer's digital signature is through the remainder of the digital certificate Digest is computed by the certificate signature algorithm and the certificate issuer's private key to verify the authenticity of the digital certificate.
Anyone can generate a digital certificate on their own, but only digital certificates generated by trusted organizations (CAS) will be trusted by the browser by default.
HTTPS
HTTPS is the security protocol that encrypts messages before HTTP messages are sent to TCP. Use port 443 for communication.
Normal HTTP has the following four layers:
- Application Layer HTTP
- Transport Layer TCP
- Network Layer IP
- Data Link Layer
HTTPS has one more layer of security:
- Application Layer HTTP
- Security Layer SSL/TLS
- Transport Layer TCP
- Network Layer IP
- Data Link Layer
Certificate key authentication is verified at the security layer. The common SSL/TLS programming implementation Library is OpenSSL.
Detailed digital certificate verification process
About the process of verifying the digital certificate of Web site in the browser the information on the web is generally not very clear. After reviewing a lot of information, we finally got to know this part.
The certificate issued to the website under CA is a certificate chain, that is, a layer of certificates, starting from the root certificate, to the subordinate CA, layer after layer, the last layer is the website certificate.
After the browser receives the certificate sent by the server, it needs to verify its authenticity. The signature of the certificate is generated by the signature algorithm and the private key of the superior CA , and not many articles are simply generated by the CA private key. The browser needs to use the parent CA's public key to decrypt the signature and compare it to the generated fingerprint, so the question is, where does the parent's public key come from?
The answer is that the public key comes from a certificate chain that is in the parent CA's certificate in clear text. A single X509v3 certificate consists of the following parts:
The X.509v3 certificate consists of three parts:
- Tbscertificate (to be signed certificate), the certificate to be signed.
- Signaturealgorithm, Signature Algorithm.
- SignatureValue, the signature value.
The Tbscertificate also contains 10 items that are transmitted in clear text during the HTTPS handshake:
- Version number.
- Serial number, serial numbers.
- Signature algorithm ID, Signature algorithm ID.
- Issuer Name, issuer.
- Validity period, effective time.
- Subject name, certificate principal name.
- Subject public key info, which contains the public key and public key values for the certificate body.
- Issuer unique Identifier (optional), publisher-only ID.
- Subject unique Identifier (optional), principal unique ID.
- Extensions (optional), extension.
The certificate chain consists of a layer of certificates, and the public key in the other layer certificate is used to decrypt the underlying certificate fingerprint signature, except that the public key of the lowest-level website certificate is to encrypt the message to the user. The root certificate at the highest level is self-signed , that is, it is issued to itself, so its public key is not only used to decrypt the underlying signature, but also to decrypt its own signature.
If the task of verifying that the certificate is true is complete, then how reliable is the certificate validated? In a word, as long as the root certificate is reliable, the entire certificate chain is reliable, and the root certificate is reliable to see whether the root certificate is in the operating system or browser built-in trusted root certificate, it is credible.
HTTPS Actual validation process
This part of the content is mainly referred to the "SSL/TLS protocol operating mechanism overview" http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html
The actual HTTPS verification process is as follows:
ClientHello Stage
- Supported protocol versions, such as TLS version 1.0;
- A client-generated random number that is later used to generate a "conversation key";
- Supported encryption methods, such as RSA public key cryptography;
- Supported compression methods;
Serverhello Stage
- Confirm the version of the encrypted communication protocol used;
- A random number generated by a server that is later used to generate a "conversation key";
- Confirm the encryption method used, such as RSA public key encryption;
- server certificate;
Requests that require validation of a user's certificate will also include a request for a user to provide a certificate.
Client response
After the client receives the response, it first validates the server certificate:
- Whether it is issued by a trusted CA;
- Whether the domain name in the certificate is consistent with the actual domain name;
- Whether it is within the validity period;
If the certificate is not a problem, the client responds to the following:
- A random number (Pre-master key). The random number is encrypted with the server public key to prevent eavesdropping;
- Code change notification, indicating that subsequent information will be sent with mutually agreed encryption method and key;
- The client handshake end notification indicates that the client's handshake phase has ended. This item is also the hash value of all the content sent in the front, which is used for server verification;
Both sides of the communication now have these three random numbers. An agreed encryption method generates an identical session key Sessionsecret based on three random numbers for subsequent symmetric encryption.
Server response
After the server receives the response, it calculates the Sessionsecret and sends the following to the client:
- Code change notification, indicating that subsequent information will be sent with mutually agreed encryption method and key;
- The server handshake end notification indicates that the server's handshake phase has ended. This is also the hash value of all the content that was previously sent, which is used by the client to verify
This is the end of the HTTPS handshake process, followed by the sending of symmetric encrypted messages over HTTP.
Resources:
- A book on the HTTP authoritative guide
- The principle of digital certificate http://www.cnblogs.com/JeffreySun/archive/2010/06/24/1627247.html
- What is a digital signature? "Http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html
- "Authentication mechanism in HTTPS communication" HTTPS://CNODEJS.ORG/TOPIC/56EB698EC95E8F992473C5A3
- SSL certificate must know: Digital certificate and CA basic knowledge http://liuqunying.blog.51cto.com/3984207/1664246
- Overview of the operating mechanism of the SSL/TLS protocol http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html
- The HTTPS practice of large Web sites (i)--HTTPS protocols and principles http://op.baidu.com/2015/04/https-s01a01/
- "Understanding HTTPS Principle, SSL/TLS protocol" https://hacpai.com/article/1447920990604
- "HTTPS certificate Generation Principle and Deployment Details" http://www.barretlee.com/blog/2015/10/05/how-to-build-a-https-server/
- Study notes on HTTPS principles http://www.kevenwu.com/blogs/14/
Symmetric key encryption in HTTPS, public key encryption, digital certificate