Securing your browsers: Internet Explorer

As third and last, I’ll show you how to secure your browser settings for Internet Explorer.

Internet Explorer is somewhat different because it doesn’t have it’s own settings for cipher suites. It gets those from the operating system. In Windows they are implemented in one of the SSPI’s namely SChannel. So to enable or disable cipher suites in IE, you need to enable or disable them in Windows.

First, let’s take care of the obvious. In IE there is an SSLv3 setting in the Advanced tab of the Internet Options. Uncheck this and IE will be POODLE-proof. SSL 2.0 should be unchecked by default.


Now, to disable cipher suites we could edit the registry. This is complicated and error prone, so we are going to use a tool. Download IIS Crypto here. I recommend version 1.6 GUI for .NET 4.0.

Start the tool with elevated privileges and have most of the work done for you by clicking the Best Practices button. You’ll have to Press the Apply button and restart for the changes to take effect.

I have edited the cipher suite order and put the ECDHE_ECDSA ciphers at the top of the list, followed by the ECDHE_RSA ciphers. I have tried disabling MD5 hashing but found that some applications for RDP were not working anymore. Disable every protocol before TLS 1.0 and every cipher suite above Triple DES 168. I tried disabling Triple DES 168, but some websites wont work anymore because they are not updated to use the newer Elliptic Curve cipher suites yet. Please test what works for you and post in comments.




As you can see, I disabled all TLS_DHE_DSS suites and the RC4 suite. I use the 3DES_CBC suite as a fallback suite.

I also disabled a few RSA SHA256 and RSA SHA384 suites because Microsoft released a bad patch. The IIS Crypto site also tells us to disable these:


This concludes my ‘series’ on how to secure your browser. It may be that these settings will be deprecated real soon. It might also be that you can use these safely for a few years. All depends on the progress and development in the field of cryptography. I will keep you updated.

Securing your browsers: Firefox

As a continuation of my previous post, I will now show you how to use secure settings with your Firefox browser. We still have to do the following:

  • Disable SSLv3 (this counters POODLE)
  • Disable RC4 cipher suites as much as possible
  • Disable SHA1 cipher suites as much as possible
  • Disable DES3 cipher suites as much as possible

I will use the most current version of Firefox, which is version 34.0(.5) as of now. The development team decided it was time to drop SSLv3 support by default, so they conveniently  took care of the first point.

To get to the security settings, open the about:config page in the address bar. Take notice of the warning and proceed. Now type ‘ssl’ in the search box that has appeared and press Enter. You will see all SSL related settings. On the bottom of your page are the cipher suites. The last column indicates if the cipher suite is enabled or not. True is enabled, false is disabled.

Again, I have tested several cipher suites in the last months and have come to a workable situation. I advise you to disable the following settings starting from the bottom:

  • security.ssl3.rsa_rc4_128_md5;false
  • security.ssl3.rsa_camellia_256_sha;false
  • security.ssl3.rsa_camellia_128_sha;false
  • security.ssl3.ecdhe_rsa_rc4_128_sha;false
  • security.ssl3.ecdhe_rsa_des_ede3_sha;false
  • security.ssl3.ecdhe_ecdsa_rc4_128_sha;false
  • security.ssl3.dhe_rsa_des_ede3_sha;false
  • security.ssl3.dhe_rsa_camellia_256_sha;false
  • security.ssl3.dhe_rsa_camellia_128_sha;false
  • security.ssl3.dhe_dss_aes_256_sha;false
  • security.ssl3.dhe_dss_aes_128_sha;false

Some will be disabled by default.

In addition, I advise you to enable the following cipher suites, again starting for the bottom of the page. These are cipher suites that can provide Perfect Forward Secrecy and are not (publicly) know to have been compromised:

  • security.ssl3.rsa_rc4_128_sha;true (fallback cipher suite)
  • security.ssl3.rsa_aes_256_sha;true (fallback cipher suite)
  • security.ssl3.ecdhe_rsa_aes_256_sha;true
  • security.ssl3.ecdhe_rsa_aes_128_sha;true
  • security.ssl3.ecdhe_rsa_aes_128_gcm_sha256;true
  • security.ssl3.ecdhe_ecdsa_aes_256_sha;true
  • security.ssl3.ecdhe_ecdsa_aes_128_sha;true
  • security.ssl3.ecdhe_ecdsa_aes_128_gcm_sha256;true
  • security.ssl3.dhe_rsa_aes_256_sha;true
  • security.ssl3.dhe_rsa_aes_128_sha;true

Additionally, you can disable ssl3.rsa_aes_128_sha too in favor of ssl3.rsa_aes_256_sha, ssl3.dhe_rsa_aes_128_sha in favor of ssl3.dhe_rsa_aes_256_sha and ssl3.ecdhe_ecdsa_aes_128_sha in favor of ssl3.ecdhe_ecdsa_aes_256_sha. Almost all servers support the 256bit version if the 128bit version is also offered, so this way I force the one with the strongest encryption. Mind you, I have not tested this thoroughly.

