In order to grab masks, I actually figured out the principle of https

During the epidemic, masks are hard to get. I can't go out without a mask. I saw a software on 52hacker that can check the remaining masks.

The software looks like this:

I have been using this software to snatch it for a long time, but I didn't get it. So I wondered if I could get the source of the mask information of this software. Since I am a novice web dog, I don't know how to reverse it. I used wireshark to capture the request to see how he did it.

According to the prompt on his software, it requests data every 5 seconds. Since the data captured by wireshark is all the traffic of this network card, it is more difficult to analyze. Open wireshark, capture the packet for a while and then stop. It is not necessary to stop for too long. Otherwise, there will be many other traffic requests.

We can see that most of the packets are sent to the IP address 27.124.36.8. Damn, it's https. How can we decrypt it without the key? Well, although we can't decrypt the data packet and don't know what parameters it uses to send it, we can see the server's certificate information.

Found an app.tonystark.io

We have only found the address of the server, but we still don’t know how to request the specific mask information.

From the above wireshark traffic, we can know that the communication between the program and the server is connected using https. Before decryption, let's learn the principle of https.

1. Learning the principles of Https

Compared with http, https only has one more layer of tls:

1. Why do we need to add this TLS security layer?

This is because the original HTTP had the following three problems:

• Data is running naked. Data is transmitted in plain text
• Unable to verify the identities of both parties in the communication
• Cannot prevent data from being tampered with

Let's solve the first problem first. How to encrypt data?

• Cryptography encryption methods only include symmetric encryption and asymmetric encryption
• Symmetric cipher: Encryption that uses the same key for both encryption and decryption.

From the flowchart, we can see that this encryption method requires the key to be prepared in advance when the two parties communicate. However, the process of transmitting the key between the server and the browser is monitored by people, which is equivalent to plain text transmission. If the key is saved locally in advance and retrieved when a connection is needed, then the browser needs to pre-store the keys of all HTTPS websites in the world, which is obviously unrealistic.

Asymmetric cryptography: public key encryption, private key decryption

This encryption method, also known as asymmetric key encryption, uses a pair of keys for encryption and decryption, namely a public key and a private key. The public key is available to everyone. After the sender obtains the receiver's public key, it can use the public key to encrypt, and the receiver uses the private key to decrypt after receiving the communication content. Because the public key encrypts and the private key decrypts, even if the public key in transmission is monitored, the transmitted traffic cannot be decrypted. However, only the transmission link from the client to the server guarantees the security of the transmission, so how to ensure the security of the link from the server to the client?

HTTPS uses a hybrid encryption mechanism that uses public key encryption to transmit symmetric keys, and then uses symmetric key encryption for communication.

First, the Client initiates a connection to the Server and sends a ClientHello. This Hello message identifies the highest supported TLS version, supported cipher suites, Session information, and compression algorithm of the Client.

After receiving the request from the Client, the Server will send and negotiate to determine the Client's cipher suite, and will also send the Server Certificate information and server public key.

After receiving ServerHello, the Client will verify whether the Server's certificate information is legal. If it is legal, it will generate a random code (this step involves TLS key calculation, which is too complicated. If you are interested, you can check it yourself) as a symmetric key encryption key, and encrypt the random code using the received server public key.

The general flow chart is like this. The processes for different TLS versions are very different.

Next, I use wireshark to capture a csdn https connection request.

First, look at ClientHello, TLS version information, Session, and supported cipher suites

In the subsequent ServerHello, it is not difficult to find that the encryption method TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 is selected

As you can see, ServerHello is followed by a data packet with three keywords: Certificate, Certificate Status, and Server Key Exchange.

Certificate is the certificate information:

From the data packet, we can see that it is issued by www.digicert.com and signed with sha256WithRSAEncryption

Certificate Status is the status information of the certificate, including the validity period of the certificate.

Finally, Server Key Exchange is the Server's Public Key.

Since the negotiated key negotiation algorithm is ECDHE, the server sends the ECDH parameters and public key to the client. The ECDH curve here is secp256r1, and the public key is 047b36092eb10...............

This is the end of ServerHello.

Because it is an ECDHE negotiation algorithm, the Client needs to send the ECC DH public key, which also has three keywords:

Client Key Exchange, needless to say, is the ECCDH public key sent by the client, and its value is 04acb6e.....

The ChangeCipherSpec message structure is very simple. This message is sent to tell the server that the client can use the TLS record layer protocol for cryptographic protection. The first cryptographically protected message is the Finished message.

The next two packets are flow control packets. They help ensure that only data that the recipient needs to use is transmitted. After that, a new session is established, and the server returns ChangeCipherSpec and finish. There is also a part of the TLS session reuse mechanism here. Please read it yourself.

So far, the entire https connection has been established.

Now we have solved the process of how HTTPS encrypts data.

2. Now let’s look at the second question: How to verify the identities of both parties in the communication?

