isasilk interoperability

This document gives information about interoperability with other SSL/TLS implementations and notes to SSL 2.0.

Protocol Version Selection

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 getActiveProtocolVersion() method of
your SSLSocket to retrieve the selected SSL version.

SSL 2.0 Notes

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:

• Very limited selection of ciphersuites. SSLv2 only supports RSA for key exchange and MD5 for the MAC.
• No support for certificate chains. SSLv2 certificate messages can only contain a single certificate, hierarchies are not properly possible.
• No proper error signalling. Once the handshake has been completed it is no longer possible to signal errors like a MAC error to the peer.
  Neither are there closure alerts like in SSLv3. This means that it is not possible to detect if the remote peer closed the connection normally,
  because of an error, or if the connection was closed on the TCP level by an attacker.
• No renegotiation. Ciphersuite renegotiation is not supported in SSL 2.0.
• No compression. Compression is not possible in SSLv2 but this is only a minor limitation as it is never used in SSLv3 either.

Setting SSL 2.0 Enabled Ciphersuites

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:

SSLv3 Ciphersuite	SSLv2 Equivalent Ciphersuite
SSL_RSA_WITH_3DES_EDE_CBC_SHA	SSL2_RSA_WITH_DES_192_EDE3_CBC_MD5
SSL_RSA_WITH_IDEA_CBC_SHA	SSL2_RSA_WITH_IDEA_128_CBC_MD5
SSL_RSA_WITH_RC4_MD5	SSL2_RSA_WITH_RC4_128_MD5
PRIVATE_RSA_WITH_RC2_CBC_MD5	SSL2_RSA_WITH_RC2_128_CBC_MD5
SSL_RSA_WITH_DES_CBC_SHA	SSL2_RSA_WITH_DES_64_CBC_MD5
SSL_RSA_EXPORT_WITH_RC4_40_MD5	SSL2_RSA_WITH_RC4_128_EXPORT40_MD5
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5	SSL2_RSA_WITH_RC2_128_CBC_EXPORT40_MD5

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.

Interoperability

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:

• Netscape Navigator and Communicator, versions 3.x, 4.0x, 4.5 and later
• Mozilla and Firefox browsers, various versions
• Netscape Servers (Enterprise, etc.), various versions
• Microsoft Internet Explorer, versions 4.x, 5.x, 6.x, 7.x
• Microsoft IIS, versions 4.x, 5.x, 7.x (but see see note below)
• SSLeay and OpenSSL based software (Apache + mod_ssl), various versions
• Oracle Server (Web Listener)
• Opera browsers, various versions (but see note below)

Some notes apply to the following implementations:

• iSaSiLk versions prior to 3.0: these versions has minor errors in the
  rarely used DH_anon and fixed DH ciphersuites which may prevent them from interoperating
  with compliant implementations including iSaSiLk 3.0 or later. This does not affect
  the RSA and DHE ciphers.
• Stronghold server. A version selection problem may occur, see note below.
• IBM servers. Some versions also have problems with protocol version
  selection, see note below.

Protocol Version Selection Problems

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

context.setAllowedProtocolVersions(SSLContext.VERSION_SSL30, SSLContext.VERSION_SSL30);

or possibly

context.setAllowedProtocolVersions(SSLContext.VERSION_SSL20, SSLContext.VERSION_TLS10);

Connection Closure and EOFExceptions

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

context.setCacheTerminatedSessions(true);

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.

TLS Extensions

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 :

• Microsoft Internet Explorer MSIE 7.0: when running on Vista operating
  system, MSIE sends the following standard extensions within the ClientHello
  message: server_name , status_request (type OCSP); MSIE
  correctly handles the extensions and the OCSP status response sent back
  by iSaSiLk
• Mozilla Firefox 2.0: if TLS is enabled only, Firefox sends the following
  standard extension within the ClientHello message: server_name ;
  Firefox correctly handles the server_name extension sent back
  by iSaSiLk

• Opera 9.10: if TLS is enabled only, Opera sends the following standard
  extensions within the ClientHello message: server_name ,

  status_request (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)

SessionTicket extension

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.

RenegotiationInfo extension

The RenegotiationInfo extension has been introduced by RFC 5746 as countermeasure
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.

ECC Cipher Suites

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.