IBrowse² Documentation

Last Updated: 20th June 2003

<< Languages Chapter

Contents Chapter

Advanced Topics Chapter >>

Secure communication on the Internet is performed via a system called Secure Sockets Layer, or SSL. IBrowse² supports SSL connections via the AmiSSLv2 or MiamiSSL applications, both of which support Secure Sockets Layer v2/v3 (SSLv2 and SSLv3) and Transport Layer Security v1 (TLSv1). This section aims to give you some background into how SSL works, both in general and in relation to IBrowse² in particular.

SSL "sits" on top of the usual transportation protocol that is handled by your TCP/IP stack, e.g. Miami, MiamiDX, AmiTCP, Genesis or Roadshow, and includes a handshake protocol that allows the web server and IBrowse² to authenticate each other and negotiate both an encryption algorithm and the cryptographic keys before IBrowse² sends any critical data.

The actual SSL protocol is used for connection security, to stop any prying eyes from reading the data that is sent between the web server and IBrowse². During the SSL handshake, the following takes place:

IBrowse² will initiate the connection to the web server.
IBrowse² will send which version of the SSL protocol it wishes to communicate at. This will be the highest version available i.e.
- v3 if Preferences » Security » SSLv2 support and Preferences » Security » SSLv3 support are both enabled
- v3 if Preferences » Security » SSLv3 support only is enabled
- v2 if Preferences » Security » SSLv2 support only is enabled
IBrowse² will send a list of cipher suites it supports, these can be controlled via Preferences » Security » Ciphers, specifically:
- The encryption used to encrypt the data can be controlled in IBrowse² under Preferences » Security » Ciphers » Encryption.
- The authentication used to verify the web servers identity can be controlled in IBrowse² under Preferences » Security » Ciphers » Key exchange/authentication.
- The data transport integrity can be controlled in IBrowse² under Preferences » Security » Ciphers » MAC.
The web server will then respond with the highest version of the SSL protocol it supports, and the lowest version IBrowse² reported it supports. If there is a miss-match here, the session will fail. e.g. if the web server supports only v2 and IBrowse² is only using v3, the connection will fail.
The web server will then respond with a single selected cipher suite from the list provided by IBrowse² based on the final SSL protocol selected.
The data will then be transferred between the web server and IBrowse² using the selected cipher suite, which in turn designates which MAC hash will be used for the data integrity checking.

Both SSLv2 and SSLv3 use symmetric and asymmetric ciphers for data exchange, key exchange, authentication and integrity checking, but they each use a different set of cipher suites to achieve this e.g. an SSLv2 server would never pick a DH cipher for key exchange as it is only valid with the SSLv3 protocol. The cipher suites that IBrowse² has available are listed in IBrowse² under the Preferences » Security » Ciphers section. From here, you can see which SSL protocol the cipher suite belongs to, i.e. SSLv2 or TLSv1/SSLv3.

One form of attack on secure communications is "man-in-the-middle". The Internet is constructed from many routers, which pass data on to each other in order to create a path from IBrowse² to the web server. Assuming one of these routers was compromised, it could tap into the communication between you and the web server. Going back to how the SSL connection are created, the following could happen:
IBrowse² will initiate the connection to the web server. IBrowse² will send which version of the SSL protocol it wishes to communicate with. The compromised router intercepts this message, and sends on to the web server a fake message saying that IBrowse² only supports SSLv2. IBrowse² will send a list of cipher suites it supports. The compromised router intercepts this message, and sends on to the web server a fake message that IBrowse² only supports a weak cipher suite, e.g. EXP-RC4-MD5, which is easy to crack these days. The web server will respond with the version of the SSL protocol it supports, which will be SSLv2 as that is all that the compromised router sent when it intercepted the original IBrowse² communication. The web server will respond with the weak cipher suite as that was the only cipher suite the compromised router sent when it intercepted the original IBrowse² communication. The data will be transferred between the web server and IBrowse² (via the compromised router), using the weak cipher suite. This then gives the compromised router the chance to log the communications and later crack the weak encryption.
The sole purpose of the SSLv2, SSLv3 and TLSv1 protocols is to stop this kind of activity from taking place and there are various procedures in the SSL protocols to combat this. As SSLv3 is a progression from SSLv2, it has further improvements in the protocol to protect against these kinds of spoof attempts. The SSL version does not directly relate to the strength of the encryption used, but allows IBrowse² and the web server to find the strongest common cipher they both can use. SSLv3 also introduces stronger encryptions, simply as they were not originally available for various reasons, when the original SSLv2 protocol was designed.
	For more information about SSLv3, visit http://wp.netscape.com/eng/ssl3/. For more information about OpenSSL, visit http://www.openssl.org

<< Languages Chapter

Contents Chapter

Advanced Topics Chapter >>



IBrowse² Documentation v2.3 © 2002, 2003 Dave Fisher ~ IBrowse² Development Team	Revision 1.0