In the above wireshark traffic analysis, we can see a Certificate. Yes, HTTPS uses certificates to authenticate the communicating parties.

The digital certificate authority (CA) is a third-party organization that both the client and the server can trust. The server operator submits an application for a public key to the CA. After the CA verifies the identity of the applicant, it will digitally sign the public key, distribute the signed public key, and bind the public key to the public key certificate.

When conducting HTTPS communication, the server will send the certificate to the client. After the client obtains the public key, it will first perform verification. If the verification is successful, communication can begin.

For example

Steps 1, 2, 3, and 4 in the above figure do not need to be requested every time. Steps 1, 2, and 3 are only required when registering a new public key. Step 4 is only required the first time you need to use the public key password. After saving it to your computer, you do not need to request the public key every time.

Before using HTTPS, a website needs to apply to the "CA organization" for a digital certificate. The digital certificate contains information such as the certificate holder and the certificate holder's public key. The server transmits the certificate to the browser, and the browser takes the public key from the certificate. The certificate is like an ID card, which can prove that "the public key corresponds to the website."

2. So how do you verify the integrity of the data? For example:

A remits 1 million yuan to B. If an attacker attacks and tampers with the message, it may become that A remits 10 million yuan to the attacker. Here we focus on the remittance message. How to ensure two issues: the "integrity" and "authentication" of the message.

At this time, digital signature technology can be used, which is equivalent to stamping in real life. Digital signature can identify tampering, disguise, and prevent denial.

Asymmetric keys are public key encryption and private key decryption. Digital signatures are public key decryption and private key encryption.

In order to prevent the message from being tampered with or forged, the digital signature technology is used. The server uses the private key to encrypt the hash of the message, and then sends the hash and signature to the client. The client then uses the public key to decrypt and compare the transmitted hash to see if they are consistent. If they are consistent, it proves that the message has not been tampered with or forged.

We all know that a fingerprint is a unique thing for a person, and it can be used to find the only person corresponding to him. The fingerprint of a message is the one-way hash function (Hash) in cryptography. Each message has its corresponding Hash, and if the message changes, its hash will also change accordingly.

The integrity of a message is also called its consistency, which can be determined by using the message fingerprint. By comparing the hash value of a one-way hash function, we can determine the integrity of the message and whether it has been tampered with.

Message authentication refers to whether the message comes from the correct sender. If it is confirmed that the remittance request is indeed from A, it is equivalent to authenticating the message, which means that the message is not disguised.

Well, Https has probably completed the three missions that Http has never completed. I believe that after reading this, you will also have a general understanding of how Https achieves the security it claims.

3. How can I decrypt the traffic?

Most of the solutions found on the Internet are two: one is to import the RSA private key into Wireshark, and the other is to configure SSLKEYLOGFILE.

The first method: Import the RSA private key into Wireshark

Implementation process:

1. Get Baidu's server certificate

Use fiddler's man-in-the-middle proxy technology to get the server certificate containing the private key.

• Open fiddler and enable https proxy service
• Use a browser configured with fiddler proxy to access Baidu
• Run "certmgr.msc" to open the certificate manager
• Find the *.baidu.com certificate in the Personal/Certificates directory, right-click All Tasks-Export

2. Remove the private key from the certificate

Use openssl to retrieve the private key.

1) Convert pfx certificate to pem certificate

Command line:

 openssl pkcs12 -in < pfx certificate path > -nodes -out < output pem certificate path (.pem) >  

2) Get the private key from the pem certificate

Command line:

 openssl rsa -in < pem certificate path > -out < output private key file path (.key) >  

3) Click Edit -> Preferences -> Protocols -> SSL (some versions only have TLS), and import the RSA key:

Import the server certificate:

After clicking OK, Wireshark will decrypt the captured message:

This method is only useful for key exchange using RSA. Once you know the RSA key, you can import it into Wireshark to decrypt the traffic. However, most HTTPS websites currently use DH key exchange. Here we explain the difference between RSA and DH. Let's look at the two processes first.

ssl_handshake_rsa:

• Client Hello, including protocol version, client random, and cipher suite list
• Server Hello, the server "hello" message contains the server random, the server selected cipher suite and the server's certificate
• Client Key Exchange After the client verifies the certificate, the client creates a random pre-master secret. It is encrypted with the public key and sent to the server. After receiving the encrypted pre-master secret, the server will use the private key to decrypt it. Therefore, if we know the private key, we can import it into Wireshark and extract the pre-master secret to decrypt the traffic.

ssl_handshake_diffie_hellman:

• Client Hello, including protocol version, client random, and cipher suite list
• Server Hello, the server "hello" message contains the server random, the server selected cipher suite and the server's certificate
• Server Key Exchange follows Server Hello. To initiate the DH exchange, the server sends the Diffie-Hellman parameters and signature.
• Client Key Exchange The client verifies the server's certificate and then sends the DH parameters to the server.

Note: There is no key exchange in the whole process, and the client and server can calculate the pre-master secret through DH parameters.

