This document gives information about interoperability with other SSL/TLS implementations and notes to SSL 2.0.
iSaSiLk supports several versions of the SSL/TLS protocol (SSL 2.0 on the client, SSL 3.0, TLS 1.0 and TLS 1.1 on both client
and server side). SSL 2.0 is disabled by default for security reasons and should only be enabled if it is actually needed.
The SSL/TLS protocol ensures that always the highest protocol version supported by both the client and the server is used.
Therefore, most applications should never need to care about version selection. However, this may not work correctly
with certain very few buggy implementations. In this case you might want to disable a protocol version. This is done using
the setAllowedProtocolVersion() method in the SSLContext .
Per default SSL 3.0, TLS 1.0 and TLS 1.1 are enabled for both clients and server, SSL 2.0 is not enabled, see the section on SSL 2.0
for more information
Once the handshake has been completed you can call the
your SSLSocket to retrieve the selected SSL version.
iSaSiLk also supports SSL 2.0 on the client side, server side SSL 2.0 is NOT supported. It was implemented to allow communication
with a few remaining old server implementations that do not support SSLv3. Server side support for SSLv2 should never be needed
as virtually all clients long support SSLv3.
SSLv2 is a very mediocre security protocol and has several known flaws and design limitations. Therefore, it is disabled by default. It should
only be enabled if you want to communicate with a server that does not support SSLv3.
A few of the limitations of SSL 2.0 are:
In iSaSiLk SSLv2 enabled ciphersuites are not manually set. Rather they are computed automatically from the enabled v3 suites. That means that
if v2 is enabled the list of enabled v3 suites is checked and if a given enabled v3 ciphersuite has an equivalent in v2 that is automatically enabled.
These equivalents are:
SSLv2 Equivalent Ciphersuite
As you can see there is an equivalent v3 ciphersuite for each v2 ciphersuite (SHA is used instead of MD5 several times) except for
SSL2_RSA_WITH_RC2_128_CBC_MD5. In this case a private ciphersuite with the v3 id 0xFF5B was defined as an equivalent. This ciphersuite
PRIVATE_RSA_WITH_RC2_CBC_MD5 can also be used in v3 mode but this is not recommended.
Fairly extensive interoperability testing has been performed between iSaSiLk and other SSL/TLS compliant implementations. Some minor problems
have been fixed and there are no known interoperability problems except for those listed below. Note that because iSaSiLk fully supports all aspects
of SSL3.0/TLS1.0/TLS1.1 iSaSiLk is interoperable with any other standard compliant implementation no matter which algorithms it supports and has enabled.
No problems were detected in tests with the following implementations:
Some notes apply to the following implementations:
Some servers do not recognize the SSL 3.0 and TLS 1.0 combined client hello format correctly (although they should).
In those cases it may be necessary to either disable TLS 1.0 or to enable
SSL 2.0 in addition (they seem to better cope with the different SSLv2 hello messages).
That means try
Unfortunately a number of servers, seemingly including most or all versions of the Microsoft IIS server, do not correctly shutdown
the SSL/TLS layer before closing the connection on the TCP level. This will cause EOFExceptions to be thrown and also cause
iSaSiLk to invalidate the session resulting in a full handshake for each connection and consequently lower performance.
Note that this is a bug in those server implementations and not in iSaSiLk! Anyway, as a workaround we offer an SSLContext setting
that allows you to ignore this (i.e. no EOFException will be thrown and the session is cached as usually). To active this workaround
use code like
Note that when activated you may be vulnerable to truncation attacks. Note also
that TLS 1.0 (RFC 2246) does not allow to resume incorrectly terminated
sessions. However, since closing TLS sessions without correct shutdown
is a common practice, TLS 1.1 (RFC 4346) does no longer require to invalidate
incorrectly terminated sessions. For that reason, the default behaviour of
iSaSiLk is different for TLS 1.1 (incorrectly terminated sessions are cached)
and protocol versions prior TLS 1.1 where incorrectly terminated sessions
cause an EOF exception and are not cached by default. You may explicitly call
the setCacheTerminatedSessions method if you want to enforce the
same behaviour for all protocol versions.
Extensions for the TLS protocol have been introduced by RFC 3546, 4366. iSaSiLk supports all standard extensions
specified by RFC 3546 (and additionally the session_ticket extension defined in RFC 4507)
and has been successfully tested against the following extension supporting browsers :
Opera 9.10: if TLS is enabled only, Opera sends the following standard
extensions within the ClientHello message: server_name ,
(type OCSP), however, there seems to be an OCSP
encoding problem. Thus the usage of the status_request extension
should be disabled when talking with Opera versions containing this
issue. This problem has been fixed by newer versions of Opera (e.g. 9.62)
The SessionTicket extension has been introduced by RFC 4507
("TLS Session Resumption without Server-Side State"). However,
the SessionTicket encoding has been changed from RFC 4507 to its
successor draft RFC 4507bis which simply puts the ticket into the
extension_data field since done so by most applications.
iSaSiLk 4.1 now also uses the 4507bis format when sending a SessionTicket
extension, but is able to parse both, the 4507 and 4507bis format.
According to RFC 4507bis iSaSiLk now also uses SHA-256 as hash algorithm
for HMAC-protecting the ticket instead of SHA-1 as has been used by RFC 4507.
The RenegotiationInfo extension has been introduced by
against renegotiation attacks . Depending on the deploymaent of RenegotiationInfo
supporting TLS applications, interoperability problems may occur during a certain
transition period. See here for further information about use and configuration options
of the RenegotiationInfo extension.
The most recent versions of Mozilla Firefox and Microsoft Internet Explorer on Windows
Vista both support elliptic curve cipher suites. Both browsers make use of the
SupportedEllipticCurves and SupportedPointFormat extensions with named curves
secp256r1, secp384r1 and secp521r1 and uncompressed point format, all supported
and by default used by iSaSiLk.