This is our old Q&A Site. Please post any new questions and answers at

I can decrypt the traffic between my browser (firefox 27.0 running on Fedora 20 linux) and by

  1. Adding "export SSLKEYLOGFILE=/home/myusername/somewritablefile" on a new line to /home/myusername/.bashrc and then logging out and logging in again. If you use csh you may be able to add "setenv SSLKEYLOGFILE /home/myusername/somewritablefile" to /home/myusername/.cshrc.
  2. Adding /home/myusername/somewriteablefile to the Edit->Preferences->Protocols->SSL->(Pre)-Master-Secret log filename field in Wireshark, clicking on apply and then ok.
  3. Starting firefox and navigating to - I can now see the decrypted http in wireshark.

BUT only if I first type about:config into the address bar of firefox, search for tls, then change security.tls.version.max to:

0 - In this case firefox uses SSLv3 with SSL_RSA_WITH_RC4_128_SHA and the decrypted http can be seen.

1 - In this case firefox uses TLSv1.0 and TLS_ECDHE_RSA_WITH_RC4_128_SHA and in this case we can also see the decrypted http.

If I change security.tls.version.max to:

2 - In this case firefox uses TLSv1.1 and TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA and wireshark does not show the decrypted http.

3 (default) - In this case firefox uses TLSv1.2 and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and wireshark again does not show the decrypted http.

This method also works for using wireshark to view the decrypted IMAP (e.g., port 993, SSL on a dedicated port settings, which uses SSLv3.0 and cipher TLS_RSA_WITH_RC4_128_SHA) or POP (e.g. with SSL on a dedicated port settings which also uses SSLv3.0 and cipher TLS_RSA_WITH_RC4_128_SHA) when using evolution. If you are using password authentication this will reveal the passwords for these accounts in cleartext, something to remember if you may have someone looking over your shoulder while you look at the trace. It may be that this method also works for other applications, I have not tried any others yet.

I have found which shows that TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA and GCM are not supported, however this bug seems to be closed as RESOLVED,FIXED.

Output of wireshark -v:

"wireshark 1.10.5 (SVN Rev Unknown from unknown)

Compiled (64-bit) with GTK+ 2.24.22, with Cairo 1.13.1, with Pango 1.36.1, with GLib 2.38.2, with libpcap, with libz 1.2.8, with POSIX capabilities (Linux), without libnl, with SMI 0.4.8, with c-ares 1.10.0, with Lua 5.2, without Python, with GnuTLS 3.1.18, with Gcrypt 1.5.3, with MIT Kerberos, with GeoIP, with PortAudio V19-devel (built Aug 4 2013 06:59:20), with AirPcap.

Running on Linux 3.13.4-200.fc20.x86_64, with locale en_GB.utf8, with libpcap version 1.5.3, with libz 1.2.8, GnuTLS 3.1.20, Gcrypt 1.5.3, without AirPcap.

Built using gcc 4.8.2 20131212 (Red Hat 4.8.2-7). "

I am wondering if anyone knows if Wireshark now supports TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA or TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 or what I need to do to decrypt these?

Many thanks

David Grant

asked 28 Feb '14, 12:54

davidgrant's gravatar image

accept rate: 100%

I have downloaded and compiled from and configured with --enable-setcap-install --disable-warnings-as-errors --with-ssl. Wireshark can now decrypt these ciphers. In the case of the data from google to me still seems garbled, although data sent to google can be seen, but connecting to which results in use of the same cipher (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) shows both sides fine. I would like to thank the Wireshark development team very much for making an amazing program.

permanent link

answered 01 Mar '14, 15:28

davidgrant's gravatar image

accept rate: 100%

If my memory serves me right, ECDHE uses Diffie-Hellman (the "DH" part), and thus has PFS and cannot be decrypted by Wireshark. The SSLKEYLOGFILE env variable gives you the master secret, but I don't think that's sufficient/useful with DH. It's only useful with RSA, as far as I can recall. You might want to try using something like fiddler.

permanent link

answered 28 Feb '14, 13:00

Hadriel's gravatar image

accept rate: 18%

Thank you very much Hadriel. I have taken a look at fiddler. However I would prefer to decrypt the capture directly in Wireshark rather than setting up a MITM proxy. This seems to be preferable to me since it cuts out the middleman ;) so to speak.

When security.tls.version.max=1 is set in the about:config page in firefox, then TLSv1.0, cipher TLS_ECDHE_RSA_WITH_RC4_128_SHA was used by (I closed both Wireshark and firefox and restarted them after making changes to this setting.) This was decrypted by Wireshark and it looks as if this cipher uses forward secrecy e.g. states "the ECDHE_ECDSA and ECDHE_RSA key exchange algorithms provide forward secrecy protection in the event of server key compromise" and states "Configuring Forward Secrecy...In the nutshell, these are some of the suites you might want to enable3 and push (close) to the top: TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA"

As you said SSLKEYLOGFILE env variable gives the master secret (as per i.e. CLIENT_RANDOM space 64 bytes of hex encoded client_random space 96 bytes of hex encoded master secret. However I am presuming that this is the master secret which can be used to derive the session key (c.f. With TLS_ECDHE_RSA_WITH_RC4_128_SHA the lines "found master secret in key log" and "dissect_ssl3_hnd_srv_hello found CIPHER 0XC011 -> state 0x37" followed by generation of the plaintext appear in the log file chosen in the "SSL debug file" field. With TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 the line "found master secret in key log" also appears but is however followed by "dissect_ssl3_hnd_srv_hello can't find cipher suite 0xC02F".

This makes me think together with that it might be that Wireshark does not support these particular ciphers? Or is there something I need to configure in a different way? I have found also this which seems to suggest that the development version of Wireshark may support GCM.

(28 Feb '14, 20:59) davidgrant

Huh, interesting. Well, that wireshark "bug" is fixed, but I think in release 1.11.x not 1.10. I don't know which 1.11 exactly, but you could try it with the latest - get the latest nightly build at:

That bug also has a sample tracefile and key info, so you could try with it first to make sure things are working, then try with yours.

(28 Feb '14, 22:25) Hadriel
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 28 Feb '14, 12:54

question was seen: 21,159 times

last updated: 01 Mar '14, 15:28

p​o​w​e​r​e​d by O​S​Q​A