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.


  • Rebel Alliance Developer Netgate

    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 
    
    

  • Rebel Alliance Developer Netgate

    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
    
    

  • Rebel Alliance Developer Netgate

    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


  • Rebel Alliance Developer Netgate

    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.


  • Rebel Alliance Developer Netgate

    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.


Locked