[Andrew Hadenfeldt <andrewhadenfeldt@xxxxxxxxx>]

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@xxxxxxxxxxxxx> wrote:

Send Wireshark-users mailing list submissions to
        wireshark-users@xxxxxxxxxxxxx

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@xxxxxxxxxxxxx

You can reach the person managing the list at
        wireshark-users-owner@xxxxxxxxxxxxx

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@xxxxxxxxx>
To: wireshark-users@xxxxxxxxxxxxx
Subject: [Wireshark-users] Analyzing TLS handshake packets
Message-ID:
        <CANUrE6mpPWvg8UPxyqOu2ignvofTBfZ+s14MkK+UrRGKUn1tDg@xxxxxxxxxxxxxx>
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@xxxxxxxxxxxxx>
To: Community support list for Wireshark
        <wireshark-users@xxxxxxxxxxxxx>, Manjesh HS <manjesh29hs@xxxxxxxxx>,
        wireshark-users@xxxxxxxxxxxxx
Subject: Re: [Wireshark-users] Analyzing TLS handshake packets
Message-ID: <0E240BD5-E915-45D9-96A5-0957399396B3@xxxxxxxxxxxxx>
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@xxxxxxxxx> 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@xxxxxxxxxxxxx
https://www.wireshark.org/mailman/listinfo/wireshark-users


------------------------------

End of Wireshark-users Digest, Vol 139, Issue 7
***********************************************