Firefox will prefer other cipher suites before ssl3.rsa_rc4_128_sha, so this will really act as a fallback cipher suite. Your result should be similar to this:


Now, to check SSLv3 is disabled, type in ‘tls’ in the search box. You will see the setting security.tls.version.min;1. It should have the value ‘1’. Value ‘0’ will allow SSLv3.


You can test your browser and the cipher suites it uses here or here. It should be these:


or these:


Next post will handle the same settings for Internet Explorer.

Securing your HTTPS Apache 2.4 web server with correct parameters

Warning: Keep in mind this is an ongoing field that is quickly changing. Vulnerabilities in protocols and implementations are discovered daily. If you read this information in a few months or even weeks, things could be radically different.

The last few days I’ve been researching HTTPS connections from Apache 2.4 webservers. This research was sparked by the recent Hearthbleed bug in OpenSSL. I’ve been reading up on vulnerabilities, cipher suites, encryption and hashing methods ever since.

The general move to SSL certificates with a bitlength > 1024bit also fueled this research. Microsoft removed support for 1024bit root CA certificates from their Operating System through a patch in March 2014.

One particular website that has a lot of information is They host a nifty server test tool at When testing our production webservers, we got this very poor result. We got a C for supporting weak cipher suites. We were also not mitgated against the BEAST vulnerability. This was tested after we patched Hearthbleed.




As you can see in the first line, the server had no preference in cipher suite order. Why is this a problem you ask? With modern browsers you always use a newer cipher suite anyway. The point is that external parties (hackers) can force your web server to use an insecure cipher suite to communicate with them.

The most shocking to me was that we, as sysadmins, including me, never really gave much thought to this. The general idea is that you put an SSL certificate on your webserver and it’s secured. As with so many security related product, this assumption is dead wrong. The default ssl_mod settings are optimized for compatibility, not security. With our web servers getting 10 millions+ hits a month and providing privacy sensitive information, there wasn’t much thought needed to see this needed some serious attention.

After some time we came to the following requirements:

  • Create a config that is as secure as possible.
  • All common browsers should be able to connect to our websites securely. The highly unsafe IE browsers on the Windows XP platform included.
  • SSL3 must be supported for older browsers/platforms.
  • We must be mitigated against all know attacks, such as BEAST, CRIME, BREACH, Lucky Thirteen, padding attacks, renegotiation, etc.

This appeared to be quite a challenge. In the case of BEAST this deserved some special attention, because mitigating against BEAST is only possible using RC4 cipher suites in TLS1.0 and SSLv3 connections. Unfortunately the research in  cracking the RC4 encryption got a serious boost in March 2013.

After days of testing, I came up with the following:

  • Use Apache 2.4.7. This version does not allow the key exchange in Diffie-Hellman cipher suites to be less then 2048bit. It will use the bitlength of the SSL certificate but will use no less then 2048bit.
  • Use an Apache binary that is compiles against a recent version (1.0.1g) of OpenSSL lib. This will ensure the serving of ECDHE and ECDHE-ECDSA cipher suites.
  • Use a 4096bit SSL certificate. This will strengthen the DHE key exchange mechanism.
  • Specifically disable SSLv2 even though it is not supported anymore with recent OpenSSL libs.
  • Force the cipher suite order in mod_ssl.conf.
  • Use a specific, custom ciphers suite to satisfy your specific needs.
  • Use mod_socache_shmcb to allow session caching and session resumption.
  • Use the Strict-Transport-Security parameter in your Virtual Host config to support HSTS.

Cipher suites are selected on the following criteria in order of importance:

  • Prefer ECDHE-ECDSA cipher suites
  • Prefer ECDHE cipher suites
  • Prefer DHE cipher suites
  • Prefer GCM block cipher suites
  • Prefer CBC block cipher suites
  • Prefer SHA384 hashing
  • Prefer SHA256 hashing
  • Prefer SHA hashing
  • Prefer cipher suites which support Forward Secrecy
  • Prefer cipher suites with 256bit encryption
  • Prefer cipher suites with 128bit encryption
  • Prefer cipher suites with 112bit encryption

As you can see, encryption bit length is only a minor factor in this. Forward Secrecy preference is implicitly done by preferring the ECDHE and DHE cipher suites.

For us, this would result in the ssl_mod config:

SSLSessionCache shmcb:/var/cache/mod_ssl/scache(512000)
SSLSessionCacheTimeout 300
SSLProtocol -SSLv2 ALL
SSLHonorCipherOrder On
SSLCompression Off

And the httpd config:

<VirtualHost *:443>

Header always set Strict-Transport-Security “max-age=63072000; includeSubDomains”

Alternatively, you can choose not to support CAMELLIA en SEED ciphers with the following parameter:


It’s up for debate if TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (DHE-RSA-DES-CBC3-SHA) and TLS_RSA_WITH_3DES_EDE_CBC_SHA (DES-CBC3-SHA) are still wanted. These create connections with 112bit cipher strength instead of 168bit which you may think. If you require 128bit, leave them out. the DHE-RSA-DES-CBC3-SHA cipher provides Forward Secrecy, so the key to decode one session, cannot be used for another session.

