https-Thorough Learning Summary

What is the difference between SSL and SSH and Openssh,openssl?

First, the role of SSL

HTTP communications that do not use SSL/TLS are non-encrypted traffic. All information is transmitted in plaintext, bringing three major risks.

Eavesdropping risk (eavesdropping): Third parties can learn the content of the communication. Tamper risk (tampering): Third parties may modify the communication content. Impersonation risk (pretending): A third party can participate in the communication by impersonating another person.

The SSL/TLS protocol is designed to address these three risks and is expected to achieve:

All information is encrypted and third parties cannot eavesdrop. With the verification mechanism, once tampered with, the communication parties will immediately find. Equipped with identity card to prevent identity from being impersonated.

Please continue reading the specific solution.

Second, the history of SSL

  1994, Netscape company designed the SSL protocol (Secure Sockets Layer) version 1.0, but was not published. In 1995, Netscape Company issued an SSL  2  .0 version, and soon found a serious vulnerability. 1996, the SSL  3  .0 edition was introduced for large-scale applications. 1999, the Internet Standardization organization ISOC replaced Netscape Company, issued an upgraded version of SSL TLS  1  .0. In 2006 and 2008, TLS was upgraded two times for TLS  1 . Version 1 and TLS 1 . Version 2. The latest change is the 2011 TLS 1  .2 revision.  Currently, the most widely used is TLS   1.0, followed by SSL 3.0. However, the main browser has implemented the TLS 1  .2 support . tls   1.0 is typically marked as SSL 3.1,TLS 1.1 for SSL 3.2,tls 1.2 for SSL 3.3 . 

In layman's terms, TLS, SSL is a cryptographic suite that encrypts data for HTTP (or other protocols). TLS is an upgraded version of SSL. Now, referring to HTTPS, cryptographic suite basically refers to TLS.

　　Process for transmitting encryption

　　Originally, the application layer sent the data directly to TCP for transmission, and now changes to the application layer to give the data to Tls/ssl, encrypt the data, and then send to TCP for transmission .

Third, HTTP defects

HTTP is transmitted in plaintext on the network and is susceptible to man-in-the-middle attacks. It also means that any node in the middle of the listening and receiving end can know what you are transmitting. These nodes may be routers, proxies, and so on.

Encrypt the password on the sending side? Useless, although others do not know your original password is how much, but can get encrypted account password, can still log on.

Iv. how HTTPS is secure

HTTP is the application-layer protocol, which under the HTTP protocol is the transport protocol TCP. TCP is responsible for the transmission, and HTTP defines how the data is packaged.

Http–> TCP (Clear text transfer)

What's the difference between HTTPS and HTTP? In fact, there is a layer of encryption layer TLS/SSL between HTTP and TCP.

　　Process for transmitting encryption

　　Originally, the application layer sent the data directly to TCP for transmission, and now changes to the application layer to give the data to Tls/ssl, encrypt the data, and then send to TCP for transmission . :

In the original five-layer model embedded in the SSL/TSL layer, used to encrypt the data in the transmission of the service, from this graph can be seen when the data from the HTTP layer down through the SSL layer of encryption services, and then the data is combined into the TCP layer to transmit, And when the data from the other end of the TCP layer to high, the encrypted data is delivered up, the SSL layer will decrypt it, and then pay the HTTP layer.

Generally speaking, is an end-to-end process of adding and decrypting

That's what this is about. Encrypting data and then transmitting it, rather than letting the data run in plaintext on a complex and dangerous network, ensures data security to a great extent. In this case, even if the data is intercepted by the middle node, the bad people can not understand.

Five, asymmetric encryption and certificate

The basic idea of the SSL/TLS protocol is to use public key cryptography, that is, the client requests the public key to the server, then encrypts the information with the public key, and the server receives the ciphertext and decrypts it with its private key. There are two questions:

1. How is the public key acquired?

How does the browser get the public key of XX? Of course, users can go online to check, XX can also paste the public key on their home page. However, for a non-success of the tens of thousands of social networking sites, will give users a great deal of convenience, after all, most users do not know what "public key" is something.

2. Data transmission only one-way security

Public key encryption of the data, only the private key can be solved, so the user to the server account, password is safe, halfway not afraid to be intercepted. But there is a big problem: The server encrypts the data with the private key, and the public key can be undone. Plus the public key is public, the server to the user's privacy data is equivalent to the online way of a bare-Ben. (Intermediate proxy Server Gets the public key, can not hesitate to decrypt the user's data)

Resolve Issue 1:

There are two very important concepts involved: A certificate, a CA (certificate authority).

　　　　 Certificate , you can temporarily interpret it as a website ID. This ID contains a lot of information, including the public key mentioned above .

