![]() You 're right seems that the browser even after refresh sometimes remembers previous session IDs and reuses them, which explains why Cert wasn't sent by server in ServerHello and wireshark couldn't correlate. The ServerHello has a Certificate and this is how it look in SSL debug (notice the additional fields on the bottom):ĭissect_ssl enter frame #320 (first time) packet_from_server: is from server - TRUE conversation = 0x12166b840, ssl_session = 0x12166c420 record: offset = 0, reported_length_remaining = 821 ssl_try_set_version found version 0x0301 -> state 0x91 dissect_ssl3_record: content_type 22 Handshake Calculating hash with offset 5 816 decrypt_ssl3_record: app_data len 816, 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 77 bytes, remaining 821 ssl_try_set_version found version 0x0301 -> state 0x91 ssl_dissect_hnd_hello_common found SERVER RANDOM -> state 0x93 ssl_dissect_hnd_srv_hello found CIPHER 0x002F TLS_RSA_WITH_AES_128_CBC_SHA -> state 0x97 dissect_ssl3_handshake iteration 0 type 11 offset 86 length 727 bytes, remaining 821 lookup(KeyID): | ea 6b 53 25 49 89 f8 29 a7 11 fd 9f 2f 97 88 6a |.kS%I.)./.j| | fd 8f 24 5b |.$[ | ssl_find_private_key_by_pubkey: lookup result: 0x7fc814867400 dissect_ssl3_handshake iteration 0 type 14 offset 817 length 0 bytes, remaining 821 pcap! Is this somehow legit? I then checked the SSL debug file more information and I saw only this:ĭissect_ssl enter frame #346 (first time) packet_from_server: is from server - TRUE conversation = 0x116b9fbb0, ssl_session = 0x116ba0fd0 record: offset = 0, reported_length_remaining = 86 ssl_try_set_version found version 0x0303 -> state 0x91 dissect_ssl3_record: content_type 22 Handshake Calculating hash with offset 5 81 decrypt_ssl3_record: app_data len 81, 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 77 bytes, remaining 86 ssl_try_set_version found version 0x0303 -> state 0x91 ssl_dissect_hnd_hello_common found SERVER RANDOM -> state 0x93 ssl_dissect_hnd_srv_hello found CIPHER 0x002F TLS_RSA_WITH_AES_128_CBC_SHA -> state 0x97Īlso, here's another, successful scenario where I use plain TLS (i.e. I did some more digging after you mentioned pubkey in the debug file and I realized that there is no Certificate in the ServerHello in the. The problem is that the issue still occurs :(. Used 2.2.3, but updated to 2.2.7 to make sure it's not an issue with previous version. So let me try to answer your questions: a. Thanks a lot in advance, Antonis Tsakiridis ![]() But I see this issue: 'decrypt_ssl3_record: no decoder available'. I then checked for a specific frame that shows up as TLSv1.2 Application Data and which I would expect to be decrypted. I introduced an SSL debug file from Preferences > Protocols > SSL > SSL debug file to figure out what is going on under the hood and the private key seems successfully loaded (based on the first lines of the log).For some reason even after previous step the traffic still shows up decrypted.pem is correct and works with wireshark by testing it with regular TLS traffic, where decryption works fine) pem format (notice that I have tested that this. ![]() Where: 5083 is the server port for WSS, and server.key is the private key of the server in.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |