How to Decrypt an HTTPS Exchange with Wireshark

This is the second blog in a three part series. If you missed, “3 Things You Should Know About HTTPS, SSL or TLS traffic with Wireshark”, please visit Lovemytool

Most internet traffic is now encrypted and internal applications also commonly use encryption that is based on Secure Socket Layer (SSL) or Transport Layer Security (TLS) to ensure they are secured. This makes packet analysis using Wireshark more complex than it used to be.

This article will clarify what you can and cannot decrypt and what information is still available to you when SSL/TLS traffic cannot be decrypted.

Can you decrypt SSL/TLS traffic with Wireshark? Yes and No.

It depends on the version of SSL/TLS used. In some cases, Wireshark will handle it, in other cases it will not. See below for your options.

How-to decrypt the SSL/TLS session with Wireshark?

Some TLS versions will allow you to decrypt the session using the server private key.

  1. Load the private key into Wireshark in PEM/PKCS format.
    1. Go to Edit > Preferences. Open the Protocols tree and select SSL
    1. Open the RSA Keys List by clicking on Edit
  • You will be requested to add the following :
    • IP address/subnet of the server(s)
    • Port used
    • Protocol used for the decrypted data (e.g. HTTP if you are looking at HTTPS)
    • Path to load the RSA private key
    • Password: not used for PEM encoded private key files, required for PKCS 

2. Provided that your analysis device sees the setup of the SSL/TLS session, it will be able to decrypt the session

For a more detailed procedure, please refer to this page on Wireshark: .

Does it work for all TLS communications? No !

Some TLS implementations will not allow you to decrypt the traffic, specifically when using:

  • Diffie Hellmann (DHE) ciphers
  • New TLS 1.3 protocol

Decrypting a TLS session is possible provided you meet the following conditions:

  • You use a Public Key Infrastructure like RSA that is based on the principle of private/public keys
  • You own the private key

These have been engineered to prevent man-in-the-middle type of attacks, meaning it will never be possible to decode HTTPS traffic by passively getting a copy of it.

So, does it apply to Wireshark only?

No. All analysis devices based on passive traffic analysis will face the same limitations.

Is there a workaround?

Unless you are ready to change your infrastructure or change your capture point, there is no workaround.

On the other hand, if some devices on your network break/proxy the SSL sessions and you would like visibility, you have a chance to view this traffic in the clear. These devices can be proxies or load balancers for applications you host.

Finally due to the rise of encryption, many organizations deploy SSL Inspection solutions in their internet gateway to ensure they keep traffic –such as Internet and SaaS traffic- under control. These solutions offer the possibility to get full visibility on TLS traffic. <LINK on WP on SaaS visibility with A10>

Does no decryption mean I have no visibility?

No. Until now, only the payload is always encrypted, which means that:

  • The TCP/IP part of the packets is readable
  • Most of the TLS protocol information is also readable, at least for now.

What can I see at TCP level?

We can see all the layers up to the transport layer. Some examples include:

  • Ethernet layer: MAC addresses, VLAN, etc.
  • IP : client, server IP addresses, ports
  • TCP : all TCP windows, flags, etc.

Add to that, all statistics based on packet data collected on these layers are also available, including:

  • Volumes (packets, data, payload, etc.)
  • Sessions
  • Time intervals reflecting network latency and server processing time
  • Retransmissions

In the end, even if these cannot be related back to a precise request to the server (for example, an application transaction, like a GET), the overall network conditions and end- user response time can be evaluated at Layer 3/4.

What information can I collect from the TLS data?

  • The who, what, and how to classify TLS traffic. The certificate name and the SNI will be very useful to identify the nature of the service which is encrypted. It can help you understand to which Internet traffic or SaaS this flow corresponds.
    • Certificate Name
    • SNI
  • Security of the TLS implementation: this provides useful information to evaluate the security level of the conversation:
    • TLS version used
    • Cypher suite used
    • Key length,
    • Certificate expiration date
  • Performance and troubleshooting: TLS will also report events like :
    • Alerts
    • Resumed sessions
    • Performance indicators measured from time intervals like TLS connection time

In conclusion, packet analysis using Wireshark is more complex than it used to be. It’s important to know what you can and cannot decrypt and what information is still available to you when SSL/TLS traffic cannot be decrypted.

If you missed the first blog in the series, get caught up here.

Stay tuned for the third and final blog in the series. In the meantime, launch our demo to learn more!