Cookie-Einstellungen
Wir verwenden Cookies, um Ihnen ein optimales Webseiten-Erlebnis zu bieten. Dazu zählen Cookies, die für den Betrieb der Seite und für die Steuerung unserer kommerziellen Unternehmensziele notwendig sind, sowie solche, die lediglich zu anonymen Statistikzwecken, für Komforteinstellungen oder zur Anzeige personalisierter Inhalte genutzt werden. Sie können selbst entscheiden, welche Kategorien Sie zulassen möchten. Bitte beachten Sie, dass auf Basis Ihrer Einstellungen womöglich nicht mehr alle Funktionalitäten der Seite zur Verfügung stehen.

Weitere Informationen finden Sie unter »Datenschutz«
Impressum
Essenzielle Cookies
- Session cookies
- Login cookies
Funktionelle Cookies
- Google Maps
- reCAPTCHA

< Blog >

open200 Funksprüche
An alle Stationen. Bitte kommen. Alles Roger. Over.
100 IT Unternehmerfruhstuck v3
career
30.05.2023
100. Wiener IT Unternehmerfrühstück - Das monatliche Software-Networking Event

IT-Unternehmer treffen sich an jedem letztem Freitag im Monat zum Erfahrungsaustausch, arbeiten an akuten Themen wie z.B. Vertrieb, Marketing, Softwareentwicklung, Mitarbeiterführung etc. Das 100. Frühstück findet diesmal in Magda's Hotel statt. Begrenzte Plätze. Hier geht es zur Anmeldung:

Mehr lesen
open200 partnership AxonIQ v4
18.05.2023
open200 partner of AxonIQ - WIN A VOUCHER for A FREE AXON TRAINING!

open200 has been partner with AxonIQ and using the Axon framework for 7 years now. Together we are celebrating this close partnership and want you to benefit from our expertise: WIN a special training by AXON FOR FREE! Read more of how you can benefit in our blog.

Mehr lesen
Bildschirmfoto 2023 04 28 um 11.37.41
28.04.2023
Using Wireshark to analyze TLS encrypted traffic

In the live of a software or system engineer it is sometimes necessary to debug network traffic on the lowest possible level.

Mehr lesen
openSkillShare Issues
selforganising
13.04.2023
Boosting Team Efficiency with openSkillShare

The Upcoming Tool for Collaborative Problem-Solving at open200 - the onsite experiment!

Mehr lesen
A4 Header
selforganising
23.05.2022
100 % Remote Company – doch nicht der richtige Begriff?

Lange benützen wir den Begriff zur Beschreibung unserer hybriden Arbeitsform. Doch ist er überhaupt passend? Wir haben uns auf eine neue Bezeichnung geeinigt. Darüber berichtet Otto Meinhart.

Mehr lesen
openInnovation 05
selforganising
17.05.2022
100 % Remote Company – Fluch oder Segen?

Die Vorteile eines Remote Setting wurden in mehreren Blogartikeln besprochen. Wie sieht es aus mit den Nachteilen? Gibt es sie? Und gibt es Tätigkeiten, die im Büro besser funktionieren? Otto Meinhart spricht darüber.

Mehr lesen
A3Header
selforganising
13.04.2022
100 % Remote Company - Wenn der Geschäftsführer das Büro auf eine Insel verlegt

Unsere Mitarbeiter:innen arbeiten bereits seit 2020 überwiegend remote. Wie ist es, wenn der Chef für 4 Wochen auf einer spanischen Insel arbeitet? Otto Meinhart berichtet über seinen Selbstversuch.

Mehr lesen
A2Header
selforganising
06.04.2022
100 % Remote Company - Ohne diese 2 Dinge funktioniert es nicht

Die Entscheidung zur 100 % Remote Company wurde gefällt. Otto Meinhart erzählt, wie die Voraussetzungen für die Umsetzung geschaffen wurden.

Mehr lesen
A1.Header
selforganising
30.03.2022
100% Remote Company - wie mit einem Buch alles begann

Die openFORCE deklariert sich zu 100 % als Remote Company. Dies war nicht immer so. Wie es dazu kam und was die Meinung von Geschäftsführer Otto änderte, steht im Blogartikel.

Mehr lesen
Renault
opensource
17.12.2021
openHAB My Renault Binding

Renault openHAB binding for mobile house battery info.

Mehr lesen
oF InnovationDays 2021 10 046 title
selforganising
02.12.2021
Die openINNOVATIONdays 2021 im Makerspace Happy Lab