In this case, since the Premaster Secret does not need to be exchanged, the middleman cannot obtain the Premaster Secret and Master Secret even if he has the private key. In other words, Wireshark cannot decrypt the encrypted traffic that uses ECDHE for key exchange by configuring RSA Private Key.

The second SSLKEYLOGFILE

Add the SSLKEYLOGFILE variable to the system environment variable and select the export directory

Both Firefox and Chrome will save the Premaster Secret or Master Secret generated by each HTTPS connection when the SSLKEYLOGFILE file path exists in the system environment variable. With this file, Wireshark can easily decrypt HTTPS traffic.

Then open wireshark, press ctrl+shift+P, select TLS protocol in Protocols, and import it.

To remove encryption

But these two methods are useless to me. This is a program connecting to a server, and I can't get the Premaster Secret or Master Secret generated by the HTTPS connection. And the Secret is random every time I connect.

Now let's talk about another one. Everyone who studies security knows that when Burp captures https traffic, it needs to trust Burp's certificate. So have you ever thought about why this is?

Packet capture tools such as burp, Charles, and fildder mainly use the idea of ​​man-in-the-middle attacks.

Normal communication only involves Client and Server.

In a man-in-the-middle attack, an intermediary is added. After the client trusts the certificate of the intermediary, it will communicate with the intermediary. Then the intermediary will receive the request sent by the client and pretend to be the client to make a request to the server. It will monitor the communication between the two parties.

So as long as the client trusts the burp certificate, the client will establish an HTTPS connection with burp. After receiving the client's request, burp will establish a connection with the server to forge client communication.

I guess you may have a question in your mind after seeing this: Doesn’t Https verify the identities of both parties in the communication?

It is like this. Https has single-end authentication and double-end authentication

Image source: https://www.jianshu.com/p/a2a7ddce7075

Generally, Web applications use SSL one-way authentication. The reason is simple. There are a wide number of users, and there is no need to verify the user identity at the communication layer. Generally, the application logic layer is used to ensure the user's legal login. However, if it is an enterprise application connection, the situation is different. It may require the client to authenticate the identity (relatively speaking). In this case, SSL two-way authentication is required.

• The client sends information such as the SSL protocol version number, encryption algorithm type, and random number to the server.
• The server returns the SSL protocol version number, encryption algorithm type, random number and other information to the client, and also returns the server's certificate, i.e. the public key certificate
• The client uses the information returned by the server to verify the legitimacy of the server, including: whether the certificate is expired, whether the CA that issued the server certificate is reliable, whether the returned public key can correctly decrypt the digital signature in the returned certificate, and whether the domain name on the server certificate matches the actual domain name of the server. If the verification is passed, the communication will continue, otherwise, the communication will be terminated.
• The client sends the symmetric encryption schemes it can support to the server for the server to choose
• The server selects the encryption method with the highest encryption level from the encryption schemes provided by the client.
• The server returns the selected encryption scheme to the client in plain text
• After the client receives the encryption method returned by the server, it uses the encryption method to generate a random code, which is used as the key for symmetric encryption during the communication process. It uses the public key returned by the server to encrypt the random code and sends it to the server.
• After receiving the encrypted information returned by the client, the server uses its own private key to decrypt and obtain the symmetric encryption key. In the following session, the server and client will use this password for symmetric encryption to ensure the security of information during communication.

• The client sends information such as the SSL protocol version number, encryption algorithm type, and random number to the server.
• The server returns the SSL protocol version number, encryption algorithm type, random number and other information to the client, and also returns the server's certificate, i.e. the public key certificate
• The client uses the information returned by the server to verify the legitimacy of the server, including: whether the certificate is expired, whether the CA that issued the server certificate is reliable, whether the returned public key can correctly decrypt the digital signature in the returned certificate, and whether the domain name on the server certificate matches the actual domain name of the server. If the verification is successful, the communication will continue, otherwise, the communication will be terminated.
• The server asks the client to send its certificate, and the client sends its certificate to the server.
• Verify the client's certificate. After verification, the client's public key will be obtained.
• The client sends the symmetric encryption schemes it can support to the server for the server to choose
• The server selects the encryption method with the highest encryption level among the encryption schemes provided by the client.
• The encryption scheme is encrypted using the previously obtained public key and returned to the client
• After receiving the encryption scheme ciphertext returned by the server, the client uses its own private key to decrypt it and obtain the specific encryption method. Then, it generates a random code for the encryption method, which is used as the key in the encryption process. It is encrypted with the public key obtained from the server certificate before and sent to the server.
• After receiving the message sent by the client, the server uses its own private key to decrypt it and obtain the symmetric encryption key. In the next session, the server and client will use the password for symmetric encryption to ensure the security of information during communication.

The tool is: Burp+Proxiey

Set the rules

Received what you wanted:

Summarize

It’s not easy to get a mask. I managed to understand the principle of HTTPS. There is no end to learning. I hope it will be helpful to everyone.