The principle of SSL access

The overall interaction flow is as follows

1. Client initiates HTTPS request

This is nothing to say, is the user in the browser input an HTTPS URL, and then connect to the server port 443.

　　2. Configuration of the server side

Servers that use the HTTPS protocol must have a digital certificate that they can make themselves or apply to the organization. The difference is that the certificate you issued requires client authentication to continue access, and the certificate requested by a trusted company does not pop up on the hint page (Startssl is a good choice, with 1 years of free service). This set of certificates is actually a pair of public and private keys. If you do not understand the public key and the private key, you can imagine a key and a lock, but the whole world only you have this key, you can give the lock to others, others can use the locks to lock up important things, and then sent to you, because only you have this key, So only you can see what is locked up by this lock.

　　3. Transferring certificates

This certificate is actually the public key, but contains a lot of information, such as the certificate Authority, expiration time and so on.

　　4. Client Resolution Certificate

This part of the work is done with the client's TLS.

Client (in IE, for example, click the "Tools"--"Internet options"--"Content" tab--click "Certificates") of the certificate manager, with the "Trusted Root Certification Authorities" list. Based on this list, the client will see if the public key that unlocks the digital certificate is within the list.

The first verifies that the public key is valid, such as the authority, expiration time, and so on, and if an exception is found, a warning box pops up prompting for a problem with the certificate. If there is no problem with the certificate, then a random value is generated. The random value is then encrypted with a certificate. As it says above, lock the random values with locks so that the locked content is not visible unless you have a key.

　　5. Transmitting encrypted information

This part transmits the random value that is encrypted with the certificate, the purpose is to let the server to get this random value, the client and the service side of the communication can be encrypted by this random value to decrypt.

　　6. Service Segment Decryption Information

After the server is decrypted with the private key, the client passes the random value (the private key), and then the content is symmetric encrypted by this value (explanation: Formal interaction data using symmetric encryption, asymmetric encryption performance poor). The so-called symmetric encryption is that the information and the private key through an algorithm mixed together, so that unless the private key is known, or can not get the content, and just the client and the server know the private key, so long as the encryption algorithm is sturdy enough, the private key is complex enough, the data is safe enough.

　　7. Transfer of encrypted information

This part of the information is the service segment with the private key encrypted after the information, can be restored on the client.

　　8. Client Decryption Information

The client uses the previously generated private key to decrypt the information passed by the service segment and obtains the decrypted content. The process the third party, even if he hears the data, is helpless.

A few key background concepts

1) Digital signatures are primarily intended to prove the identity of the sender. The scenario is reproduced as follows :

Alice and Bob interchange the public key.
Alice digitally signs the txt file with her private key.
Alice encrypts the TXT file with Bob's public key.
Alice passes the digitally signed and encrypted file txt to Bob via email or other transmission channels, such as QQ, MSN, etc.
Bob decrypts the file encrypted with Bob's own private key after receiving the signed and encrypted message, and then decrypts the digital signature with Alice's public key.
Similarly, in this process Cinda can also get Bob, Alice's public key and signed and encrypted bid file TXT. Unable to open the message due to the absence of Bob's private key. And since Alice has digitally signed the file with her private key before sending it, Bob will be able to confirm that he received the message from Alice after receiving the message, and that it cannot be another user. Imagine if a cinda illegal user wants to change the message, posing as Alice to Bob, because Cinda does not have Alice's private key, it is impossible to digitally sign with another user's private key to decrypt the digital signature with Alice's public key.
Here to pay attention to file encryption and digital signature sequence, must be signed and then encrypted, so encryption technology can also guarantee the digital signature in the message. If the first encryption, and then signed, illegal users can obtain the message after the public key to crack the digital signature, because the public key can be public, it is easy to be a few people with ulterior motives to get. The signature is likely to be replaced after the digital signature is cracked. Of course, the contents of the message cannot be opened without the recipient's private key.

2) The Origin of the certificate--here is also a scene to show

Bob has two keys, one is the public key and the other is the private key.

Bob gave the public key to his friends----patty, Doug, Susan----each.

Susan is going to write a confidential letter to Bob. After she writes it, she encrypts it with Bob's public key, which can achieve a confidential effect.

After Bob received the letter, he decrypted it with the private key and saw the contents of the letter. It is to be stressed that as long as Bob's private key is not disclosed, this letter is safe, even if it falls in the hands of others, can not be decrypted.

Bob replied to Susan and decided to use a "digital signature". When he finishes, he uses a Hash function to generate a digest of the Letter (Digest).

Bob then uses the private key to encrypt the digest and generate a "digital signature" (signature).

Bob attached the signature to Susan under the letter.

After Susan received the letter, she took down the digital signature and decrypted it with Bob's public key to get a summary of the letter. It was proved that the letter was indeed made by Bob.

Susan then uses the Hash function on the letter itself to compare the resulting results with the summaries obtained in the previous step. If the two are consistent, it proves that the letter has not been modified.

A complicated situation arose. Doug tried to cheat Susan by secretly using Susan's computer and swapping Bob's public key with her public key. At this point, Susan actually owned Doug's public key, but thought it was Bob.
's public key. So Doug could impersonate Bob, make a "digital signature" of his private key, write to Susan, and let Susan decrypt it with a fake Bob's public key.

Later, Susan felt something wrong and found herself unable to determine whether the public key really belonged to Bob. She thought of a way to ask Bob to find the "Certificate Center" (certificate Authority, referred to as CA), for the public
Key to be certified. The certificate center uses its own private key to encrypt Bob's public key and some related information to generate a "digital certificate" (Certificate).

After Bob gets the digital certificate, he can rest assured. Later to write to Susan, as long as the signature, accompanied by a digital certificate on the line.

After Susan received the letter, the CA's public key to unlock the digital certificate, you can get Bob's real public key, and then can prove that "digital signature" is really Bob signed.

Attachment: A more detailed implementation of stream parsing

Http://www.fenesky.com/blog/2014/07/19/how-https-works.html

The principle of SSL access