Unser zweitätiger Kreativworkshop fand dieses Mal im Wiener Happy Lab ganz im Zeichen von Trial and Error mit 3D-Druckern, Laser Cuttern und Co. statt. Im Blogbeitrag gibt es die Zusammenfassung des coolen Team Events.

Mehr lesen
Lust auf ERFOLG?
Using Wireshark to analyze TLS encrypted traffic

In the live of an software or system engineer it is somtimes necessary to debug network traffic on the lowest possible level. Wireshark is the most common tool to use when you want to analyze network traffic by sniffing the raw data that crosses your network interface.

As long as you have unencrypted traffic you can directly see the protocoll details as well as the payload of data packages that are sent through the network. But hey, we have 2023, so most of the traffic should be encrypted using strong and modern encryption methods. TLS 1.3 is the standard way to encrypt network traffic today. When starting a communication sender and receiver agree on the encryption method and exchange secret keys that are used to encrypt and decrypt the payload. Without these keys you cannot access the payload and just see a random sequence of bits and bytes.

But for debugging purposes we need to access to the unencrypted payload. So what to do?

The only way to decrypt the payload is to have access to the secret keys the communication partners have agreed on. Thankfully Wireshark understands TLS 1.3 (and older standards like SSL, older TLS versions, but these should not be used anymore) and can decrypt traffic if we provide the secret keys. And there is good news. Most of the tools we use in development have options to log the secret keys so we can use it in Wireshark to decrypt the network payload so we can analyze all the traffic.

There is a log format specification for exactly that purpose and Wireshark can read encryption keys logged in that format!

Configure Wireshark

Wireshark is an excellent tool with an enormous amount of featues, but for the casual user the user interface can be a bit overwhelming. I will not show the general usage of Wireshark or how to start analyzing a network connection as that would extend the length of that post.

When you have started a recording session you need to configure where Wireshard can find the communication keys. You need to right click in the packet list and select open the "Transport Layser Security Preferences" dialog. The following screenshot shows the context menu and where you can find it.

 

In the following dialog you need to select the log file with the keys. This is shown in the next screenshot.

From now on Wireguard can access the secret keys and will try to use them to decrypt the TLS message payload! Now only one question remains. How to configure your software stack to log the secret keys?

HTTP Browsers and Tools

This works for Google Chrome, Chromium based browsers, Firefox and curl on Linux/macOS.

export SSLKEYLOGFILE=/home/my-user/Documents/tls_key.log

You need to start the browser from the command line so that the environment variable takes effect. After visiting websites that use https (should be any website nowadays) you will notice that the communication keys have been appended to the tls_keylog.log file. You can use that file within Wireshark as described above! As soon as you added the keyfile Wireshark looks up the corresponding encryption keys from the file and uses it to encrypt the whole traffic!

 

 Java/JVM based applications

When you are using JVM based languages like Java, Kotlin, Scala you cannot use the method above as Java uses it's own TLS stack to do all the encryption. Luckily there is a little software helper that can log communication keys as well! You can use jSSLKeyLog to run as a Java agent along with your application. You can find more infos about Java agents in that overview about Java instrumentation.

The following example shows how to configure that i.e. in IntelliJ:

The important part is that you need to add a JVM argument in the form:

node --tls-keylog=$(pwd)/tls_key.log app.js

As soon as you start your application and access TLS encrypted websites or API endpoints the encryption keys will be appended to the key.log file. Now you can configure Wireshark as described above to read the keys from that file and et voilá - you can see the decrypted payload.

Node - JavaScript, Typescript

When you are using Node you are ready to log your encryption keys out of the box as node has explicit support for logging them to a file via command line option:

node --tls-keylog=$(pwd)/tls_key.log app.js

So just add the "--tls-keylog" option to your scripts and you are ready to debug!

Rust

There is no explicit support for logging TLS keys - at least I am aware of - but you can use a default library available for Rust to log the keys in your application.

The documentation is available here https://docs.rs/rustls/latest/rustls/trait.KeyLog.html

So a bit more work to do but at least not quite hard to implement it into your application.

Disclaimer

As soon as you have finished your debugging session, don't forget to disable the logging of the SSL/TLS keys again! When you use your browser for debugging tasks and then do some banking stuff you don't want anyone else to have access to the keylog files, did you? So simply don't forget to disable the logging!

So next time you need Wireshark for low level debugging network traffic you don't need to fear about TLS encrypted traffic. Happy debugging!