What is encrypted by HTTPS?

They all say that HTTPS is secure. I read a lot of explanations,but I don’t know what is encrypted by HTTPS.  Can someone explain in easy terms? What I don't understand is:

1. For example, the mailbox is encrypted with HTTPS when logging in. Even if the account information is protected at the time of submission, is n’t the following request, the source code of the web page returned by the mail server, and the content of the letter all on it? Is this information encrypted at the same time? 2. I visited a certain https website. What information can the operator / hacker check? Such as access request, submitting the contents of the form, etc ... 3. Hackers hijacked to SESSIONID can easily bypass the login. Can HTTPS be used for protection?

Q1: For example, the email is encrypted with HTTPS when logging in. Even if the account information is protected during submission, are n’t the following requests, the source code of the web page returned by the mail server, and the content of the letters all on it? Is this information encrypted at the same time? To correct that, there is no such thing as HTTPS in this world. When we mentioned HTTPS, we actually mentioned two protocols at the same time, one was TLS, and the other was HTTP. They were embarrassingly enthusiastically warming up to provide security services for users to access web pages (HTTP), which is abbreviated as HTTPS. Take the webpage that everyone pulls from the website, as an example. The content of the page usually consists of N IP packets. The logical format of each IP packet is as follows:

The "HTTP" in the yellow part of the picture is completely encrypted. Only the sender and receiver of the data can decrypt it. Any third party cannot decrypt the plaintext HTTP content because there is no key information.

The sending and receiving of mail uses SMTP to send mail. In order to use TLS to protect the security of sending mail, the following logical format is usually used:

Use POP3 / IMAP to receive mail. The receiving format of secure mail is as follows:

Similarly, the above yellow parts are also encrypted. Is it possible to conclude that mail transmission must be secure? It's not, because email has a fatal weakness: Opportunistic Encryption. What is opportunistic encryption? The client usually uses "STARTTLS" to try to establish a TLS secure connection. If everything is OK, the message content is completely encrypted. If the client fails to establish a secure connection multiple times, the client will abandon the use of TLS and transmit the message in an unencrypted manner. The logical format is as follows:

Then the plain text content of the email is stolen by a third party during transmission, as long as the third party can capture the traffic. In order to prevent the two parties from establishing a TLS connection, the third party usually deliberately disrupts (packet loss) in the middle, and TLS cannot be established, so it chooses to transmit in plain text next.

Q2: I have visited an https website. What information can the operator / hacker check? Such as access request, submitting the content of the form, etc ... This question has been answered above. All the contents of the HTTP package are encrypted and secure. However, the operator can monitor your DNS query messages transmitted in plain text and plain text messages during the TLS negotiation phase. These plain text information (website domain name, SNI, digital certificate Subject / Alternative Name) will reveal which websites you are visiting, only here No more information. The above assumption is that operators or other third parties have not used "man-in-the-middle attacks". If they forged a certificate that you want to access the website, but they are verified by your browser, then this is a successful "man-in-the-middle attack". All the information you visit the website, including the form of the HTTP package, can be decrypted by them, not to mention your login password, Session ID, Access Token, Authentication Cookie.

Q3: A hacker hijacks the SESSION ID and can easily bypass the login. Can HTTPS be used for protection? The SESSION ID, Access Token, and AuthenticationCookie are equivalent to the user password, so that we can avoid entering a password each time a page is pulled, which is too cumbersome. With the above permission information to prove the user's identity, it is possible to bypass the login process without entering a password. However, the above information is encrypted by TLS. Only the client and server can decrypt it. Other third parties cannot obtain it. To obtain this confidential information, you must use the man-in-the-middle attack mentioned above to successfully hijack the TLS session, and you can get any interesting permission information. The most convenient way to conduct a successful man-in-the-middle attack is to "forge a certificate that looks legitimate to the browser". This sounds absurd, but this is what the real world looks like! What causes this absurd situation is the systemic flaw of the global public key authentication system (PKI).

The above is the news sharing from the PASSHOT. I hope it can be inspired you. If you think today' s content is not too bad, you are welcome to share it with other friends. There are more latest Linux dumps, CCNA 200-301 dumps and CCNP Written dumps waiting for you.