How to decrypt Diffie-Hellman in wireshark?

How can i decrypt Diffie-hellman TCP packets?

I’m trying to make a tool that shows cleartext response from a server that uses this encryption. However when i look online people all seem to say it’s impossible to decrypt DHE, which is not true since we are the client and have access to this information,

but how can i decrypt these packets with the handshake in wireshark?

Bonus question: Any tools in python or something that establish DHE connections and show cleartext response?

enter image description here

Using Diffie-Hellman exchange on low power IoT devices

I have almost 0 knowledge of IoT, their protocols and usual device constraints. I had a discussion today with someone that has a fair amount of IoT experience and we were discussing some security related issues and the establishment of a shared key came up. I assumed that Diffie-Hellman would be used but this person seemed to not be familiar with the method and based on their knowledge for low power devices, the keys are actually preloaded inside.

  1. Is this true?
  2. Is the power consumption for a secure DH exchange too high to use on low power IoT devices?
  3. What role does Ephemeral Diffie–Hellman Over COSE (EDHOC) play in this case? Is it a good alternative or still problematic?

Real implementation of Diffie-Hellman [on hold]

I’m making a cybersecurity project where I need to implement a symmetric key exchange between two parties. Although I understand how Diffie-Hellman works in theory, how can I actually implement it(or use an existing implementation of it) for a project? So far, I have used OpenSSL to generate RSA keys(for signatures), but am stuck on getting some sort of DH implementation.

How to decrypt Diffie-Hellman encryption in WebRTC?

I have installed a WebRTC server application, which is designed for Contact Center solutions: communicates with internal PCs in pure RTP (agents), and with external PCs (customers) using encrypted WebRTC. WebRTC is encrypted with Diffie-Hellmann. I would like to be able to decrypt the WebRTC RTP stream, and eventually replay it, to be able to debug quality related problems (sometimes quality is OK between agent and server, but very low on customer device, and not sure whether to blame the network, the server or the customer device). In such a debugging scenario, I will have full access to the server (root access in linux, able to tcpdump and do basically anything), and most of the time I will have full access to the customer device (e.g. Administrator access on my laptop).

What I have done so far is I added SSLKEYLOGFILE environment variable, and Chrome started printing a lot of data in it, like this:

CLIENT_HANDSHAKE_TRAFFIC_SECRET 5fc29d95842ec41a2faa367ad799e25ec020eb2bba47a2ae4b25dd45b26715fe f3eb56ec637c241f6a7bffed601b362bb39035c9a204d6259bf221d7428cef50  CLIENT_TRAFFIC_SECRET_0 5fc29d95842ec41a2faa367ad799e25ec020eb2bba47a2ae4b25dd45b26715fe e848e23888913118a3a717c137f0299d4bdea98a7c0513eca728dca63ab07f77  SERVER_TRAFFIC_SECRET_0 5fc29d95842ec41a2faa367ad799e25ec020eb2bba47a2ae4b25dd45b26715fe f22862cd1d888f083ce7c55207c2d044db8dab24be5d5304b53f3b08588436a4  EXPORTER_SECRET 5fc29d95842ec41a2faa367ad799e25ec020eb2bba47a2ae4b25dd45b26715fe 015444c5a2ef5c7a691a10ca168fc0c8e4e0d00127d3c2f1cdda27ec671b3c94  CLIENT_RANDOM 9265831d9c50fc1a45d1ba06bfda5c10bea1c82104ec0170add0187ad1cb76b5 736c310b97a1c1e887d57f222d3e74ee022d91ad9fdcaa9006e2a21eeb4fd863c5fa76b9a61aabda44906b84501c960a 

My problem is, that based on online articles, I should be able to find the ‘Random Bytes’ as seen in Wireshark in this file, however I cannot. I tried session id, random bytes, basically all similar looking strings that I saw in Wireshark, but I can’t seem to find them in the SSLKEYLOGFILE. Nevertheless I added SSLKEYLOGFILE into Wireshark to DTLS protocol as (Pre-)Master-Secret file, but the traffic is not decrypted. The Wireshark SSL debug file doesn’t print anything that resembles an error (although I’m not sure what to look for). I can see various messages:

dissect_ssl enter frame #22 (first time) packet_from_server: is from server - FALSE   conversation = 0000027E892C55E0, ssl_session = 0000027E892C5C80   record: offset = 0, reported_length_remaining = 581 ssl_try_set_version found version 0x0303 -> state 0x10 dissect_ssl3_record: content_type 23 Application Data decrypt_ssl3_record: app_data len 576, ssl state 0x10 packet_from_server: is from server - FALSE decrypt_ssl3_record: using client decoder decrypt_ssl3_record: no decoder available  ssl_decrypt_record found padding 8 final len 327 checking mac (len 307, version 303, ct 23 seq 1) tls_check_mac mac type:SHA1 md 2 Mac[20]: | c9 62 43 71 5c 9f 91 31 0d 98 cc 3b 9a 37 2f 1a |.bCq\..1...;.7/.| | 0b 61 3d dd                                     |.a=.            | ssl_decrypt_record: mac failed    checking keylog line: CLIENT_HANDSHAKE_TRAFFIC_SECRET 1c88cbccba12f83b5752f3dc49cd4294dbb77f0a6992f728d129af34e4d70350 39741b6d2d8cecaa23477ecd1929d7f21560397fe48aec4c11ec92d263cfa542     matched client_handshake  tls13_load_secret TLS version 0x303 is not 1.3 

So basically I’m stuck at this point. What am I missing? Do I need to export something from server side also? Or more Wireshark configuration?

EDIT:

You can check SSLKEYLOGFILE, Wireshark debug log, and raw capture here: https://drive.google.com/open?id=1-1XnRVvrTqQiHq8bF3KTLKZzKAC9zRb0

In the capture, 10.35.119.32 is the server IP which handles RTP, 16004 is the WebRTC port (there is unencrypted RTP also from/to this server, which is the agent RTP as I mentioned, on port 17xxx).

TLS-Handshake, Server Key Exchange, Diffie-Hellman: Where does key length come from?

Where does the key length come from?

In this example it is 2048 bits long:

Secure Sockets Layer     TLSv1.2 Record Layer: Handshake Protocol: Server Key Exchange         Content Type: Handshake (22)         Version: TLS 1.2 (0x0303)         Length: 783         Handshake Protocol: Server Key Exchange             Handshake Type: Server Key Exchange (12)             Length: 779             Diffie-Hellman Server Params                 p Length: 256                 p: ...                 g Length: 1                 g: 02                 Pubkey Length: 256                 Pubkey: ...                 Signature Algorithm: rsa_pkcs1_sha512 (0x0601)                 Signature Length: 256                 Signature: ... 

It is apparently not a parameter of the cyper suite (here: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256) as there is no key length given for DHE.

Is this just a parameter configured on the server side? Or is it somehow negotiated? I cannot find much information except in “Bulletproof SSL and TLS” in the section about deployment best practices.

To be on the safe side, if deploying DHE, configure it with at least 2,048 bits of security.

That section makes it sound like it’s server configuration…

Reason for my question:

I have got a piece of older software which cannot connect to a server via TLS. It complains that it only supports DH key lengths from 512 to 2048. And in the according network trace p Length is 512 (== 4096 bits). Thus the TLS handshake fails.

Now I need to know how I could get my legacy software (running on an embedded device) to talk to the server (preferrably without updating the software).