Hello,

Is there something in Linux that might hinder an SSL Handshake?

I know almost nothing about Linux. My client application works fine on Windows. It connects to a external server via SSLSocket. To do so, there is a handshake protocol to manage certificates issue. That occurs below my application.

The fact is that when I run the same application on Linux machines, the handshake is not completed. The application sends the ClientHello and receives the ServerHello. Then it should reveive a server certificate, but it doesn't. After a few seconds the connection times out.

I tried in Linux Red Hat 7.3, REHL4.3 and CentOS. The problem is always the same.


In all my tests (on Windows and Linux):
- The network and proxy are the same.
- The JDK are almost the same (jre1.4.2_03 and jre1.4.2_13).
- The keystores are the same, so the certificates.

The only difference that I find is that the length of the ClientHello that I send on Windows PCs is 98, and on Linux it is 77, but this is something that I can't handle.

So, to me, it seems that the problem lies on the OS Linux. Is there any Linux security directive, any service, anything that might affect ssl communications?

Thank you.

i'd suggest getting a copy of wireshark and actaully exploring the ssl handshake in more detail. these sorts of issues have usually been down to incompatible cipher specs when they've caught me up.

I used Ethereal to monitor the handshake. After establishing the SSL Session, in Windows the client receives two mesages:

- Server Hello Certificate [Unreassembled packet], which is 1380 bytes long.
- Continuation Data [Unreassembled packet], which is 705 bytes long.

In Linux, the client receives the following:

%% Created: [Session-1, SSL_RSA_WITH_RC4_128_SHA]
** SSL_RSA_WITH_RC4_128_SHA
[read] MD5 and SHA1 hashes: len = 74
0000: 02 00 00 46 03 01 45 D5 AA 44 68 02 76 87 D9 0E ...F..E..Dh.v...
0010: 53 A0 DB 97 CF 56 11 CA E3 8B 5F 30 44 26 2E 6F S....V...._0D&.o
0020: CD 8C A9 DD 31 B4 20 6F ED F5 9F 91 C0 AD 97 68 ....1. o.......h
0030: BE FD 59 62 C6 B5 86 30 1D 39 90 03 06 09 7C E3 ..Yb...0.9......
0040: DA 6C A8 10 FE C3 B7 00 05 00 .l........
[Raw read]: length = 5
0000: 16 03 01 08 18 .....
[Raw read]: length = 1376
0000: 0B 00 08 14 00 08 11 00 04 84 30 82 04 80 30 82 ..........0...0.
0010: 03 E9 A0 03 02 01 02 02 10 62 76 EC A2 A8 88 DA .........bv.....
0020: 1A 17 11 83 6B F0 1D A9 22 30 0D 06 09 2A 86 48 ....k..."0...*.H
...........lots of bytes till the end of the message..........
0540: 30 81 BA 31 1F 30 1D 06 03 55 04 0A 13 16 56 65 0..1.0...U....Ve
0550: 72 69 53 69 67 6E 20 54 72 75 73 74 20 4E 65 74 riSign Trust Net
----- And the socket is closed -----


So to me it seems that the client application is receiving an incomplete message, but I don't know why.

Without delving into the data on a packet by packet basis, it may well be that the client is sending a reset before the other frame has arrived as the data is known to already be unacceptable for some reason or other.