Re: Analyzing TLS handshake packets

[Andrew Hadenfeldt <andrewhadenfeldt () gmail com>]

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