Hello!
I've faced with problem decryption traffic between Exchange and another server that uses Exchange Web Services. I see handshake in traces, but no decoder available. What could be the problem?
Wireshark SSL debug log
ssl_association_remove removing TCP 443 - http handle 000000000599FAE0
3489 bytes read
PKCS#12 imported
Bag 0/0: PKCS#8 Encrypted key
Private key imported: KeyID d9:f3:bc:7f:67:bf:bf:85:49:49:02:2f:d4:33:02:e3:…
ssl_load_key: swapping p and q parameters and recomputing u
Bag 1/0: Encrypted
Bag 1/0 decrypted: Certificate
Certificate imported: ruspbvm3209.swc02.tlab.alcatel.ru <<error>>, KeyID d9f3bc7f67bfbf854949022fd43302e3cac7a182
ssl_init IPv4 addr '172.17.3.209' (172.17.3.209) port '443' filename 'C:\Users\pkropach\Desktop\ca-exch.pfx' password(only for p12 file) '123'
ssl_init private key file C:\Users\pkropach\Desktop\ca-exch.pfx successfully loaded.
association_add TCP port 443 protocol http handle 000000000599FAE0
dissect_ssl enter frame #48 (first time)
ssl_session_init: initializing ptr 0000000007342690 size 712
association_find: TCP port 48689 found 0000000000000000
packet_from_server: is from server - FALSE
conversation = 0000000006941908, ssl_session = 0000000007342690
record: offset = 0, reported_length_remaining = 37
dissect_ssl3_record found version 0x0301(TLS 1.0) -> state 0x10
dissect_ssl3_record: content_type 21 Alert
decrypt_ssl3_record: app_data len 32, ssl state 0x10
association_find: TCP port 48689 found 0000000000000000
packet_from_server: is from server - FALSE
decrypt_ssl3_record: using client decoder
decrypt_ssl3_record: no decoder available
dissect_ssl enter frame #3522 (first time)
ssl_session_init: initializing ptr 00000000073A6C40 size 712
association_find: TCP port 62166 found 0000000000000000
packet_from_server: is from server - FALSE
conversation = 000000000695EA68, ssl_session = 00000000073A6C40
record: offset = 0, reported_length_remaining = 230
dissect_ssl3_record: content_type 22 Handshake
decrypt_ssl3_record: app_data len 225, ssl state 0x00
association_find: TCP port 62166 found 0000000000000000
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 221 bytes, remaining 230
packet_from_server: is from server - FALSE
ssl_find_private_key server 172.17.3.209:443
ssl_find_private_key: testing 1 keys
dissect_ssl3_hnd_hello_common found CLIENT RANDOM -> state 0x01
dissect_ssl enter frame #3524 (first time)
packet_from_server: is from server - TRUE
conversation = 000000000695EA68, ssl_session = 00000000073A6C40
record: offset = 0, reported_length_remaining = 2065
dissect_ssl3_record found version 0x0301(TLS 1.0) -> state 0x11
dissect_ssl3_record: content_type 22 Handshake
decrypt_ssl3_record: app_data len 2060, ssl state 0x11
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 2065
dissect_ssl3_hnd_hello_common found SERVER RANDOM -> state 0x13
dissect_ssl3_hnd_srv_hello found CIPHER 0xC013 -> state 0x17
dissect_ssl3_hnd_srv_hello trying to generate keys
ssl_generate_keyring_material not enough data to generate key (0x17 required 0x37 or 0x57)
dissect_ssl3_hnd_srv_hello can't generate keyring material
dissect_ssl3_handshake iteration 0 type 11 offset 86 length 1640 bytes, remaining 2065
dissect_ssl3_handshake iteration 0 type 12 offset 1730 length 327 bytes, remaining 2065
dissect_ssl3_handshake iteration 0 type 14 offset 2061 length 0 bytes, remaining 2065
dissect_ssl enter frame #3529 (first time)
packet_from_server: is from server - FALSE
conversation = 000000000695EA68, ssl_session = 00000000073A6C40
record: offset = 0, reported_length_remaining = 75
dissect_ssl3_record: content_type 22 Handshake
decrypt_ssl3_record: app_data len 70, ssl state 0x17
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 16 offset 5 length 66 bytes, remaining 75
ssl_generate_pre_master_secret: found SSL_HND_CLIENT_KEY_EXCHG, state 17
ssl_decrypt_pre_master_secret session uses DH (17) key exchange, which is impossible to decrypt
ssl_generate_pre_master_secret: can't decrypt pre master secret
trying to use SSL keylog in
failed to open SSL keylog
dissect_ssl3_handshake can't generate pre master secret
dissect_ssl enter frame #3533 (first time)
packet_from_server: is from server - FALSE
conversation = 000000000695EA68, ssl_session = 00000000073A6C40
record: offset = 0, reported_length_remaining = 6
dissect_ssl3_record: content_type 20 Change Cipher Spec
dissect_ssl3_change_cipher_spec
packet_from_server: is from server - FALSE
ssl_change_cipher CLIENT
dissect_ssl enter frame #3536 (first time)
packet_from_server: is from server - FALSE
conversation = 000000000695EA68, ssl_session = 00000000073A6C40
record: offset = 0, reported_length_remaining = 53
dissect_ssl3_record: content_type 22 Handshake
decrypt_ssl3_record: app_data len 48, ssl state 0x17
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 211 offset 5 length 16071396 bytes, remaining 53
asked 13 Dec ‘15, 04:53
pavelnt
6●2●3●4
accept rate: 0%
Is it normal that I see
ssl_decrypt_pre_master_secret session uses DH (17) key exchange, which is impossible to decrypt
not for all pcap traces?
It is normal if you talk about traces taken between different endpoints; it would be weird if two ssl negotiations between the same endpoints (i.e. same applications, not just same IP addresses) would use different session key establishment methods.
I receive traces from the same machine. But I don't see "ssl_decrypt_pre_master_secret session uses DH (17) key exchange".
Wireshark SSL debug log
ssl_association_remove removing TCP 443 - http handle 0000000005613710 3489 bytes read PKCS#12 imported Bag 0/0: PKCS#8 Encrypted key Private key imported: KeyID d9:f3:bc:7f:67:bf:bf:85:49:49:02:2f:d4:33:02:e3:... ssl_load_key: swapping p and q parameters and recomputing u Bag 1/0: Encrypted Bag 1/0 decrypted: Certificate Certificate imported: ruspbvm3209.swc02.tlab.alcatel.ru <<error>>, KeyID d9f3bc7f67bfbf854949022fd43302e3cac7a182 ssl_init IPv4 addr '172.17.3.209' (172.17.3.209) port '443' filename 'C:\Users\pkropach\Desktop\ca-exch.pfx' password(only for p12 file) '123' ssl_init private key file C:\Users\pkropach\Desktop\ca-exch.pfx successfully loaded. association_add TCP port 443 protocol http handle 0000000005613710
dissect_ssl enter frame #50 (first time) ssl_session_init: initializing ptr 0000000009283F50 size 712 association_find: TCP port 52511 found 0000000000000000 packet_from_server: is from server - FALSE conversation = 00000000066E1D78, ssl_session = 0000000009283F50 record: offset = 0, reported_length_remaining = 37 dissect_ssl3_record found version 0x0301(TLS 1.0) -> state 0x10 dissect_ssl3_record: content_type 21 Alert decrypt_ssl3_record: app_data len 32, ssl state 0x10 association_find: TCP port 52511 found 0000000000000000 packet_from_server: is from server - FALSE decrypt_ssl3_record: using client decoder decrypt_ssl3_record: no decoder available
I receive traces from Linux computer that connects to Exchange server. I'd like to see response from Exchange server, because I have problem with bad request (http 400).
as for the ssl decoder behaviour, I don't have enough information. I'd filter each tcp session into a separate pcap file and only if the SSL debug log would still say something different for packets with same role in those individual sessions, I'd start to worry. I cannot imagine why the same client and server would use DH key negotiation for one session and other negotiation method for another one. I cannot see the "handshake" keyword in the logs you've posted in the comment. (hint: if the comment is still editable for you, put 4 spaces before each line of the log, it will be much more readable)
Wireshark can only decrypt a flow if the key negotiation phase is available in the capture (which is a necessary condition but not a sufficient one) or if you provide it with the private (deciphering) keys of both parties in some other way.
As for the real task you need to accomplish, i.e. quite off-topic wrt the initial decryption question: capturing the exchange on the network can tell you what has happened but not why it has happened. So if you get "400 Bad Request" final response to your request, you cannot expect a detailed (or even correct) explanation of what the server does not like about your request. Most often there is no explanation at all.
So if your real goal is to find out why the server does not like your client's request, the first place to look for explanation is the server's error log. I suppose you know what you are sending in your request; if you are not sure, run a web server on linux, let it log the incoming requests' contents in detail, and let your linux client send the request to it instead of the Exchange. It should be much faster than fiddling around with decryption.