Once any web application is deployed its always recommended to perform a thorough security testing to identify if there are any security risks.
In this article im just sharing my experience to disable RC4 and SSLV3 for applications hosted on Windows Servers.
We can use the below URL site to test the server configuration for HTTPS protocol
https://www.ssllabs.com/ – that will test your server’s configuration for the HTTPS protocol
Why RC4 needs to be disabled ?
RC4 should not be used, due to crypto-analytical attacks.
It’s been more than 25 years since Ron Rivest invented his RC4 stream cipher but still being used by legacy clients and browsers.
How RC4 Encryption Works:
A ciphersuite consists of a key exchange algorithm, an encryption method and an integrity protection method.
RC4 is a stream cipher, so it encrypts plaintext by mixing it with a series of random bytes used to encrypt it. But, the bytes used to encrypt the plaintext aren’t really as random as they should be, at least at the beginning of the process.
That makes it possible for an attacker to figure out the plaintext of an encrypted message with access to enough TLS requests. The problem is that there are biases in the keystream, making life easier for an attacker.
Why its not Disabled by default on Windows Server 2008 R2, 2012 R2 ?
Unfortunately, servers default configuration tends to support backward compatibility as well over security.
They are enabled by default only for supporting older versions of browsers and operating systems.
Basically we need to disable this on apps running Windows Server 2008 R2 , 2012 R2 and IIS.
Preventive Measures for RC4 Attack:
As a security its always recommend to use TLS 1.2 or above. So its better to disable them and support only the latest type of encryption.
Disable Ciphers by adding the below registry entries on the server hosting the application.
A Small history on SSL
SSLv1 was never publicly released.
SSLv2 was quickly found to be insecure.
SSLv3 was created, and, together with the newer TLSv1/1.1/1.2, it is still currently being used to secure the transport layer of the Internet.
Weakness of SSL V3:
Last year Google Engineers found the major loophole in SSLV3 with an exploitation technique known as POODLE Attack.
This is a plaintext recovery attack that focuses on HTTP headers and exploits a weakness in the SSLv3 protocol when used with block ciphers.
Its a protocol vulnerability attack.
So now its recommended to disable the SSLV3 on server side.
Preventive Measures for SSLV3 Attack:
Disable SSL V3 by adding the below registry entries on the server hosting the application.
Always advisable to have encryption of more than TLS 1.2.
1) If you have this security enabled on the reverse proxy application through which your services are published, then the session for those connections will be terminated there itself.
But still its better to have this disabled on all the applications which are serving the clients.
2) Its very important to note that before disabling this type of connections we need to make sure that the application is not serving any clients with this encryption.If at all its found we need to make that application to work on TLS1.2 or later.
Thanks & Regards
MVP – Office Servers and Services
Leave a Reply