Remember the Little-Endianness

How to remeber "little-endianness" easily? Remember as "three L":

Little-Endianness → Least-Significant-Byte at the Lowest-Address

So for x86-64, if we have an int i = 0x01020304 on the stack, it looks as follows:

         USERLAND
-------------------------
|xx xx xx xx xx xx xx xx| 0x0000 7fff ffff ffff
|xx xx xx xx xx xx xx xx|
|01 02 03 04 xx xx xx xx| <-((int*)&i)-1
|xx xx xx xx xx xx xx xx|
|xx xx xx xx xx xx xx xx|
------------------------- <-$rsp
|                       |
|                       |
          ......
|                       |
|                       | 0x0000 0000 0000 0000
-------------------------

Sign in to Security Device: Please sign in to NSS Certificate DB

Because of this error pop-up window, it is impossible to remove/add/change root authorities (Settings → Manage certificates → Authorities) in Chromium browser:

The problem is solved this way:

sudo mv  ~/.pki/nssdb/ ~/.pki/nssdb_old

or more radically:

sudo rm -r ~/.pki/nssdb/

Mitmproxy. Decrypting TLS traffic in Wireshark exporting session keys from Mitmproxy.

1. We install mitmproxy (mine is version 4.0.4 requiring Python 3.6.8).


2. 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:



1

mitmproxy



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


3. 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.


4. Now we return to the first tab with the mitmproxy opened and we will see the http2 Server Push communication:
   
   
   
   
   
   NOTE
   
   
   We need flag --ignore-certificate-errors because mitmproxy generates a fake certificate for each visited page signed by mitmproxy itself (and mitmproxy is not a root CA in our browser). So if we executed the above command without the flag, we would get a typical SSL warning screen where we would have to add a security exception. Below in the image one can see the fake certificate for hostname http2.golang.org.
   
   

   
   
   
   
   An alternative to using the flag is to import the mitmproxy certificate as a root CA to our browser. It is very easy. Once mitmproxy is launched, it automatically creates a certificate file ~/.mitmproxy/mitmproxy-ca-cert.pem (do not confuse it with other files, one of them e. g. contains a private key). So we just go to Chromium Settings → Manage certificates → Authorities. There we press IMPORT to import the certificate file. When asked, we choose the option “Trust this certificate for identifying websites”. Now we can see org-mitmproxy in the authorities list. So we can run the command without the flag and we will get no SSL error:
   
   

   1	chromium-browser --proxy-server="http://localhost:8080" --user-data-dir=/tmp https://http2.golang.org/serverpush



5. 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.


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


7. 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



8. 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.


9. 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.


10. 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). 
    
    
    
    
    
    
    
    


11. 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.

Decrypting TLS traffic in Wireshark exporting session keys from chromium-browser

Suppose we want to do it for page https://http2.golang.org/serverpush.

• We open Wireshark and start capturing traffic. 

• We type in the following commands in the terminal. Here we use option --user-data-dir=/tmp, in order to launch a brand new instance of chromium. If we do not use the option and we have chromium already opened, then the page will be opened in our old instance of chromium and session keys will not be exported.

1 2	export SSLKEYLOGFILE=~/chomium_keys.txt chromium-browser --user-data-dir=/tmp https://http2.golang.org/serverpush

• In Wireshark, we type in to the filter field (as in the image below): http2.
  There will be no packets seen in the window as all the traffic is encrypted.

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

• At once we will see the decrypted http2 packets in Wireshark: