IntraWeb Archive

Securing IntraWeb stand alone applications against SSL/TLS BEAST attack

Securing IntraWeb stand alone applications against SSL/TLS BEAST attack

The BEAST attack

Last year, two guys reported that they could actually decrypt HTTPSrequests. That was called BEAST attack or Browser Exploit Against SSL/TLS. Itis a SSL/TLS attack that uses JavaScript and a network sniffer to exploit clientside SSL/TLS security holes. A very interesting reading about the BEAST attack and its origins can be found here.

If you use SSL security on an IntraWeb application you may be interested in whether or not your application is vulnerable to BEAST attack, right?. Infact, if you are using Open SSL “out of the box” in any kind of webserver, probably you are vulnerable to the BEAST attack. The TLS (Transport Layer Security protocol) version 1.1 and 1.2 are not vulnerable but most browsers don’t support it yet, so the web servers can’t take advantage of that.

How can you protect IntraWeb applications against a BEAST attack?

Stand alone IntraWeb servers are based on Indy libraries and Open SSL for HTTPS support. Indy uses SSL 3.0 and TLS 1.0, so TLS 1.1+ is not feasible. Another way to protect your application is to disable CBC mode ciphers.

When using HTTPS with Open SSL, Indy uses a subclass of TIdServerIOHandler class, called TIdServerIOHandlerSSLOpenSSL. This class has a property SSLOptions where you can set CertFile, KeyFile and other options when using SSL. There is also a property CipherList. When not set explicitly, Indy uses the default value “AES:ALL:!aNULL:!eNULL:+RC4:@STRENGTH”. You may find more information about the CipherList format here. Many sources confirmed that RC4 cipher suites are not vulnerable to BEAST attack, and RC4 is universally supported, so it turns out to be a good candidate. To make things simple, we may just use it with RSA (asymmetric exchange and signing) and SHA1 (symmetric hash), like that:

    CipherList := ‘RC4+SHA1+RSA’;

Checking this cipher list using Open SSL tools:

C:OpenSSL-Win32-1.0.1cbin>openssl ciphers -v RC4+SHA1+RSA

> RC4-SHA         SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1

Securing IntraWeb XII applications

IntraWeb (version 12.2.9 and up) exposes the TInServerIOHandlerSSLOpenSSL instance used by Indy via ServerController event OnAfterCreateIOHandler. You may use this event to modify the default CipherList used by Indy, like that:

procedure TIWServerController.IWServerControllerBaseAfterCreateIOHandler(IOHandler: TInServerIOHandler);
     // IOHandler is the instance of TInServerIOHandlerSSLOpenSSL used by Indy
  TInServerIOHandlerSSLOpenSSL(IOHandler).SSLOptions.CipherList := ‘RC4+SHA1+RSA’;

Please note that IntraWeb Indy classes have a different prefix “In”instead of “Id” to avoid naming conflicts with standard Indydistribution that comes with many versions of Delphi and Rad Studio. To use the code above you have to add InServerIOHandler and InSSLOpenSSL units to ServerController unit uses clause. You may also use other combinations of CipherList, like ‘ECDHE-RSA-RC4-SHA:RC4+SHA1+RSA’, to make use of perfect forward secrecy referenced here.

Securing IntraWeb XIV (and later) applications

In IntraWeb XIV we have redesigned the IOHandler creation and the default cipher list is already RC4+SHA1+RSA. This means that you don’t have to do anything special to protect agains this kind of attacks. If you are using latest OpenSSL libraries with IntraWeb XIV (and later) you are already protected.

Nevertheless, you can still change the cipher list used by Indy IOHandlers, via ServerController.SSLOptions.CipherList property. If this is set, IntraWeb will use this list instead of its own default cipher list.

Also note that it is important to use latest Open SSL libraries supported by IntraWeb and Indy servers applications. More information about Open SSL libraries used by IntraWeb can be found here.

Thats it! After that we may submit our application to some SSL test tool, like

The result is shown in the figure below

Further readings: