a ⊕ b: 2019

Let us first simply use it. In one terminal tab we execute the following command and we will see gray empty screen because nothing yet came through the proxy:

mitmproxy

Alternatively, one can also use mitmdump command which is TUI variant of mitmproxy.

In another one terminal tab we launch the following command:
1

chromium-browser --proxy-server="http://localhost:8080" --ignore-certificate-errors --user-data-dir=/tmp https://http2.golang.org/serverpush
Here we use option --user-data-dir=/tmp, in order to launch a brand new instance of chromium. If one does not use this option and has a chromium instance already opened, then the page will be opened in this old instance of chromium and session keys will not be exported.

Now let us return to decrypting TLS in Wireshark. Below I drew the scheme of interaction among our browser (B), mitmproxy (P) and the remote server (S):

All the traffic is doubled – each copy of the two is encrypted with different ephemeral keys. So now we open Wireshark on “any” interface, in order to see both the loopback traffic between the browser and mitmproxy, as well as the traffic between mitmproxy and golang server.

In Wireshark, opened on “any” interface, we type in to the filter field: http2.

Now we want to export both sets of the keys using mitmproxy. So we launch mitmproxy in one terminal tab as following:
1

SSLKEYLOGFILE=~/mitmproxy_keys.txt mitmproxy

Now we launch chromium in another terminal tab as follows. As all the traffic is encrypted, there will be no packets filtered out by "http2" and seen in the traffic window of Wireshark.
1 2

export SSLKEYLOGFILE=~/chomium_keys.txt chromium-browser --proxy-server="http://localhost:8080" --ignore-certificate-errors --user-data-dir=/tmp https://http2.golang.org/serverpush
Obviously, we do not need the first command because we want to export the keys from mitmproxy, rather than from chromium. But I still offer to execute the first command and so to export also keys from chromium. We will use it at the end of the article in an experiment. For now I just mention that ~/chomium_keys.txt will contain roughly half the keys which will be contained in ~/mitmproxy_keys.txt, i. e., it will contain the 1st keys set depicted in the image above: the keys which encrypt the loopback traffic between the browser and the mitmproxy.

In Wireshark we go to Edit → Preferences → Protocols → SSL.
There we set “(Pre-)-Master-Secret log filename” to our file with exported keys ~/mitmproxy_keys.txt.

Now we can see the decrypted traffic both between browser and proxy and between proxy and server in the window. These two kinds of traffic are copy of each other. In the first image one can see the loopback traffic decrypted. While in the second image one can see its decrypted twin outgoing from mitmproxy to the public Internet and vice versa (the particular frame chosen in the image is actually ingoing – here we have Server Push technology and so the server fulfills its promise by sending the promised resource).

The last step is the above-mentioned experiment. The point is that while mitmproxy was exporting keys to its file, Chromium was doing the same to its file. So in Wireshark we can go to Edit → Preferences → Protocols → SSL again and set “(Pre-)-Master-Secret log filename” to the file ~/chomium_keys.txt.

What we see now: half the traffic has disappeared. Only loopback traffic is present in the window, while the traffic between the proxy and the golang server has become encrypted TLS again so we do not see it in the window because of the “http2” filter. This proves that ~/chomium_keys.txt contains the 1st keys set out of the two sets contained in ~/mitmproxy_keys.txt (so, by the way, the latter file is roughly two times bigger). Actually, one can just open the two files and check that hex strings of keys, contained in the first file, are also present in the second file.

a ⊕ b