cant decrypt TLSv1.3 with Kaspersky Total Security installed

asked 2022-02-01 17:44:36 +0000

PCrossley
1 ●1 ●1 ●2

updated 2022-02-04 15:30:10 +0000

I followed the instructions in https://wiki.wireshark.org/TLS, unfortunately my session does not decode.

I am using Wireshark 3.6.1 on Windows 10

I've tried using: Chrome Version 97.0.4692.99 (Official Build) (64-bit) Firefox 96.0.3 (64-bit)

I am setting the environment variable from a script as suggested, I can see that the file is created when the browser start script is run.

Here is the excerpt from the logfile that seems to be relevant

#2027 is the client hello immediately after the TCP handshake completes.
#2030 is the server hello
#2034 shows application data.

Any suggestions would be gratefully Received.

dissect_ssl enter frame #2027 (first time)
packet_from_server: is from server - FALSE
  conversation = 00000236BB6CF320, ssl_session = 00000236BB6D07C0
  record: offset = 0, reported_length_remaining = 517
dissect_ssl3_record: content_type 22 Handshake
decrypt_ssl3_record: app_data len 512, ssl state 0x00
packet_from_server: is from server - FALSE
decrypt_ssl3_record: using client decoder
decrypt_ssl3_record: no decoder available
dissect_ssl3_handshake iteration 1 type 1 offset 5 length 508 bytes
Calculating hash with offset 5 512
ssl_dissect_hnd_hello_common found CLIENT RANDOM -> state 0x01

dissect_ssl enter frame #2030 (first time)
packet_from_server: is from server - TRUE
  conversation = 00000236BB6CF320, ssl_session = 00000236BB6D07C0
  record: offset = 0, reported_length_remaining = 1414
ssl_try_set_version found version 0x0303 -> state 0x91
dissect_ssl3_record: content_type 22 Handshake
decrypt_ssl3_record: app_data len 122, ssl state 0x91
packet_from_server: is from server - TRUE
decrypt_ssl3_record: using server decoder
decrypt_ssl3_record: no decoder available
dissect_ssl3_handshake iteration 1 type 2 offset 5 length 118 bytes
ssl_try_set_version found version 0x0304 -> state 0x91
ssl_dissect_hnd_hello_common found SERVER RANDOM -> state 0x93
ssl_set_cipher found CIPHER 0x1301 TLS_AES_128_GCM_SHA256 -> state 0x97
trying to use TLS keylog in C:\Users\ptcro\Documents\Wireshark\keylogfile.txt
  checking keylog line: CLIENT_HANDSHAKE_TRAFFIC_SECRET 66b6f23776dc56679574d74c9fbcff5937db50859e66494269c7328e64627a98 280a7cba7701a3ec4c9dcee63c1ac612e25db29bc76aa8cd8dc9f053e62800b5
    matched client_handshake
  checking keylog line: SERVER_HANDSHAKE_TRAFFIC_SECRET 66b6f23776dc56679574d74c9fbcff5937db50859e66494269c7328e64627a98 2c5fe95616deb0200d8e156d54e392b0233debfea38e1099782acca007ebc71e
    matched server_handshake
  checking keylog line: CLIENT_TRAFFIC_SECRET_0 66b6f23776dc56679574d74c9fbcff5937db50859e66494269c7328e64627a98 1323e0b35ada89c6b4757f0e8cc20a770b4cc8b1e2563d7ea11736c269399621
    matched client_appdata
  checking keylog line: SERVER_TRAFFIC_SECRET_0 66b6f23776dc56679574d74c9fbcff5937db50859e66494269c7328e64627a98 e428d0f2c506211e48f088d7ad87f583dd4e44a6f3a7f044050ee29cb109e88e
    matched server_appdata
  checking keylog line: EXPORTER_SECRET 66b6f23776dc56679574d74c9fbcff5937db50859e66494269c7328e64627a98 328f323ad2033fd0ffd85e68d10d366d60ec7cee2dd7b248af48ad01d7b9d27e
    matched exporter
tls13_load_secret transitioning to new key, old state 0x97
tls13_load_secret Cannot find CLIENT_HANDSHAKE_TRAFFIC_SECRET, decryption impossible
tls13_load_secret transitioning to new key, old state 0x97
tls13_load_secret Cannot find SERVER_HANDSHAKE_TRAFFIC_SECRET, decryption impossible
  record: offset = 127, reported_length_remaining = 1287
dissect_ssl3_record: content_type 20 Change Cipher Spec
  record: offset = 133, reported_length_remaining = 1281
dissect_ssl3_record: content_type 23 Application Data
decrypt_ssl3_record: app_data len 36, ssl state 0x97
packet_from_server: is from server - TRUE
decrypt_ssl3_record: using server decoder
decrypt_ssl3_record: no decoder available
  record: offset = 174, reported_length_remaining = 1240
  need_desegmentation: offset = 174, reported_length_remaining = 1240

