JAVA Toolkit
| home | contact




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.

 

 
print    tip a friend
back to previous page back  |  top to the top of the page