In simple terms, SSL means that both parties in communication negotiate a key for symmetric encryption through asymmetric encryption.
Digital certificate and CA
Using a combination of symmetric encryption, asymmetric encryption and digest algorithms, we have achieved the four major features of security. Is it perfect?
No, there is also a "public key trust" issue here.
Because anyone can publish the public key, we still lack the means to prevent the *** from forging the public key. In other words, how to judge that the public key is yours or the public key of a treasure?
http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html
1. zfb generates its own public key, private key, and public key to download on the website 2. Xiaoming downloaded the zfb public key, and use this public key to encrypt a piece of information data1 (generate order request) as data1_enc and send it to zfb 3.zfb Go to the encrypted information data1_enc and use your own private key to unlock the relevant data for data1 and calculate the business data data2 to be processed (notify Xiaoming of the payment of this order), and use the hash algorithm to generate a digest for data2 data2_digest to encrypt the digest with your own private key Encrypted as data2_digest_enc is the digital signature signature and then sends data2+data2_digest_enc to Xiaoming 4. Xiaoming receives data2+data2_digest_enc, decrypts data2_digest_enc with zfb's public key to data2_digest, which proves that the information is sent to him by zfb and then to data2 The result obtained by using the hash function is compared with data2_disget. If 1 is correct, the information is complete and has not been tampered with ---------------------------- --------------------------------- But one day Xiao Ming was secretly used by Xiao Hui the zfb public key he had obtained before Replaced with Xiaohui’s own public key (it is also possible that Xiaohui replaced the Alipay website with his own public key, and then Xiaoming went to download the public key of Xiaohui instead of zfb's) Xiaoming here Someone (actually Xiaohui) placed an order and encrypted the data with Xiaohui’s public key and sent it to zfb. Of course, Alipay could not unlock it with his private key. Xiao Hui obtained the data Xiao Ming sent to Alipay on the way, and decrypted it with his private key. In the case of no deduction, Xiao Ming was notified that the payment was successful. After Xiao Ming delivered the goods, he found that the account did not receive the money for the order ---------------------- -------------------------------------------------- - Xiao Ming after unusual and decided to find a trusted authority CA, let zfb with his public key to the CA for him to make public key authentication CA CA with his public key and private key to zfb some of his other encrypted information generated digital After the certificate , when zfb sends a message to Xiaoming, it will be sent along with his digital certificate. After Xiaoming receives the message, he uses the CA's public key to unlock the information in the certificate to obtain the real public key of zfb. The only problem now is that the CA is trusted.
We can use a method similar to key exchange to solve the public key authentication problem, and use another private key to sign the public key. Obviously, this will fall into "infinite recursion". But this time there is really "no trick". To end this "definite loop", we must introduce "external force", find a recognized and trusted third party, and let it be the "starting point of trust and the end of recursion" to construct The chain of trust for the public key. This "third party" is what we often call CA (Certificate Authority)
It is like the Public Security Bureau, Ministry of Education, and Notary Center in the online world. It has a high degree of credibility. It signs each public key and uses its own reputation to ensure that the public key cannot be forged and is credible.
The CA's signature certification of the public key is also formatted. It is not simply a matter of binding the public key to the identity of the holder, but also includes the serial number, purpose, issuer, valid time, etc., and type these into A package is then signed to fully prove the various information associated with the public key, forming a "digital certificate" (Certificate) .
There are only a few well-known CAs in the world, such as DigiCert, VeriSign, Entrust, Let's Encrypt, etc. The certificates issued by them are divided into DV, OV, and EV. The difference lies in the degree of credibility. DV is the lowest, it's just the credibility of the domain name level, who doesn't know behind it. EV is the highest. After strict verification by law and audit, it can prove the identity of the website owner (the name of the company will be displayed in the browser address bar, such as Apple and GitHub websites).
But how does CA prove itself? This is still a question of the chain of trust.
A smaller CA can be signed by a larger CA, but at the end of the chain, the Root CA can only prove itself. This is called a "Self-Signed Certificate" or "Root Certificate" (Root CA). Certificate). You must believe, otherwise the entire certificate trust chain will not go down
With this certificate system, the operating system and browser have built-in the root certificates of major CAs. As long as the server sends its certificate when surfing the Internet, the signature in the certificate can be verified, following the certificate chain (Certificate Chain). After verifying layer by layer, until the root certificate is found, it can be determined that the certificate is trustworthy, so that the public key inside is also trustworthy.
The certificate used in the experimental environment is a self-signed certificate of "Yeluzi" (issued by the OpenSSL command line on Linux), which will definitely not be trusted by the browser, so when accessed with Chrome, it will be displayed in red and marked as Not safe. But as long as you install it into the root certificate store of the system and let it be the root of the chain of trust, there will be no danger warning.
Weaknesses of the certification system
Although the certificate system (PKI, Public Key Infrastructure) is the current security infrastructure of the entire online world, absolute security does not exist. It also has weaknesses and is the key word "trust."
If the CA makes a mistake or is deceived and issues the wrong certificate, although the certificate is real, the website it represents is fake.
There is a more dangerous situation. The CA is compromised by VPN, or the CA is malicious, because it (the root certificate) is the source of trust, and all the certificates in the entire trust chain are not trusted.
These two things are not "sensational", and both have actually happened. Therefore, some patches need to be applied to the certificate system.
For the first type, CRL (Certificate revocation list) and OCSP (Online Certificate Status Protocol) were developed to revoke problematic certificates in a timely manner.
For the second type, because there are too many certificates involved, the operating system or browser can only be "ruthless" from the root, revoke the trust of the CA, and put it on the "blacklist", so that all the certificates issued by it will be Considered unsafe
- The digest algorithm is used to achieve completeness and can generate a unique "fingerprint" for the data. The commonly used algorithm is SHA-2
- The digital signature is the encryption of the private key to the digest, which can be verified after decryption by the public key to realize identity authentication and non-repudiation
- The distribution of the public key requires the use of a digital certificate, which must be verified by the chain of trust of the CA, otherwise it is untrusted
- As the source of the chain of trust, the CA is sometimes untrustworthy. The solutions include CRL, OCSP, and termination of trust.
Confidentiality : It is solved by hybrid encryption, asymmetric encryption realizes symmetric encryption key transmission, and symmetric encryption realizes content encryption.
Completeness : Rely on the digest algorithm to solve.
Identity authentication : It is solved by digital certificates. Because of the trust of the CA organization, the digital certificate becomes a complete chain of trust, so as to prove the true identity of the other party through the digital certificate, but note that the true identity may also be a bad person. Therefore, with CRL, OCSP, and termination of trust.
Undeniable : Rely on digital signature to solve, the content digest algorithm gets the digest, the private key encrypts the digest, the other party uses the corresponding public key to decrypt, obtains the digest, and then compares with the original text digest provided by the server you got, consistent indicating that this content is provided by the original server , The identity of the server is described by the certificate.
Certificate verification
The server returns the certificate chain (not including the root certificate, which is preset in the browser),
and then the browser can use the trusted root certificate (root public key) to parse the root certificate of the certificate chain to obtain the public key + digest of the first-level certificate Verify the signature,
then use the public key of the primary certificate to decrypt the primary certificate to obtain the public key and digest of the secondary certificate for verification,
and then use the public key of the secondary certificate to decrypt the secondary certificate to obtain the server’s public key and digest for verification , The verification process is over
Digital signatures and digital certificates are only used in the handshake phase of TSL/SSL, mainly to ensure that the server's public key can be correctly transmitted to the browser (not being disguised by the middleman to send a fake public key)
The specific process is probably:
- 1. The server goes to the CA to apply for a certificate. The certificate contains information such as the public key to be sent to the client, the issuer, and the expiration time.
If you simply send the certificate to the browser in this way, the middleman can easily modify it into your own public key. The subsequent communication is insecure,
so certain encryption methods are needed. The method here is to use digital signatures: use the information in the certificate After the digest algorithm calculates the digest, it is encrypted with the CA's secret key to generate a digital signature
- 2. The server sends the digital certificate and digital signature together to the browser. Because of the digital signature, the digital certificate cannot be modified by the middleman (the digital signature generated after modification is inconsistent with the original digital signature). After the browser gets the digital certificate , Go to the local trusted organization to find the corresponding organization, use its public key to decrypt the digital signature, and verify whether the certificate has been modified.
This step ensures that the public key obtained by the browser must be correct. - 3. After the public key is correctly transmitted to the browser, the next step is to negotiate the symmetric encryption key, and then communicate, etc.