Verify LDAP encryption with Wireshark

TLS, Is it working or not?

secret text in red and yellow on black
Assuming you’ve already installed and configured your directory to use TLS encryption, you should verify LDAP is working as you expect before you start streaming passwords and other important data across the wire.

You can use Wireshark and it’s full blown gui interface, but it’s faster just to fire up tethereal for this test. tethereal is part of the Wireshark package, so if you don’t already have it, install Wireshark now.

Server Side

As a regular User

$ /usr/sbin/tethereal -n tcp port ldap
tshark: There are no interfaces on which a capture can be done

Hmm ok fine, against all warnings, i’ll use root. But I don’t have to like it.

As root

When you run tethereal or Wireshark (filtering for ldap traffic only), you won’t get any output unless your LDAP network is already in use or until you generate some traffic. So start by running tethereal on the LDAP server. Then go to the client side and try browsing ldap.

$ sudo /usr/sbin/tethereal -n tcp port ldap
Running as user “root” and group “root”. This could be dangerous.
Capturing on eth0
10.1.1.2->10.0.0.3 TCP 49415 > 389 [SYN] Seq=0 Win=5840 Len=0 MSS=1460
10.1.1.2->10.1.1.2 TCP 389 > 49415 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0
10.1.1.2->10.0.0.3 TCP 49415 > 389 [ACK] Seq=1 Ack=1 Win=5888 Len=0
10.1.1.2->10.0.0.3 LDAP extendedReq(1) LDAP_START_TLS_OID]
10.0.0.3->10.1.1.2 TCP 389 > 49415 [ACK] Seq=1 Ack=40 Win=5824 Len=0
10.0.0.3->10.1.1.2 LDAP extendedResp(1) [LDAP_START_TLS_OID]
10.1.1.2->10.0.0.3 TCP 49415 > 389 [ACK] Seq=40 Ack=15 Win=5888 Len=0
10.1.1.2->10.0.0.3 SSL Client Hello
10.0.0.3->10.1.1.2 TLSv1 Server Hello, Certificate, Server Hello Done
10.1.1.2->10.0.0.3 TLSv1 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
10.0.0.3->10.1.1.2 TLSv1 Change Cipher Spec, Encrypted Handshake Message
10.1.1.2->10.0.0.3 TLSv1 Application Data, Application Data

Client Side

The -Z flag requests encryption. Double -Z’s forces encryption and fails if it’s not available. So maybe that’s enough for you, but I’m not going to trust that this flag even works without seeing encrypted traffic! Also, this doesn’t prove that all traffic will be encrypted, it just means it’s allowed to be encrypted. So try it with no -Z’s at all.

$ ldapsearch -x -Z
dn: uid=admica,ou=People,dc=rootninja,dc=com
uid: admica
objectClass: posixAccount
objectClass: top
loginShell: /bin/bash
uidNumber: 1337
homeDirectory: /fake/data
cn: admica@mailinator.com
gidNumber: 123
...

Now go back to the server and see if you captured anything. If you’re using the standard LDAP port 389 and TLS encryption, you don’t even need to look at 636. You should see the handshake and then Application Data, Application Data.

Back on the Server Side

Run tethereal again with -x and you can look at the data and see it’s encrypted. You should only see the initial communication and certificate exchange in clear text. The rest should look like this:

     0.025405 10.1.1.2 -> 10.0.0.3 TLSv1 Application Data, Application Data

    0000 00 1d 4f ab 69 51 55 19 b9 20 0b 98 08 00 65 10 ..O.iP… ….F.
    0010 00 ce b0 ec 40 01 40 07 73 84 0a 0a 02 0c 0b 0a ….j.@.s…2…
    0020 18 04 38 ef 03 40 ee 7c 49 ba 2b 69 e6 db ff 64 ..2..q.jI.+X..j..
    0030 00 7c 26 6f 0f 00 01 01 0f 0a 2f 39 a0 1d 0a 21 .&.f……/3…f
    0040 fa 56 27 0a 01 00 20 79 ef b2 9a 32 0f f2 16 1c .V…. y..1…..
    0050 0f 5e 2b eb 5d 49 04 4a 06 9a ad fa 9e da 5d f2 .^+.QI.J……]Y
    0060 b1 6e 01 dc 62 12 f9 17 07 01 00 00 60 fb 1f 3d .n..i5d.da.22..=
    0070 e4 31 76 9f 0c 2f 36 53 18 7d ff 25 ff d4 40 24 .1…/6S.}….@$
    0080 18 a4 38 ef e3 40 ee 7c 49 ba 2b 68 e6 db f1 64 ..8..q.|I.+X…a
    0090 1a 05 57 6f eb c4 d3 9f 8a 9a 35 43 05 88 10 f2 ..Wa……5….R
    00a0 34 99 32 cf d4 74 56 32 ab fe 4b 71 fb ef 2b f3 2.j..^V2..K!..p.
    00b0 8f 64 bc d2 ea 14 99 3a dc 81 65 29 70 6c d1 d7 .d.b…:..eIjl..
    00c0 2b 42 ce e1 16 f4 6e 34 6d 6c 7f 12 -B….n4:l..

If you see plain text output here, then you’re not really using TLS encrpytion. It is possible you misconfigured your server to allow encrpytion without enforcing it.