by Njål

SSL v3.0 POODLE vulnerability – fixing on IIS


A few days ago 3 Google researchers discovered a nasty SSL security bug – named POODLE (“Padding Oracle On Downgraded Legacy Encryption”) – CVE 2014-3566.

This vulnerability affects servers still running SSL 3.0. It centers on cipher block chaining (CBC) encryption implementation and allow attackers with a Man-in-the-Middle (MITM) position to derive the contents of a secure payload based on responses received from requests sent from a compromised browser to a legitimate server.

The first thing you should do is check if this affects your site. Scan using SSL Toolbox –

If this issue is detected – then you should disable SSL 3.0 support or disable SSL 3.0 CBC-mode ciphers. Here’s a bat file which does the job – just run it as a an administrator on your IIS server – and reboot.

REG ADD "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server" /v Enabled /t REG_DWORD /d 0 /f
REG ADD "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client" /v Enabled /t REG_DWORD /d 0 /f
REG ADD "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server" /v Enabled /t REG_DWORD /d 0 /f
REG ADD "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client" /v Enabled /t REG_DWORD /d 0 /f
REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\DES 56/56" /v Enabled /t REG_DWORD /d 00000000 /f
REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 40/128" /v Enabled /t REG_DWORD /d 00000000 /f
REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 56/128" /v Enabled /t REG_DWORD /d 00000000 /f
REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 128/128" /v Enabled /t REG_DWORD /d 00000000 /f
REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128" /v Enabled /t REG_DWORD /d 00000000 /f
REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128" /v Enabled /t REG_DWORD /d 00000000 /f
REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 64/128" /v Enabled /t REG_DWORD /d 00000000 /f


Rescan using SSL Toolbox after the reboot to make sure the vulnerability have been removed from your server.

Tags: ,
by Andreas

Accepting invalid SSL certificates programmatically (C#)

This might initially sound like a very bad idea, because it undermines one of the fundamental reasons for using SSL in the first place. But it’s suprising how often I come across situations where this comes in very handy, especially during development and testing when valid certificates aren’t present and you still want to test your code over a secured encrypted channel.

Add a static method for handling the validation logic (or to skip it entirely):

// callback for validating SSL certificate during handshake
private static bool CustomCertificateValidatior(object sender,
    X509Certificate certificate, X509Chain chain,
    SslPolicyErrors policyErrors)
    // anything goes!
    return true;

    // PS: you could put your own validation logic here, 
    // through accessing the certificate properties:
    // var publicKey = certificate.GetPublicKey();


You then just add a RemoteCertificateValidationCallback before you make the SOAP / HTTP request, and your custom validator will take care of the validation.


// method where request is made

// ensure SSL certificate validation uses custom method
ServicePointManager.ServerCertificateValidationCallback +=
       new RemoteCertificateValidationCallback(CustomCertificateValidatior);

// initiate a SOAP or HTTP request like normal
// and your custom method will be used for validation

// ..
Tags: ,