Debugging SSL

Debugging SSL application sometimes is not easy, the data is encrypted, so you need some special tool to do it. First you will need:

  1. ssldump
  2. server key
  3. a knowledge about SSL protocol

Note:This is an experience that i got when i'm having trouble integrating SSL support for a Wireless Point Of Sale device (Nurit from Lipman), so your problem might be different from mine .

Cipher problem

My first problem that i encountered is that the SSL connection is terminated while doing handshaking. From the ssldump output i know that the client are offering some Cipher to the Server, and after checking the Cipher support on the server, it turns out that i have to use the RSA key (and not the DSA key that i was using). SSL protocol may not be compatible, thats why you must check cipher support on both side.

To dump basic protocol things like this (i.e: not the content of the data), you won't need the server key

Data Problem

Next problem was: the data won't completely decoded on the client side. (as a note: The Nurit only supports blocking socket.) It turns out that SSL will have a 16Kb frame, and my buffer was only 1 kb (and somehow the next data is not received on the second call of the TCPAPI_Read systeml call), increasing the buffer to 16kb solves the problem.

To see the data passed from the client to server, you will need the server key (to decrypt the message), use the -k parameter to pass the keyname (see the manual for more information). If your server uses Java, you will need few step to convert the keystore format to PEM (openssl format).

Cipher problem

My first problem that i encountered is that the SSL connection is terminated while doing handshaking. From the ssldump output i know that the client are offering some Cipher to the Server, and after checking the Cipher support on the server, it turns out that i have to use the RSA key (and not the DSA key that i was using). SSL protocol may not be compatible, thats why you must check cipher support on both side.

To dump basic protocol things like this (i.e: not the content of the data), you won't need the server key

Data Problem

Next problem was: the data won't completely decoded on the client side. (as a note: The Nurit only supports blocking socket.) It turns out that SSL will have a 16Kb frame, and my buffer was only 1 kb (and somehow the next data is not received on the second call of the TCPAPI_Read systeml call), increasing the buffer to 16kb solves the problem.

To see the data passed from the client to server, you will need the server key (to decrypt the message), use the -k parameter to pass the keyname (see the manual for more information). If your server uses Java, you will need few step to convert the keystore format to PEM (openssl format).