You might want to put TLS_DHE_RSA_WITH_AES_128_CBC_SHA (DHE-RSA-AES128-SHA) before TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (DHE-RSA-DES-CBC3-SHA), but since it’s included in EDH+aRSA, you’ll have to write it out.

Above settings result in an A+ rated site with BEAST mitigation, Strict Transport Security (HSTS), Forward Secrecy with all common browsers and no RC4 in vulnerable cipher suites:


ssllabs-a-plusssllabs-protocol-detailsssllabs-handshake-simulation ssllabs-protocol-details-and-cipher-suites

If you are not interested in mitigating BEAST (as most browsers are patched), you could use the following order:


Again, CAMELLIA and SEED could be left out:


And explicit denial of all RC4 encryption might be preferable:


I would also advise leaving out the 112bit TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (ECDHE-RSA-DES-CBC3-SHA) cipher suite:


This would result in all modern browsers/flatforms (IE in Vista and higher, Andriod 4.0.4 and higher, FireFox, Chrome and Safari) to use ECDHE cipher suites with 256bit encryption. The TLS_RSA_WITH_3DES_EDE_CBC_SHA (DES-CBC3-SHA) suite will be used for all exceptions. Also encryption with the potentially vulnerable RC4 cipher is prevented.


“Elliptic curve cryptography”
“Elliptic Curve DSA”
“Elliptic curve Diffie–Hellman”
“SSL/TLS Deployment Best Practices”
“Configuring Apache, Nginx, and OpenSSL for Forward Secrecy”
“RC4 in TLS is Broken: Now What?”
“Updated SSL/TLS Deployment Best Practices Deprecate RC4”
“SSL Labs Test for the Heartbleed Attack”
“SSL Labs: Stricter Security Requirements for 2014”
Session Resumption
“HTTP Strict Transport Security”
“Strong SSL Security on Apache2”
“Increasing DHE strength on Apache 2.4.x”
“OpenSSL cipher suites” This site runs Apache. It’s cipher suites are: “EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS”. This server runs nginx. It’s cipher suites are: ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:HIGH:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!CBC:!EDH:!kEDH:!PSK:!SRP:!kECDH; This site uses mod_spdy voor Apache 2.4. mod_spdy.
chrome://net-internals/#spdy Monitor SPDY connections in the Chrome browser

VMware Auto Deploy error SSLError: [Errno 336265225] _ssl.c:337: error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM lib

After upgrading to vCenter 5.1 Update 1a I decided to take a look at the Auto Deploy component. Since upgrading to vCenter 5.0 it wasn’t working. Because we didn’t plan on using it, I just disabled the service at that time. After the improvements to Auto Deploy in 5.1 especially the Stateless Caching mode, this technique  might be something we want to use in the future.

Enabling the service resulted in the same error as before. The service starts, but the vSphere Client plugin cannot connect and displays the error ‘The request failed because of a connection failure. (Unable to connect to the remote server)’


I verified that there were no listeners on port 6501 and 6502 through a netstat -a on the Autodeploy server.


I browsed to VMware KB 2000988 to start my quest for a solution.

I opened the vmconfig-autodeploy.xml from %ProgramData%\VMware\VMware vSphere Auto Deploy\ and verified all paths mentioned were correct. I also checked the settings in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\VMware, Inc.\VMware vSphere Auto Deploy with regedit. The only thing I changed in the registry and the XML file was the username. I changed it from the Down-Level Logon Name [NETBIOS DOMAIN]\[USER] to the User Principal Name [USER]@[DNS DOMAIN].

A reboot of the service didn’t change the situation.

Because I didn’t do any configuration, I tried to re-register the service and got an error thrown at me, yay!


I opened the log file location %ProgramData%\VMware\VMware vSphere Auto Deploy\logs and immediately saw that a lot of logging was being created. A good thing in it self and a clear indication something is wrong 🙂


Opening one of the log files revealed that same error

SSLError: [Errno 336265225] _ssl.c:337: error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM lib

and another one

Error: [(‘PEM routines’, ‘PEM_read_bio’, ‘no start line’), (‘SSL routines’, ‘SSL_CTX_use_certificate_file’, ‘PEM lib’)]


So, it seems to be a certificate issue. A Google search revealed nothing to further help me.

I opened the location of the SSL certificates %ProgramData%\VMware\VMware vSphere Auto Deploy\ssl and there was the root of the problem.


Because we still use the default installer certificates, these were quickly replaced with copies from e.g. the %ProgramData\VMware\VMware ESXi Dump Collector\ssl folder.

I tried to re-register the service again, but was thrown another error:

error: attempt to write a readonly database


Again, because there was no configuration done, I simple renamed the db file in the Data directory and ran the command again. A new db file was created automatically.


The command did throw another error or warning,

‘openssl’ is not recognized as an internal or external command, operable program or batch file.

but it did finish successfully.


I restarted the Auto Deploy service and was able to connect my vSphere Client. All good!


%d bloggers like this: