jessie-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Jessie-discuss] Bug in SSLSocket.doClientHandshake


From: Alfredo Pironti
Subject: [Jessie-discuss] Bug in SSLSocket.doClientHandshake
Date: Mon, 01 Jun 2009 19:25:57 +0200
User-agent: Thunderbird 2.0.0.21 (X11/20090409)

Hi list,

I would like to report a bug in the org.metastatic.jessie.provider.SSLSocket.doClientHandshake() method.

The SSL client implemented by this method will always try to send packets of type "session.enabledProtocols.last()" (that is the last element of the supported protocols list), instead of using the actually negotiated protocol version (which is chosen by the server).

To reproduce this bug, start an ssl server, asking to ONLY accept SSLv3 versions, then start the JESSIE ssl client ensuring that session.enabledProtocols is something like {"SSLv3","TLS"}. The server will choose the SSLv3 version, but the ClientKeyExchange message will be of version 3.1 (TLS), and the server will abort the session.

The problem stems from several sub-bugs in the code. Some of them I found are:

1) line 1373: The "if" block (anc the code in it) is redundant. We should only check that we support the server chosen version, and start using it. Something like

if (session.enabledProtocols.contains(version)) {
        session.protocol = version;
} else {
        // Exception: unsupported protocol
}

2) line 1384: if we really want to keep this code, this line should be
version = v2;
and not version = v1;. Indeed v2 is the variable storing the higher protocol, not v1.

3) At line 1459 we finally set
session.protocol = version;
We should do this as soon as we get the server chosen version. Moreover, after this statement, we should only use session.protocol. Instead, at line 1707 we do
ProtocolVersion v =
              (ProtocolVersion) session.enabledProtocols.last();
that chooses "some" protocol version, disregarding the negotiated one!

Maybe sub-bug 3) is repeated in the rest of the code, but I didn't check for it.

Moreover, when creating an SSLContext with the
SSLContext.getInstance("SSLv3", "Jessie");
statement, the socket will actually be ready to use SSLv3 AND TLS (which is allowed by JSSE, but it's not likely to be the expected behaviour. One would expect the client to support only SSLv3 or _lower_ protocol types).

If you need further information, I'll be glad to help.

Regards,
Alfredo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]