SecureTransport, IE, BEAST and FIPS Mode
SecureTransport (ST) 5.1 supports FIPS 140-2 Level 1 ciphers for encrypting the communications channel over which files are transferred through its FIPS Mode feature. FIPS Mode can be enabled for HTTPS, SSH and FTPS based transfers.
If you have a requirement to use FIPS Mode transfers with HTTPS and your PCI scan has flagged that your ST deployment is vulnerable to the BEAST attack (see http://www.kb.cert.org/vuls/id/864643 for more information on the vulnerability that the attack exploits) on SSL/TLS - you might run into a problem. The SSL/TLS attack was discovered last year in September, browser vendors and server application vendors that used SSL/TLS released patches or workarounds for this issue.
A number of these patches / workarounds and the one that SecureTransport uses is to only allow RC4 based ciphers to be used. However, the FIPS approved ciphers do not include RC4 as they were considered weaker than other algorithms such as AES and 3DES.
A secondary issue exists with SecureTransport's default HTML client and when the client system is running Windows and Microsoft KB2643584 patch is installed which mitigates the vulnerability installed. In this scenario the user will be able login to ST using the default html template however, when they attempt a file upload a blank page is displayed or internal server error is displayed.
Similarly problems exist with the admin interface which is also over HTTPS (but on port 444) when certain operations are attempted.
The Microsoft patch described in MS12-006 (http://technet.microsoft.com/en-us/security/bulletin/ms12-006), addresses the vulnerability by implementing SSL Record Splitting/Fragmentation as described in the RFC2246 which defines the TLS 1.0 protocol.
The problem I believe is that ST cannot deal with SSL/TLS Record fragmentation/splitting. Actually most browser vendors have implemented the same mechanism.
This is a known bug/issue that Axway will address. Hopefully this article will help others who have run into this issue as it was difficult to diagnose and took some effort to convince Axway this was the problem.
In the meantime you can remove the patch or disable it by creating the SendExtraRecord registry key and setting its value to 2. This key prevents IE from splitting SSL records. The vulnerability can only be exploited in certain specific circumstances, so depending on the risk appetite of your organisation this may be acceptable.
http://blogs.technet.com/b/msrc/p/january-2012-security-bulletin-q-a.aspx
http://blogs.msdn.com/b/kaushal/archive/2012/01/21/fixing-the-beast.aspx
http://blogs.msdn.com/b/kaushal/archive/2011/10/03/taming-the-beast-browser-exploit-against-ssl-tls.aspx
http://www.imperialviolet.org/2012/01/15/beastfollowup.html
https://nuxx.net/blog/category/computers/
If you have a requirement to use FIPS Mode transfers with HTTPS and your PCI scan has flagged that your ST deployment is vulnerable to the BEAST attack (see http://www.kb.cert.org/vuls/id/864643 for more information on the vulnerability that the attack exploits) on SSL/TLS - you might run into a problem. The SSL/TLS attack was discovered last year in September, browser vendors and server application vendors that used SSL/TLS released patches or workarounds for this issue.
A number of these patches / workarounds and the one that SecureTransport uses is to only allow RC4 based ciphers to be used. However, the FIPS approved ciphers do not include RC4 as they were considered weaker than other algorithms such as AES and 3DES.
A secondary issue exists with SecureTransport's default HTML client and when the client system is running Windows and Microsoft KB2643584 patch is installed which mitigates the vulnerability installed. In this scenario the user will be able login to ST using the default html template however, when they attempt a file upload a blank page is displayed or internal server error is displayed.
Similarly problems exist with the admin interface which is also over HTTPS (but on port 444) when certain operations are attempted.
The Microsoft patch described in MS12-006 (http://technet.microsoft.com/en-us/security/bulletin/ms12-006), addresses the vulnerability by implementing SSL Record Splitting/Fragmentation as described in the RFC2246 which defines the TLS 1.0 protocol.
The problem I believe is that ST cannot deal with SSL/TLS Record fragmentation/splitting. Actually most browser vendors have implemented the same mechanism.
This is a known bug/issue that Axway will address. Hopefully this article will help others who have run into this issue as it was difficult to diagnose and took some effort to convince Axway this was the problem.
In the meantime you can remove the patch or disable it by creating the SendExtraRecord registry key and setting its value to 2. This key prevents IE from splitting SSL records. The vulnerability can only be exploited in certain specific circumstances, so depending on the risk appetite of your organisation this may be acceptable.
References
http://technet.microsoft.com/en-us/security/bulletin/ms12-006http://blogs.technet.com/b/msrc/p/january-2012-security-bulletin-q-a.aspx
http://blogs.msdn.com/b/kaushal/archive/2012/01/21/fixing-the-beast.aspx
http://blogs.msdn.com/b/kaushal/archive/2011/10/03/taming-the-beast-browser-exploit-against-ssl-tls.aspx
http://www.imperialviolet.org/2012/01/15/beastfollowup.html
https://nuxx.net/blog/category/computers/
Comments
Post a Comment