[mitmproxy] Patch issue #2103

[LetMeR00t]

PR for resolving #2103

It's not working for the moment but I can't find why ...
@jbremer can you have a look to see if you see what I miss ?
Nothing appears as decrypted in the HTTPs tab using these modifications

[codecov-io]

Codecov Report

Merging #2104 into master will increase coverage by <.01%.
The diff coverage is 56.66%.

@@            Coverage Diff             @@
##           master    #2104      +/-   ##
==========================================
+ Coverage   62.37%   62.38%   +<.01%     
==========================================
  Files         154      154              
  Lines       15823    15842      +19     
==========================================
+ Hits         9870     9883      +13     
- Misses       5953     5959       +6

Impacted Files	Coverage Δ
cuckoo/auxiliary/mitm.py	20% <0%> (-0.69%)	⬇️
cuckoo/processing/dumptls.py	63.63% <100%> (-4.55%)	⬇️
cuckoo/processing/network.py	79.61% <60%> (+0.07%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 13cbe0d...f2d4114. Read the comment docs.

[coveralls]

Coverage increased (+0.007%) to 62.29% when pulling f2d4114 on LetMeR00t:patchissue_#2103 into 13cbe0d on cuckoosandbox:master.

[LetMeR00t]

@jbremer I'm pretty sure that it's because we don't have the same information in the SSLKEYLOGFILE...
According to this link : https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format, the SSLKEYLOGFILE contains the client_hello ID and not the server_hello ID as on your code :
https://github.com/LetMeR00t/httpreplay/blob/859feca94207b018a308f08cbae2555064639843/httpreplay/smegma.py#L470-L480

A big difference between RSA and CLIENT_RANDOM labels don't you think ?

[jbremer]

It's probably enough, but indeed might require some additional / different handling. It's been a while so I don't have the whole TLS picture in my mind currently, but what about a simple
master_secret = self.secrets[self.client_hello.data.session_id] or master_secret = self.secrets[client_random] or so?

[LetMeR00t]

I added this, it seems to be working but I have now an error during the decryption process.
Do you have any idea on that ?

[LetMeR00t]

Potential solutions :

• Use the tlslite-ng v0.7.0, maybe it's a bug ?
• Use different cipher suites to see if the problem is specific to AES GCM ?
  It's weird because the first "Client random found" has no error, meaning that it's was well decrypted ?...
  I think that for the cuckoo/httpreplay it's ok, I think it's linked with the ciphersuite or tlslite-ng...
  What do you think ?

[LetMeR00t]

For the record, using tlslite-ng v0.7.0 doesn't resolved the issue.
I'm confusing about the HTTPS decryption reporting, did you have any issue on your side ? Because I didn't succeed to have at least one sample with HTTPS transactions that are decrypted...
Anyway, I will try the second potential solution but it's difficult to know where the problem is (because Cuckoo is using httpreplay which is using tlslite-ng ....)

[LetMeR00t]

@jbremer , good news !
It worked using another cipher suite !

As you can see above, the debug is showing that TLS master secret is working.
Moreover, the PCAP shows the chosen ciphersuite (not using GCM in my case)
Finally, you have the result on the cuckoo web interface.

[LetMeR00t]

By using this configuration file, I have no issue at all :

mode: "transparent"
showhost: True
ciphers_client: "ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS"

No GCM cipher suites are on this list, I suspect a bug concerning the decryption of an AES GCM traffic during the replay.
Otherwise, the code is working.

[LetMeR00t]

This is linked to the PR : hatching/httpreplay#15

[LetMeR00t]

Hi @jbremer,
I've updated my PR with your recent updates :

• https://github.com/LetMeR00t/httpreplay/tree/patchissue_cuckoo_%232103
• https://github.com/LetMeR00t/cuckoo/tree/patchissue_%232103

Once more, I succeeded to use mitmproxy as a transparent proxy with these patches.
I don't check again if the GCM ciphers were always a problem in the decryption.

Tell me if you need help.

[LetMeR00t]

After a check, I confirm you that GCM ciphers are not working.
I have to use a config.yaml file in my ".mitmproxy" folder :

mode: "transparent"
showhost: True
ciphers_client: "ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS"

With all, it works perfectly.

[ProtoGitt]

Hi. Just wanted to thank you for fixing this as I ran into the same issue - i'm able to see and decrypt the traffic. I wonder why this hasn't been fixed in the official release yet?

Thanks.

[LetMeR00t]

Hi @jbremer,
I updated this branch to the current master, I hope you will have some time to take my changes :)
As a reminder, it allows to use mitmproxy without any issue for the decryption.
Thank you

[LetMeR00t]

Update done with the last version of "master"