Reference: http://blog.csdn.net/xoopx/article/details/51577039
First, fiddler intercepts the HTTPS request sent by the client browser to the server, and the handshake is not established at this time.
In the first step, Fiddler sends a request to the server to handshake, obtains the CA certificate to the server, decrypts the root certificate public key, verifies the server data signature, and obtains the public key of the server CA certificate.
The second step, Fiddler forge their own CA certificate, impersonate the server certificate passed to the client browser, the client browser do the same thing as fiddler.
In the third step, the client browser generates a symmetric key for HTTPS communication, which is then passed to the server with fiddler forged certificate public Key and is intercepted by fiddler.
Fourth step, fiddler will intercept the ciphertext with their own forged certificate of the private key to obtain the HTTPS communication with the symmetric key.
Fifth step, fiddler the symmetric key with the server certificate public key encryption to the server, the server with the private key after the establishment of trust, the handshake is complete, with a symmetric key to encrypt the message, began to communicate.
Sixth step, Fiddler received the ciphertext sent by the server, with the symmetric key to solve, get the clear text sent by the server. Encrypted again, sent to the client browser.
In the seventh step, the client sends a message to the server, encrypts it with a symmetric key, and is Fidller intercepted and decrypted to obtain plaintext.
Since Fiddler has always had a symmetric key for communication, the information is transparent to the entire HTTPS communication process.
Fiddler crawl HTTPS principle?
