Another way that HTTPS traffic can be intercepted and decrypted/read is by using Man-In-The-Middle attacks. Same as above.Yes, HTTPS traffic can be intercepted just like any internet traffic can.
Update: Here’s the link for the KB article in bluecoat which I wrote. This link is a very good short and sweet explanation with screenshots: The rest of the procedure follows the normal SSL decryption. The proxy will output the key in the form:ĥ.Ĝopy and paste the key (including the BEGIN RSA and END RSA lines) in notepad and store in a safe place as a. Substitute the “ selfsigned” keyword for your own keyring ID. Make a note of the keyring ID being used in the reverse proxy (this can also be checked from the GUI under proxy services)Ĥ.Ğnter the command show ssl keypair unencrypted selfsigned.
(optional) enter show ssl keyring to view a list of configured keyrings. If another certificate is used, please substitute the appropriate entries.ġ.Ğnter the proxy management console via CLI (ssh / console cable)ģ. In this example we will extract the self-signed key from the proxy. If these plaintext keys get lost, please change the certificates and keys on the proxy to avoid a security/integrity compromise.Įxtracting the private key from the Proxy: Please be very careful and delete these after use. Please note: You will be dealing with plaintext private keys. Since the key is known to the Proxy, it is possible to extract this key and use it in Wireshark to decrypt the SSL traffic for easier troubleshooting. In a reverse proxy scenario, the appropriate certificate and keys must be imported into the proxy in order to allow it to properly terminate SSL connections. Just submitted as KB article to bluecoat 🙂Īn SSL reverse proxy is deployed, and at some stage in the troubleshooting process a packet capture of the HTTPS traffic is required to view traffic flowing between the client / proxy or between the OCS and proxy.
0 kommentar(er)
