http&https& Certificates & Digital Signatures

HTTP protocol

HTTP is a Hypertext Transfer protocol that is used to transfer data between networks. The underlying is the TCP protocol (Transmission Control Protocol).

is a connection-oriented host to the host layer of reliable transmission, where the reliable means that data loss is minimal. TCP establishes a connection that takes 3 handshakes before it starts transmitting data. is the request-response-reconfirmation, guaranteed to send and receive.

Therefore, the transmission of data is less efficient than the UDP data message protocol (a non-connection-oriented unreliable transport protocol).

HTTP protocol transmits data, the data is transmitted in plaintext between the networks, so it is not very safe and easy to be stolen.

HTTPS protocol

is the security version of the HTTP protocol, data transmission using encryption technology, in the network transmission is not in the bare-Ben state.

Symmetric and Asymmetric encryption

There are two types of encryption, symmetric and asymmetric encryption.

Symmetric encryption, that is, the encryption and decryption of data is the same secret key, the secret key by the sender and the receiver to co-maintain. But the cost of joint maintenance is high.

Asymmetric encryption, that is, the encryption and decryption of data with a different secret key. The sender uses a public key to encrypt the data sent, and the receiver decrypts it with a secret key.

The encryption technology used by HTTPS is asymmetric encryption technology, the browser side uses the public key provided by the server to encrypt the data to the server, the server decrypts the data with the private key. After decryption, the data to be returned is encrypted with the secret key, and the browser is decrypted with the public key.

Whether the above process is still unsafe, because the public key is public, the server side of the data with the secret key encryption, transmission to the requestor, while others can intercept the data to use the public key decryption, so that the risk of data leakage can occur.

Is there any better way to solve it? Yes, the protocol between the requester and the server is a secret key (the process is not clear at this time). The requestor encrypts the key in the data and transmits it to the server, the server decrypts it with the private key, obtains the private key from the data, and then encrypts the returned data with the private key and transmits it to the requesting party. The requester decrypts the secret key from the previous protocol.

Certificates and CAs

There is one more question: How does the server send the public key to the requestor's hand? It's about certificates and CAs.

The certificate, as its name implies, can prove its identity. The CA is the authoritative authority for issuing security certificates.

Usually the server side will send the public key to CA,CA will produce a security certificate, the certificate contains the server's public key.

Certificate issuance details here first, you can simply understand that the site (server) submitted to the CA application, CA audit passed, the certificate issued to the website (server), when the user visited the website (server), the site (server) to the user.

Digital signatures and summaries

When it comes to certificates, it is necessary to mention the digital signatures and abstracts.

Digital signatures and abstracts are powerful means to ensure that certificates are valid and effective.

Abstract is the content of the transmission of the hash algorithm for its calculation to get a fixed length of the string, is a summary.

The digest is then encrypted with the CA's private key as a digital signature.

You must use the CA's public key to decrypt it.

The certificate contains the following content:

1. The certificate contains the name of the institution that issued the certificate--CA
2. Digital signature of the certificate content itself (encrypted with CA private key)
3. Certificate Holder's public key
4. The hash algorithm used in certificate signing

The CA itself has its own certificate, and the lake is called "Root certificate". This "root certificate" is used to prove the identity of a CA, which is essentially an ordinary digital certificate.

Browsers typically have root certificates built into most mainstream authoritative CAs.

The root certificate of the browser's built-in CA contains the following key elements:

1. CA's public key (very important!!!) ）

Identification Certificate:

A fully forged certificate

This is a relatively simple situation and checks the certificate:

1. Certificate issued by the agency is forged: the browser does not know, directly considered a dangerous certificate
2. The certificate authority does exist, and according to the CA name, find the corresponding built-in CA root certificate and the CA's public key.
3. Using the CA's public key to decrypt the digest of the forged certificate, it is found that the solution is not available. Considered a dangerous certificate

Certificates that have been tampered with

Assume that the agent through some way, get XX certificate, and then the public key of the certificate secretly modified to their own, and then exasperate that the user will be hooked. But it's too simple:

1. Check the certificate, according to the CA name, locate the corresponding CA root certificate, and the CA's public key.
2. Using the CA's public key, the digital signature of the certificate is decrypted to obtain the corresponding Certificate Digest AA
3. Calculates the digest BB of the current certificate according to the hash algorithm used in the certificate signature.
4. Compare AA with BB, find out about inconsistencies--and determine the danger certificate

Refer to the article of the Great God in the garden http://www.cnblogs.com/chyingp/p/https-introduction.html

http&https& Certificates & Digital Signatures