Wireshark mailing list archives
Re: Analyzing TLS handshake packets
From: Andrew Hadenfeldt <andrewhadenfeldt () gmail com>
Date: Mon, 18 Dec 2017 00:10:39 +0000
Your screenshot shows you connecting to port 389 instead of the usual LDAPS port (636). I don't see STARTTLS messages either. Are you truly running LDAPS on 389? On Sat, Dec 16, 2017 at 6:00 AM <wireshark-users-request () wireshark org> wrote:
Send Wireshark-users mailing list submissions to wireshark-users () wireshark org To subscribe or unsubscribe via the World Wide Web, visit https://www.wireshark.org/mailman/listinfo/wireshark-users or, via email, send a message with subject or body 'help' to wireshark-users-request () wireshark org You can reach the person managing the list at wireshark-users-owner () wireshark org When replying, please edit your Subject line so it is more specific than "Re: Contents of Wireshark-users digest..." Today's Topics: 1. Analyzing TLS handshake packets (Manjesh HS) 2. Re: Analyzing TLS handshake packets (Peter Wu) ---------------------------------------------------------------------- Message: 1 Date: Thu, 14 Dec 2017 16:21:11 +0530 From: Manjesh HS <manjesh29hs () gmail com> To: wireshark-users () wireshark org Subject: [Wireshark-users] Analyzing TLS handshake packets Message-ID: < CANUrE6mpPWvg8UPxyqOu2ignvofTBfZ+s14MkK+UrRGKUn1tDg () mail gmail com> Content-Type: text/plain; charset="utf-8" Hi Wireshark User Community, In my project, there is a LDAP client utility and a LDAP server utility running on different nodes in the TCP/IP network. There is a need to establish TLS (LDAPS) connection mode of communication between them in order to exchange some information. This functionality is broken recently. A TCP dump file was generated on the problematic setup to analyze the TLS handshake mechanism. When it was analyzed through Wireshark tool, it is reporting that the "Client Hello" packet generated by LDAPS client utility (the one that initiates TLS handshake), as a malformed packet by reporting an error as "compression methods length", incompatible as per the protocol specifications. We are suspectingthat the TLS protocol specifications are violated during this TLS handshake. The screenshot of the same has been attached with this mail. How this issue can happen ? What are the factors that can lead to such an issue ? Is it an issue with incompatible versions of openSSL/TLS/cipher suite between client and server ? Please share your suggestions/comments in order to investigate this issue further. - Manjesh. -------------- next part -------------- An HTML attachment was scrubbed... URL: < https://www.wireshark.org/lists/wireshark-users/attachments/20171214/6bc48cdd/attachment.html-------------- next part -------------- A non-text attachment was scrubbed... Name: screenshot_1.png Type: image/png Size: 61056 bytes Desc: not available URL: < https://www.wireshark.org/lists/wireshark-users/attachments/20171214/6bc48cdd/attachment.png------------------------------ Message: 2 Date: Sat, 16 Dec 2017 10:42:35 +0000 From: Peter Wu <peter () lekensteyn nl> To: Community support list for Wireshark <wireshark-users () wireshark org>, Manjesh HS <manjesh29hs () gmail com,wireshark-users () wireshark org Subject: Re: [Wireshark-users] Analyzing TLS handshake packets Message-ID: <0E240BD5-E915-45D9-96A5-0957399396B3 () lekensteyn nl> Content-Type: text/plain; charset=utf-8 Hi Manjesh, Is it possible to attach a pcap with just the Client Hello message (and optionally the messages preceding it)? This looks quite unusual, normally the compression methods length is 1 (for null compression). 97 in hex is 0x61 which is the ASCII 'a' character and only occurs in the codepoint of an obscure cipher (0xC0,0x61 TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384). (A lot of cipher suites precede your compression methods, so if the problem was LF -> CRLF conversion, then perhaps one of the cipher shifted. That does not appear to be the case though.) My guess is that an error message is somehow written to the same file descriptor as the socket. But without pcap it is hard to tell. Kind regards, Peter https://lekensteyn.nl (pardon my brevity, top-posting and formatting, sent from my phone) On 14 December 2017 10:51:11 GMT+00:00, Manjesh HS <manjesh29hs () gmail com> wrote:Hi Wireshark User Community, In my project, there is a LDAP client utility and a LDAP server utility running on different nodes in the TCP/IP network. There is a need to establish TLS (LDAPS) connection mode of communication between them in order to exchange some information. This functionality is broken recently. A TCP dump file was generated on the problematic setup to analyze the TLS handshake mechanism. When it was analyzed through Wireshark tool, it is reporting that the "Client Hello" packet generated by LDAPS client utility (the one that initiates TLS handshake), as a malformed packet by reporting an error as "compression methods length", incompatible as per the protocol specifications. We are suspectingthat the TLS protocol specifications are violated during this TLS handshake. The screenshot of the same has been attached with this mail. How this issue can happen ? What are the factors that can lead to such an issue ? Is it an issue with incompatible versions of openSSL/TLS/cipher suite between client and server ? Please share your suggestions/comments in order to investigate this issue further. - Manjesh.------------------------------ Subject: Digest Footer _______________________________________________ Wireshark-users mailing list Wireshark-users () wireshark org https://www.wireshark.org/mailman/listinfo/wireshark-users ------------------------------ End of Wireshark-users Digest, Vol 139, Issue 7 ***********************************************
___________________________________________________________________________ Sent via: Wireshark-users mailing list <wireshark-users () wireshark org> Archives: https://www.wireshark.org/lists/wireshark-users Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users mailto:wireshark-users-request () wireshark org?subject=unsubscribe
Current thread:
- Analyzing TLS handshake packets Manjesh HS (Dec 15)
- Re: Analyzing TLS handshake packets Peter Wu (Dec 16)
- <Possible follow-ups>
- Re: Analyzing TLS handshake packets Andrew Hadenfeldt (Dec 17)