In other words, when Xiao Ming, Xiao Wang, small, and other users to visit XX, no longer need to find a server public key. When they visit a server, the server sends the certificate to the browser and tells them that it is good to encrypt the data with the public key inside.

Here's a question, where does the so-called "certificate" come from? This is the CA responsible for the next mentioned live.

　　　　CA (certification authority), there are many CAs that can issue certificates (both at home and abroad), but only a handful of CAs are considered authoritative and impartial, and the browser is considered trustworthy, and some certificate publishers ' certificates are pre-installed in our operating system . . Like VeriSign. (CA's own forgery of the certificate is not the same thing happened ...) the details of the certificate issued here first do not expand, you can first understand that the site to the CA submitted the application, CA audit passed, the certificate issued to the site, when users visit the site, the site will give the certificate to the user .

Resolve Issue 2:

As mentioned above, the data encrypted with the private key can be decrypted and restored with the public key. So, does this mean that the data passed to the user by the website is not secure?

The answer is: YES!!! (three exclamation point to emphasize three parties)

See here, you may be in the mind to think: with the use of HTTPS, data or bare-Ben, so not reliable, but rather than directly with the convenience of HTTP. But why is the industry increasingly clamoring for website HTTPS? This is obviously against our perceptual knowledge. because: Although HTTPS uses the public key encryption, but also combines other means, such as symmetric encryption, to ensure authorization, encryption transmission efficiency, security.

In summary, the whole process of simplifying encrypted communication is:

1 Xiao Ming visited xx,xx to give his own certificate to Xiaoming (actually to the browser, Xiaoming will not have the perception) 2 the browser gets xx's public key A from the certificate. 2 The browser generates a symmetric key B with only its own, encrypted with public key A, and passed to XX (in fact there is a process of negotiation, which is simplified for ease of understanding) 4 . XX is decrypted by the private key and gets the symmetric key B5. The data communication after the browser and XX is encrypted with key B Note: For each user who accesses XX, the resulting symmetric key B is theoretically different. such as Xiao Ming, Xiao Wang, small, may be generated is B1, B2, B3.

Vi. issues that may exist in the certificate

There are two possible cases of certificate illegality:

The certificate is bogus: It is not a CA-issued
The certificate has been tampered with: for example, the public key of XX website is replaced

For example: In this world there is a kind of thing called agent, so, the above Xiaoming Landing XX website may be such, Xiao Ming's Landing request to the proxy server, the proxy server and then forward the request to the authorization server.

Xiaoming –> Evil Proxy Server –> login Authorization server

Then, there are too many bad people in the world, one day, the proxy server moved a bad mind (also may be invaded), the request of Xiaoming intercepted. At the same time, an illegal certificate was returned. If the good xiaoming believed the certificate, then he ran naked again. because the certificate has the public key of the evil server, not the public key of the authorization server, Xiaoming encrypts the public key of the evil server, and the evil server can use its private key to get the contents of the packet. Of course not, so what is the mechanism to prevent such a thing from happening?

Let's take a look at what the "certificate" is, and then we can guess roughly how to prevent it.

Vii. contents of the certificate

In the formal introduction of the format of the certificate, first in a small advertising, popular science under the digital signature and digest, and then the certificate for non-in-depth introduction. Why is it? Because the digital signature, digest is the certificate anti-counterfeiting very crucial weapon.

Digital signature and summary

　　　　"Abstract" is the content of the transmission, through the hash algorithm to calculate a fixed length of the string (is not associated with the article summary), for the download to verify that the file is complete, or whether it is "identical" to the file on the server, and different plaintext digest into ciphertext, The results are always different, and the same plaintext has a consistent digest, and the "Digital Digest" is the root cause of HTTPS's ability to ensure data integrity and tamper protection.

　　　　"Signature", the digest is encrypted by the CA's private key , and the result of encryption is "digital signature". a digital signature can only verify the integrity of the data, and whether the data itself encrypts the control range that is not a digital signature .

CA's private key encryption –> digital signature

In combination with the above, we know that this digital signature can only be decrypted by the CA's public key .

Next, let's look at what the mysterious "certificate" actually contains, and then guess roughly how to prevent the illegal certificate. There are a number of things we need to focus on here:

The certificate contains the name of the institution that issued the certificate-ca

Digital signature of the certificate content itself (encrypted with CA private key)

The certificate holder's public key (corresponding to the server's private key)

hash algorithm used for certificate signing (using the same hash algorithm to verify the signature)

Reference:

Overview of the operating mechanism of SSL/TLS protocol

HTTPS Popular Literacy Stickers

Security Science: A preliminary study of HTTPS

　　

https-Thorough Learning Summary