3

I have the following question regarding the decryption of SSL traffic. The topology that I have in mind is like this: User-------MitM Proxy--------WebServer In the environment described earlier there is already a commercial proxy which is doing a man in the middle attack by replacing the original SSL certificate of the server with it's own. Can I decrypt the SSL traffic between the user and the proxy and send them un-encrypted to a forensics/sandbox solution? I have a tap device between the users and the proxy and the public and private key of the mitm proxy are available.

3

EDIT : If the proxy SSL certificates are already installed on the user computer then yes absolutely and here's the right answer. Otherwise keep reading...

Yes and no.

No because by replacing the SSL certificate of the server by your own, the user's browser will raise a big scary warning that the certificate is invalid and will warn the user that he should not proceed.

Yes because if the user still decide to proceed and accept the false certificate, then you will be able to decrypt everything since it was encrypted with your certificate.

Alternatives

  1. If you are able to install your certificate directly on the user computer, then his browser will not raise any warning and you can decrypt everything. Check this link

  2. Just replace the https by http. Most users don't take the time to check that it's really https so it's a very effective MitM attack.

  3. Get a real certificate for a url that is similar to the url you are targeting.

| improve this answer | |
  • Generally when you have a SSL decryption/inspection proxy like the one the poster describes in place, you are indeed already deploying certs to the client machines. The traffic is in fact already being examined at that point, that isn't the question. The question is can the OP add an additional tap to capture and decrypt the traffic a second time. – Xander Aug 20 '14 at 17:46
  • @Xander Wrong. If a proxy, or any malicious MitM, could simply deploy certificate on my machine by the simple fact of being the MitM then I would be very worried and you should be too. The fact is that unless the user specifically accept a certificate, it will NOT be install on the user machine. Hopefully for us, our browser pop scary warning to help us make the good decision. – Gudradain Aug 20 '14 at 17:51
  • @Xander Whether you add a second MitM or 20 other MitM doesn't change anything. The same explanation apply. – Gudradain Aug 20 '14 at 17:52
  • You misunderstand the configuration here. This is not a malicious MitM. It's a proxy used to decrypt and monitor SSL traffic coming and going from a corporate network. The users do not need to accept and install certs, because they've already been installed by IT as a part of the image or pushed via a group policy. – Xander Aug 20 '14 at 17:59
  • @Xander Well, the question only state : "there is already a commercial proxy which is doing a man in the middle attack by replacing the original SSL certificate of the server with it's own." Not that a corporate certificate have already been installed on the user machine... – Gudradain Aug 20 '14 at 18:04
1

EDIT
As Andrey points out in the comments; this is only valid if the user machine already trusts the replacement SSL cert (more accurately, the proxy cert as a root cert or the proxy cert signed by a trusted root), otherwise the user will get a warning that the cert is signed for the wrong domain. In a corporate setting, the proxy cert is typically installed by a group policy by the domain admins.

Yes, absolutely. If your MitM proxy is already replacing the SSL certificate, you should be able to decrypt the traffic using the private key of the MitM proxy. Just capture the packets as if they were unencrypted (using wireshark or something) and unencrypt them at your leisure.

| improve this answer | |
  • The important precondition being that client must trust that replaced SSL certificate, which isn't always true. – Andrey Aug 21 '14 at 5:34
  • 1
    You can passively decrypt the client-MitM leg if you have the MitM privatekey, which OP does, and at least one of the client and MitM forces plain-RSA (not Perfect Forward Secrecy = DHE or ECDHE) key-exchange. For reasonably modern clients such as web browsers this isn't the default, although if admins are already pushing the MitM's root cert maybe they can push a cipher restriction also. If the (unspecified) MitM only implements RSA or has an option to limit client-side to RSA, that handles everybody at once. – dave_thompson_085 Aug 21 '14 at 10:40
  • I have indeed the private key of the proxy that is doing man in the middle for the users, I do not have an issue with the user's browsers trusting that certificate that the proxy is generating. My issue resides in the fact that I cannot decrypt ssl traffic using wireshark or other tools. I've been struggling with this for some time, I think that I have an issue with the public/private keys I submit for decryption. If I browse linkedin.com for example, the certificate that is used to identify that session looks like this:Root CA--Subord1--MitmProxy--Linkedin.com – mihai rosca Aug 25 '14 at 7:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.