Packet Capture Decryption
-
Capturing encrypted SMTP traffic on the WAN interface and providing the private key in Wireshark it is decrypted just fine for a Windows Live email client session. But cannot decrypt the capture of a pfSense Notify session.
What is different about the pfSense SMTP client? It’s as though it is not using the SMTP servers certificate.
-
Did the start of the client/server exchange in both cases look the same? (e.g. STARTTLS or straight SSL/TLS) You should be able to see the certificate negotiation and such at least.
-
The same up through 6th packet (TLSv1 Server Hello). After that they diverge a bit but both are successful at sending the message. But Wireshark cannot decrypt the pfSense notify sent message even though both cases should be using the same cert and private key.
The Wireshark SSL Debug log has this line about DH key exchange being impossible to decrypt.
Session from other SMTP client does not have that. Guessing this is the issue. But don't know how to change it so that it can be decrypted.dissect_ssl enter frame #13 (first time) conversation = 058D184C, ssl_session = 058D1CD0 record: offset = 0, reported_length_remaining = 198 dissect_ssl3_record: content_type 22 Handshake decrypt_ssl3_record: app_data len 134, 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 130 bytes, remaining 139 ssl_decrypt_pre_master_secret session uses DH (17) key exchange, which is impossible to decrypt dissect_ssl3_handshake can't decrypt pre master secret record: offset = 139, reported_length_remaining = 59 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 record: offset = 145, 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 166 offset 150 length 16733742 bytes, remaining 198 -
Not sure I'd want to cripple it to make it less secure… :-)
http://ask.wireshark.org/questions/17630/cant-decrypt-tlsv1-traffic
-
Not permanently no. But temporarily for investigation yes.
Where I'm head is trying to determine what is going on with port 587 with SSL/TLS enabled that prevents it from working.
Now I'm guessing the reason has to do with the SMTP server config maybe not compatible with DH.
Port 445 (smtps) uses tls wrappermode and port 587 (submission) uses tls security level encrypt.Where would this be changed in pfSense? Thinking it may be easier to verify by temporarily changing pfSense test bed before going and messing around with the mail server config.
Mail server config snipit.
submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING smtps inet n - n - - smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING -
Looks like in /etc/inc/smtp.inc we compose the fsockopen url with ssl:// if SSL is enabled, apparently there is also a tls:// prefix.
Perhaps there needs to be an extra option to control the switch somewhere. Instead of an SSL checkbox, a drop-down: No Encryption / SSL / TLS
-
Or maybe it might need a nudge another way… http://php.net/stream_socket_enable_crypto
-
Hard coding TLS in /etc/smtp.inc does not seem to change the behavior for ether being able to decrypt or port 587 working.
-
There are also other choices there (sslv2, sslv3) do those make any difference?
-
Tried those. Don't recall the exact result but it did not work.
From some network captures it looks like pfSense always insists on "wrapper mode". After the TCP connection is made pfSense immediately sends client hello and then ignores the initial STMP 220 response.