Variety is the spice of life.
Change is the spice of life.
1. Introduction to HTTP and HTTPS
HTTPS = HTTP + SSL
Similarities
In most cases, HTTP and HTTPS are the same because they both use the same underlying protocol. As an HTTP or HTTPS client—browser—establishes a connection to the web server on a specified port. When the server receives a request, it returns a status code along with a message, which could be the requested information or an error message indicating some error. The system uses a Uniform Resource Identifier (URI) scheme, so resources can be uniquely identified. The only difference between HTTPS and HTTP is the specification of a protocol header (https); everything else is the same.
Differences
2. Understanding the Encryption Process Asymmetric Encryption
Basic Features
Both public and private keys can be used for encryption and decryption. Data encrypted with the public key must be decrypted with the private key, and data encrypted with the private key must be decrypted with the public key.
Asymmetric encryption has the characteristics of tamper-proofing, non-repudiation, and verification.
Tamper-proofing: If A encrypts information with their private key, only A’s public key can decrypt it. If the encrypted information is modified, it cannot be decrypted with A’s public key. If someone tries to imitate A and encrypt data without A’s private key, others will not be able to decrypt the modified data using A’s public key, thus ensuring tamper-proofing.
Non-repudiation: If A encrypts data with their private key, and one day A denies that the data is theirs, but others can decrypt the data with A’s public key, it proves that the data must be from A, because only the public key can decrypt data encrypted with the private key, and only A has the private key, so A cannot deny it.
Verification: B has A’s public key and sends a “hello” to A. A encrypts the “hello” with their private key and sends it back to B. B uses A’s public key to decrypt the data and finds it is the “hello” they sent to A, proving that the person on the other end is A.
All of the above is based on the assumption that only A has the private key.
Digital Signature Principle A generates an MD5 hash of the original message and encrypts the hash with their private key to obtain a signature. The signature is sent along with the original message to B, which can be in plaintext. B decrypts the signature with A’s public key to obtain the hash, and B computes the MD5 of the original message to compare whether it matches the hash. If they match, it proves that the original message was sent by A and is complete. The main function of the digital signature is to verify data integrity and authenticate the sender’s identity. However, if A directly encrypts the original message with their private key and B successfully decrypts it, it can also prove data integrity and validate the sender’s identity. Because the time to compute the MD5 of the original message + the time to encrypt the hash is less than the time to encrypt the original message
Digital Certificate Principle
The integrity checks of the data, identity verification, and measures against tampering and non-repudiation are all based on the assumption that A’s private key is not leaked and that A’s public key belongs to A. The former can be ensured by enterprises focusing on security, while the latter may involve the risk of public keys being replaced by attackers, who can impersonate enterprises and users to communicate. So what to do in such cases?
The key question here is whether the public key in your possession is trustworthy. Only if you trust that the public key you have belongs to A can you trust that the data decrypted with that public key is from A and complete. But if the public key you have does not belong to A, then trust is out of the question. To solve this problem, we need a third-party authority. A submits their public key and some hashing algorithms to this authority, which signs the combination of A’s public key and the hashing algorithms (we call this combination P) to obtain S. Together, P and S form a certificate, allowing users to obtain A’s public key from this certificate and decrypt A’s content.
You might say that this certificate could also be forged. Indeed, but the public key used to decrypt the certificate is provided by the CA to browser/operating system vendors, and is built into browsers/operating systems. There are only a few CAs worldwide, which means when you trust a browser or operating system, you also trust the public key of this decryption certificate. This trust is the foundation of the entire security system.
What Problem Does the Certificate Solve? The certificate solves the problem of confirming the identity of the other party. With the certificate, you can confirm that the entity you are communicating with is the one you expect.
3. The Encryption and Decryption Process of HTTPSHTTPS Principle Server A encrypts the webpage content with its private key and sends it along with the requested certificate to the user. After the user receives the certificate, the application (possibly a browser) retrieves the certificate and uses the operating system’s certificate manager to identify the CAs, then decrypts the certificate using the public key corresponding to the CA, obtaining the public key of server A and confirming whether this certificate was issued to this domain. If a website uses a certificate from another website, the browser will detect that the domain on the certificate does not match this website and will raise an alert. It may also be that this certificate was not issued by a trusted institution, and the browser will also raise an alert.
The Entire Process
1. The client initiates a request, sending a random number and other information, including the SSL protocol version supported by the client and the supported encryption algorithms. The random number is used to generate the session key. 2. The server generates a random number as the session key, selects the appropriate protocol and encryption algorithm based on the client’s supported protocols and algorithms, and sends the certificate to the client. 3. The client verifies the certificate, and upon successful verification, generates a symmetric key, encrypts it with the server’s public key, and sends it to the server. 4. The server decrypts to obtain the symmetric key and sends a response to confirm to the client, completing the handshake. 5. Official communication begins. When we import a certificate, we are actually importing a CA, a trusted institution, such as the certificate of 12306/BurpSuite, rather than the certificate sent to you by the server.
The basic principle of the SSH protocol is a combination of symmetric and asymmetric encryption. The handshake process of the SSH protocol is as follows:
1. The client initiates a request to establish the first connection. 2. The server generates a public key and a private key, sending the public key to the client. 3. After the client receives the public key, it encrypts a symmetric key and sends it to the server. 4. The server receives the encrypted data and decrypts it with its private key to obtain the symmetric key. 5. After that, the server uses the symmetric key to encrypt data and formally establishes a connection with the client.