dissect_ssl enter frame #2034 (first time)
packet_from_server: is from server - TRUE
  conversation = 00000236BB6CF320, ssl_session = 00000236BB6D07C0
  record: offset = 0, reported_length_remaining = 5001
dissect_ssl3_record: content_type 23 Application Data
decrypt_ssl3_record: app_data len 4996, ssl state 0x97
packet_from_server: is from server - TRUE
decrypt_ssl3_record: using server decoder
decrypt_ssl3_record: no decoder available

edit retag flag offensive close merge delete

add a comment

3 Answers

Sort by » oldest newest most voted

answered 2022-02-04 15:25:18 +0000

PCrossley
1 ●1 ●1 ●2

I Just de-installed my Kaspersky Internet Security and decryption now works. Pausing Kaspersky wasn't enough - I had to remove it completely. There may be a setting that I can tweak to stop this happening but I haven't found it yet.

edit flag offensive delete link

Comments

I don't know about Kaspersky, but other AV endpoints do install proxies so that they can inspect traffic. You can check for such a proxy by examining the certificate in your browser, it will have been issued by a CA related to the AV product, usually signed with a certificate locally installed on your machine rather than a public CA.

It appears that Kaspersky AV for Windows does include such a proxy, see here: https://support.kaspersky.com/KESWin/...

grahamb ( 2022-02-04 16:31:01 +0000 )edit

The Problem was caused by the fact that Kaspersky Total Security scans encrypted connections for malware.

Exiting the program works but that turns off protection. Pausing protection doesn't help.

With some help from this site I discovered that Under Settings->Network Settings there is an option "do not scan encrypted connections". Selecting this solves the problem although it obviously leaves me vulnerable if I browse to infected sites.

I have logged this with Kaspersky in case there is a work around whereby Kaspersky populates the keyfile.

Many thanks to those who helped.

PCrossley ( 2022-02-04 23:02:35 +0000 )edit

Thanks for that - this is the missing piece of the puzzle. Turning off the encypted network scan from settings->network settings solved the problem.

PCrossley ( 2022-02-04 23:04:52 +0000 )edit

add a comment

answered 2022-02-02 08:25:11 +0000

SYN-bit

18528 ●9 ●338 ●255 https://SYN-b.it

If there are keys in C:\Users\ptcro\Documents\Wireshark\keylogfile.txt (which I assume is the file you used for SSLKEYLOGFILE in your script), then Chrome did pick it up. Could it be that there are Java components in the website? Or maybe other parts of the website that do not use the SSL/TLS library of Chrome? In that case, the session keys of those sessions will not get logged.

Is the site you are trying to access public so I can try myself?

edit flag offensive delete link

Comments

Thanks for the quick response. I was browsing to https://www.chappell-university.com/ Its quite a simple page.

I had a similar experience browsing to https://www.wireshark.org/ Here's a part of the debug trace from that - client was firefox Frame 1615 is server hello and change cypherspec

dissect_ssl enter frame #1615 (first time)
packet_from_server: is from server - TRUE
  conversation = 000002421E662FF0, ssl_session = 000002421E665340
  record: offset = 0, reported_length_remaining = 1220
ssl_try_set_version found version 0x0303 -> state 0x91
dissect_ssl3_record: content_type 22 Handshake
decrypt_ssl3_record: app_data len 122, ssl state 0x91
packet_from_server: is from server - TRUE
decrypt_ssl3_record: using server decoder
decrypt_ssl3_record: no decoder available
dissect_ssl3_handshake iteration 1 type 2 offset 5 length 118 bytes
ssl_try_set_version found version 0x0304 -> state 0x91
ssl_dissect_hnd_hello_common found SERVER RANDOM -> state 0x93
ssl_set_cipher found CIPHER 0x1301 TLS_AES_128_GCM_SHA256 -> state 0x97
trying to use TLS keylog in C:\Users\ptcro\Documents\Wireshark\keylogfile.txt
  checking keylog line: CLIENT_HANDSHAKE_TRAFFIC_SECRET ...

(more)

PCrossley ( 2022-02-02 12:39:30 +0000 )edit

Ran out of space - heres the rest of the log for that packet I note that at the end of my previous comment it found the keylog line "CLIENT_HANDSHAKE_TRAFFIC SECRET" and the line ended "matched client_handshake"

