7

For the purpose of troubleshooting, I need to see what an email looks like when it's sent to my sendmail server via SMTP. The upstream server requires the SMTP connection to use STARTTLS so a packet capture only shows me encrypted data.

Is there a way to use wireshark to decrypt the transmission and see? Assuming of course that I have the private key used on my sendmail server?

I see several procedures available online referencing the RSA key lists feature in wireshark (for example: https://support.citrix.com/article/CTX116557). But this still doesn't seem to be working for me.

Is this related to forward secrecy? Can I just not do this on newer protocols / ciphers?

Mike B
  • 11,570
  • 42
  • 106
  • 165
  • 3
    It depends on the cipher used, especially the key exchange. If RSA key exchange is used you can decrypt it with the private key of the server certificate. If DHE/ECDHE is used (forward secrecy) you can't. – Steffen Ullrich Aug 11 '17 at 17:44
  • 2
    Better suited on http://security.stackexchange.com/ – sebix Aug 11 '17 at 18:24
  • @SteffenUllrich would you like to post your response as an answer? I'll upvote. :-) – Mike B Oct 03 '17 at 00:00

2 Answers2

2

It may be that the wireshark SMTP protocol parser doesn't know how to handle TLS/SSL. But maybe you can use the HTTP protocol parser instead. Go to edit->preferences->protocols->HTTP and add the port to SSL/TLS ports

ptman
  • 27,124
  • 2
  • 26
  • 45
2

Knowledge of the RSA private key is only sufficient if RSA key exchange is done. Modern systems instead use Diffie Helmann key exchange (DHE*, ECDHE* ciphers) to provide forward secrecy. In this case the private key is only used in authenticating the server but not for the key exchange and thus knowledge of the private key does not help in getting the encryption keys.

Instead the SSL pre master secret would be needed since this is used to derive the encryption keys. While some browsers support exporting this secret in some special debug modes other clients usually don't.

As for your specific problem I would instead to try a man in the middle "attack" which logs all traffic in plain even though the client gets encrypted traffic. This works similar to man in the middle proxies for HTTPS, only that it supports the initial plain connection and understands that STARTTLS upgrades to TLS. From a quick search I've found starttls-mitm and that sslsplit has some beta support for this. Of course the client needs to connect to the man in the middle proxy and trust the certificate it gets, which might be the original server certificate since you seem to have access to this.

Another option would be to enable debugging in the specific MTA in case this provides detailed enough information for your specific problem.

Steffen Ullrich
  • 12,227
  • 24
  • 37