Yet in this end section it says "cannot find CLIENT_HANDSHAKE_TRAFFIC_SECRET"

  checking keylog line: CLIENT_TRAFFIC_SECRET_0 23663dbcee04093c9dc7a63672cd27a75530c4a9e95a4aba384eb7ba13a57504 99f8c11d5d5372850e6512254eb4bd76db25ddfa533cf10e8202bbd50b74c9a0
    matched client_appdata
  checking keylog line: SERVER_TRAFFIC_SECRET_0 23663dbcee04093c9dc7a63672cd27a75530c4a9e95a4aba384eb7ba13a57504 ec7528c4b99d80275efcb1654c291af4c976c1b2aa0af1a069ce4eb45cd153d3
    matched server_appdata
  checking keylog line: EXPORTER_SECRET 23663dbcee04093c9dc7a63672cd27a75530c4a9e95a4aba384eb7ba13a57504 fab17de5057678ee8d1cbacc94d1a3bfca29b978c4b188c946bcd379d6762528
    matched exporter
tls13_load_secret transitioning to new key, old state 0x97
tls13_load_secret Cannot find CLIENT_HANDSHAKE_TRAFFIC_SECRET, decryption impossible
tls13_load_secret transitioning to new key, old state 0x97
tls13_load_secret Cannot find SERVER_HANDSHAKE_TRAFFIC_SECRET, decryption impossible
  record: offset = 127, reported_length_remaining = 1093
dissect_ssl3_record: content_type 20 Change Cipher Spec
  record: offset = 133, reported_length_remaining = 1087
  need_desegmentation: offset = 133, reported_length_remaining = 1087

PCrossley ( 2022-02-02 12:43:45 +0000 )edit

I tried with google to see if I could reproduce the issue and had no issues:

dumpcap -s0 -w google-tlsv13.pcapng -f "host www.google.com" &
export SSLKEYLOGFILE=google-tlsv13.keys
curl -D- -4 -o/dev/null --tlsv1.3 https://www.google.com
kill %1
tshark -o tls.keylog_file:google-tlsv13.keys -o tls.debug_file:tls-debug.log -r google-tlsv13.pcapng -Y http2

I did see in the log file that there is a match on any of the lines in the SSLKEYLOGFILE, which is weird, as there is only one session in the trace, so it could not match all of the lines. So based on that, I suspect that the keys for your specific TLS session are not in the log file. You can check whether the keys that belong to the session in the pcap are actually in the keylogfile, by printing the random of the ClientHello and check ...(more)

SYN-bit ( 2022-02-02 12:52:06 +0000 )edit

Well the whole thing is curious. I installed an Ubuntu VM so that I could run your grep script on my files (it will be useful if I need to do such things again). But as expected the command found no matches between the random numbers and the keylogfile.

So we know that keys are going into the file but that doesnt seem to include the ones I want. I changed my script to use a different filename just in case I had some other process using that file but I get the same result - keys go in - I point wireshark to the new file but there arent any matches.

You appear to have tested this on Linux - could it be a windows issue ?

(I just tried it with Wireshark 3.4.7 and Firefox 96.0.3 on my Linux VM and it worked fine)

PCrossley ( 2022-02-02 16:30:11 +0000 )edit

What happens if you do the steps manually without your script? And could you post the script you are using?

SYN-bit ( 2022-02-02 16:58:17 +0000 )edit

see more comments

answered 2022-02-02 08:13:57 +0000

hugo.vanderkooij
76 ●190 ●4

I think you missed the list of exceptions. One of them: The protocol version is SSLv3, (D)TLS 1.0-1.2. It does not work with TLS 1.3.

edit flag offensive delete link

Comments

Using SSLKEYLOGFILE does work with TLSv1.3. Using the RSA private key will indeed not work, but @PCrossley is using the SSLKEYLOGFILE method.

SYN-bit ( 2022-02-02 08:21:51 +0000 )edit

Thans for the suggestion but I did read the list of exceptions but it doesn't apply.

The exception you refer to applies to using the RSA key from the server. TLS1.3 encrypts the handshake with a Diffie Helman exchange and only uses the server key for authentication. - having the server key wont allow you to decrypt packets.

I however am using the alternative method with a key log file on the client. This is the method that is sai to work under all circumstances. The key log file contains the pre-master secret exported from the client when the environment variable is set (the requirement for export of keys from client is in an RFC and is widely supported by TLS libraries).

My reading of the diagnostic trace file shows that the keylogfile has been searched and a match has been found but I am then told that no ...(more)

PCrossley ( 2022-02-02 12:19:26 +0000 )edit

add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

cant decrypt TLSv1.3 with Kaspersky Total Security installed

3 Answers

Comments

Comments

Comments

Your Answer

Question Tools

Stats

Related questions

cant decrypt TLSv1.3 with Kaspersky Total Security installed edit

3 Answers

Comments

Comments

Comments

Your Answer

Question Tools

Stats

Related questions

cant decrypt TLSv1.3 with Kaspersky Total Security installed