A Few Options To Use Keepass Even More Safely

To use everyone’s favorite password tool Keepass more safely, enable the following options:

1) Enter master key on secure desktop. You can find this option in the security tab in the options dialog.

This option will make sure it’s very difficult for key loggers to steal your master password of your Keepass database while you enter it. Read more on it here.

2) Two-channel auto-type obfuscation. This option can be enabled only per password entry.

This option will paste parts of the password through the clipboard making almost any keylogger useless. Read more on it here.

You will receive a warning that this option won’t work with all windows.

As long as you’re using Keepass mainly for passwords for web services, you should be fine.

I recommend you look around in the options dialog to see of you can tweak some more options for your security. Let me know in the comments if you find something that everyone should use.

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:

• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_RC4_128_SHA

or these:

• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_RC4_128_SHA

Next post will handle the same settings for Internet Explorer.

Securing your browsers: Chromium, Google Chrome or Opera

It took some time for me to write this blog. It was supposed to deal with all three major browsers, but I could not make the time lately. I started a  four year Professional Education last year. Together with my more-than-full-time job I just could not find the time to post anymore. In the meantime POODLE came along and this post is almost outdated before it is even written. Or typed 🙂

I got my bachelor and are now in my second year, hurray! Now, because of an obligatory assignment from school, I am supposed to write six blog posts before January 2015. So this presented the opportunity to start writing again and break this big subject up in parts.

We’ll start with Chromium first. This is also applicable to Google Chrome and Opera. Here we go.

So, because of POODLE, this subject should have your attention. If it does not, be glad you stumbled upon this blog. To secure your browser from any unsafe or insecure settings while visiting HTTPS web pages, 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 have been testing different settings myself for months now, and the problem is that disabling cipher suites which utilize SHA1 hashing or RC4 ciphers altogether probably is not a good idea. Why? Well, for one, Youtube will stop working. Yeah, really. It seems, when visiting Youtube over TLS, your video stream will use an RC4 cipher. It kind of makes sense because RC4 is the least CPU intensive stream cipher. But still it is weird coming from the company that works hardest of all to put old cipher suites to rest.

Denying cipher suites which use SHA1 hashing will probably stop you from being able to visit a minority of sites. You will have to read the error presented to you to recognise why you can’t see a particular webpage. Be aware of this.

Anyway, there aren not any check boxes to check or buttons to push in the GUI, so you have to use start up parameters to force Chromium, Chrome or Opera to comply with thesesecurity settings. Please note that WordPress does not like the double hyphen sign. It replaces it with a dash upon publishing. So replace the dash with two hyphens to make it work. To stop using insecure cipher suites, you will have to start your Chromium, Chrome or Opera executable with the following parameters:

–cipher-suite-blacklist=0x0005,0x0004,0x002f,0xc012,0xc011,0x003c,0xc011,0x0032,0xc007,0xc00c

To stop using SSLv3, you’ll have to use the parameter:

–ssl-version-min=tls1

To do this, you’ll have to edit the shortcut you use to start your browser to let it read:

“<PATH TO>\chrome.exe or opera.exe” –cipher-suite-blacklist=0x0005,0x0004,0x002f,0xc012,0xc011,0x003c,0xc011,0x0032,0xc007,0xc00c —ssl-version-min=tls1

This disables many outdated cipher suites. You can find them by the hex code here. You should know, this does not disable SHA1 nor DES3 altogether. The TLS_RSA_WITH_RC4_128_SHA (RC4-SHA) and TLS_RSA_WITH_3DES_EDE_CBC_SHA (DES-CBC3-SHA) will stay enabled for fallback and compatibility (e.g. Youtube) issues.

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

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e)
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc14)
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc13)
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c)
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)

If you’re interested, these are all the parameters I currently use with my Chromium browser:

–cipher-suite-blacklist=0x0005,0x0004,0x002f,0xc012,0xc011,0x003c,0xc011,0x0032,0xc007,0xc00c —ssl-version-min=tls1 –flag-switches-begin –enable-async-dns –enable-download-resumption –enable-encrypted-media –enable-fast-unload –javascript-harmony –disable-pinch –enable-quic –use-simple-cache-backend=on –enable-spdy4 –disable-touch-drag-drop –enable-webgl-draft-extensions –ignore-gpu-blacklist –enable-lcd-text –num-raster-threads=4 –disable-origin-chip –save-page-as-mhtml –touch-events=disabled –flag-switches-end

OK, that’s that. I will post some instructions for Firefox and Internet Explorer soon.

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 https://www.ssllabs.com. They host a nifty server test tool at https://www.ssllabs.com/ssltest/. 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
SSLCipherSuite EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:DHE-RSA-CAMELLIA256-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-SEED-SHA:AES256-SHA256:AES128-SHA256:AES128-SHA:DHE-RSA-DES-CBC3-SHA:DES-CBC3-SHA:RC4-SHA:!aNULL:!eNULL:!ADH:!EXP:!LOW:!DES:!MD5:!PSK:!SRP:!DSS

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:

SSLCipherSuite EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:AES256-SHA256:AES128-SHA256:AES128-SHA:DHE-RSA-DES-CBC3-SHA:DES-CBC3-SHA:RC4-SHA:!aNULL:!eNULL:!ADH:!EXP:!LOW:!DES:!MD5:!PSK:!SRP:!DSS

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:

 

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

SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-SHA256:ECDH-RSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-CAMELLIA256-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-RSA-SEED-SHA:CAMELLIA256-SHA:CAMELLIA128-SHA:DES-CBC3-SHA:!aNULL:!eNULL:!ADH:!EXP:!LOW:!DES:!MD5:!PSK:!SRP:!DSS

Again, CAMELLIA and SEED could be left out:

SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-SHA256:ECDH-RSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DES-CBC3-SHA:!aNULL:!eNULL:!ADH:!EXP:!LOW:!DES:!MD5:!PSK:!SRP:!DSS

And explicit denial of all RC4 encryption might be preferable:

SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-SHA256:ECDH-RSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DES-CBC3-SHA:!aNULL:!eNULL:!ADH:!EXP:!LOW:!DES:!MD5:!PSK:!SRP:!DSS:!RC4

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

SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-SHA256:ECDH-RSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DES-CBC3-SHA:!aNULL:!eNULL:!ADH:!EXP:!LOW:!DES:!MD5:!PSK:!SRP:!DSS:!RC4

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.

 

References:
“Elliptic curve cryptography” http://en.wikipedia.org/wiki/Elliptic_curve_cryptography
“Elliptic Curve DSA” http://en.wikipedia.org/wiki/Elliptic_Curve_DSA
“Elliptic curve Diffie–Hellman” http://en.wikipedia.org/wiki/ECDHE
“SSL/TLS Deployment Best Practices” https://www.ssllabs.com/projects/best-practices/
“Configuring Apache, Nginx, and OpenSSL for Forward Secrecy” https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy
“RC4 in TLS is Broken: Now What?” https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what
“Updated SSL/TLS Deployment Best Practices Deprecate RC4” https://community.qualys.com/blogs/securitylabs/2013/09/17/updated-ssltls-deployment-best-practices-deprecate-rc4
“SSL Labs Test for the Heartbleed Attack” https://community.qualys.com/blogs/securitylabs/2014/04/08/ssl-labs-test-for-the-heartbleed-attack
“SSL Labs: Stricter Security Requirements for 2014” https://community.qualys.com/blogs/securitylabs/2014/01/21/ssl-labs-stricter-security-requirements-for-2014
“SPDY” http://en.wikipedia.org/wiki/SPDY
“ChaCha20” http://en.wikipedia.org/wiki/ChaCha20#ChaCha_variant
“Poly1305-AES” http://en.wikipedia.org/wiki/Poly1305
“QUIC” http://en.wikipedia.org/wiki/QUIC
Session Resumption http://en.wikipedia.org/wiki/Transport_Layer_Security#Session_IDs
“HTTP Strict Transport Security” http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
“Nginx” http://en.wikipedia.org/wiki/Nginx
“Strong SSL Security on Apache2” https://raymii.org/s/tutorials/Strong_SSL_Security_On_Apache2.html
“Increasing DHE strength on Apache 2.4.x” http://blog.ivanristic.com/2013/08/increasing-dhe-strength-on-apache.html
“OpenSSL cipher suites” https://www.openssl.org/docs/apps/ciphers.html
https://www.ssllabs.com/ssltest/analyze.html?d=payload.hu. 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”.
https://www.ssllabs.com/ssltest/analyze.html?d=icnseo.com 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;
https://www.ssllabs.com/ssltest/analyze.html?d=blck.io. This site uses mod_spdy voor Apache 2.4.
https://github.com/eousphoros/mod-spdy mod_spdy.
chrome://net-internals/#spdy Monitor SPDY connections in the Chrome browser

Windows 8 Internet Explorer 10 Flash Player vulnerabilities thoughts

In Internet Explorer 10 the Adobe Flash Player isincluded by default. I don’t know the exact reason for this, but I don’t really care. Google is doing this for almost 2 years with Google Chrome. As soon as Adobe releases an update, Google Chrome is also updated. It seems to work and it certainly prevent users from using an ancient Flash Player plugin with dozens of vulnerabilities. I think this is why Microsoft decided to jump on this bandwagon,too.

But wait. How does Microsoft distribute it’s patches? By implementing a patch tuesday every month. The consequences of this combination of choices become painfully clear with the release of Windows 8. It contains a months old version of the Flash Player plugin that can’t be manually updated.

The update to the most recent version, that contains patches to (at least) vulnerabilities disclosed in APSB12-18 and APSB12-19, will be available no sooner then October 26th. How embarrasing. I really can’t believe noone of all those smart people at Microsoft forsaw this scenario. It must have been a management decision…. 😛

There is nothing more to say then to advise all Windows 8 users to use IE10 for 1 thing only; browse to getfirefox.com or the Chrome release channels and download ‘the other browser’. I prefer Chromium daily builds myself, but you condemn yourself to frequent manual updates. In case of FF or Chromium, the next thing to do is to browse to the Flash Player download page and get the file for plugin based browsers and install it.

And keep the browser on your system (and keep it updated), even if you start using IE10 after it’s got the Flash Player patch. Why? Because this scenario will repeat itself unless Microsoft will find a way to release these specific patches on a day-to-day basis.

“Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item” & fix

A fellow admin asked me to look into one of his daily annoyances. Whenever he wanted to run a .bat file on a Windows Server 2003 server of a file share, he received the following error:

“Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item”

I tried to right-click and edit the file, but got the same error.

I check the file permissions, but there was nothing that stood out. I vaguely remembered having to fix this before, so a quick Google search pointed me into the right direction: Internet Explorer Advanced Security Configuration.

Uncheck it in the above screen to uninstall it.

Now, usually you’d have to restart the server before this would be effective. But you can also use this little trick:

Close all Explorer windows and finally kill the explorere.exe process from the task manager.

This will (kinda) restart the Windows ‘shell’ and the settings will take affect immediately.

Next, click File -> New Taks (Run…) from the task manager menu, type explorer and press Enter. Your Windows desktop will re-appear.

You’re done now.

When you try to run or open the file again, you’ll receive the usual warning message, so you can decide yourself if you want to run the file.

Please keep in mind that you disabled Internet Explorer Advanced Security Configuration. This is a potential security risk so only do this fix if you’ve though it over thoroughly!

Keep your servers up-to-date with patches, and make it a practice to not to use the (insecure) Internet Explorer to browse the web on the server. And NEVER install plugins like Adobe Flash Player or you’ll have handed yourself a much bigger security problem.

Namebench DNS benchmark tool to speed up your Internet browsing experience

I  want to shift your attention today to a nifty tool called namebench. This freeware DNS benchmark tool finds the fastest DNS servers for your specific Internet connection by testing and measuring the response times of several DNS servers. This can greatly increase your browsing experience. A few milliseconds doesn’t seem much, but you generate hundreds to thousands DNS request per browsing session.

And as a bonus, it runs on Windows, OS X and Linux/UNIX! Download the tool here.

Complementary , here are some public DNS servers for you to test:

Public DNS servers from Google (without any filters):
8.8.8.8
8.8.4.4

Public DNS servers from OpenDNS (they may block porn and malware sites):
208.67.222.222
208.67.220.220

Public DNS servers form ScrubIt
67.138.54.100
207.225.209.66

Public DNS servers from DNS Advantage (they may block malware sites):
156.154.70.1 (rdns1.ultradns.net)
156.154.71.1 (rdns2.ultradns.net)

You can also use 156.154.70.22 and 156.154.71.22 which are advertised by Comodo

Public DNS servers from DNSResolvers (without any filters):
205.210.42.205 (cache1.dnsresolvers.com)
64.68.200.200 (cache2.dnsresolvers.com)

A Level3 DNS-Server with Anycast (multiple locations) (without any filters):
4.2.2.2 (vnsc-bak.sys.gtei.net)

A Cabe & Wireless DNS-Server with Anycast (multiple locations) (without any filters):
141.1.1.1 (cns1.cw.net)

Personally, I’m using 156.154.70.1 and 208.67.220.220 now.

Remedy Magic Service Desk & Internet Explorer 8: The Workaround / Fix

Update 20090907: Thanks to a smart workaround (in a comment below) by Andy Whelan, the fix is now without any user interaction. Change the erroneous line 978 ‘ListTable.dataPageSize = PageSize’ in file Program Files\Remedy\Magic Service Desk\Application Server\Scripts\commondetailstab.js to ‘try{ListTable.dataPageSize = PageSize}catch(err){}’ and start using IE8 =)

So you installed Internet Explorer 8. You read stories on the Internet about people cursing because things don’t work with IE8. Well, you think, they could’ve known. IE8 is W3C compliant, IE6 an IE7 are not. So all people using IE-only websites and applications now have a problem. But you are happy. The installation went fine (due to a fresh install, but whatever) and all your sites seem to work fine. It shouldn’t be a problem anyway, because if some site might not work, you have Minefield/Chromium/Opera. But then… you open Magic Service Desk, login, open an incident to add some details and…. hmmm

Argh. There you are. Error on page. No incident details. IE can tell you there is an error on line 978 in the file http://<MSD web server>/magic/Scripts/CommonDetailsTab.js. I looked into this file and it seems the DataPageSize property is IE only.

A quick Google search shows this is a known problem and Remedy recommends uinstalling IE8 (offline). Wait, not so fast!

First thing to do is to revert to ‘IE7 compatibility mode’. Open the Tools menu and select the compatibility option.

Oh wait… intranet addresses are selected by default (second checkbox from bottom)….

I guess Microsoft knows that the majority of applications are available only on the intranet and that IE6 is still the default browser in most companies. But wait, that means that the IE-7 compatibility mode doesn’t work as I expected. Thinking about it, it would be rather weird if IE8 had the completely different IE7 rendering engine under the hood.

Hmmm, so now what? Revert to IE7? No way, I want a W3C compliant browser! I found a way, but I must warn you, it’s ugly.

First, deselect the ‘Disable script debugging (Internet Explorer) option in Tools->Options->Advanced Tab

Now, open the incident in Magic Service Desk. You will be prompted to start the Javascript debugger.

Select Yes. You will jump into the debugger and go straight to the erroneous line in the javascript file.

Now we are going to ‘jump’ over the error. That means that this specific line will not be executed (interpreted). Press F11 then press Shift-F5 and then press Alt-Tab. Tada! You’re back at your incident and you see your incident details =)

Inserting  incident details follows the same path. Every time line 978 is called in the Javascript file, you’ll  have to jump over it to continue. As I said, ugly, but… it works!

Well, that’s it. Good luck to all of you and let’s hope Remedy will fix this soon. It’s kinda scandalous that this browser is available for over 6 months for developers for testing purposes and that NOBODY at Remedy seems to have taken the 30 minutes to download and test IE8 beta 1, beta 2 or RC1 on their product. Shameful…

I’ll post more if I find more apps/websites that don’t work on IE8. Stay tuned =)

Tested on Remedy Magic Service Desk 8.00.1803 and Internet Explorer 8.0.6001.18702 (Dutch version)

Windows Update keeps asking for a restart: Continued

Ok, to sum things up: I didn’t fix it. I just didn’t have the time to monitor registry and/or the file system to exactly track what happened. I will list what I HAVE done.

First I’d like to thank Greg Bray for being the first to leave a comment on my blog =) His suggestion is valid if you don’t want to be nagged all the time, but it isn’t useful if you want to install IE8.

My problem seems to be the fact that I installed the MSDN version of IE8, namely Beta 2, while the RC1 was already available to the public. When I tried to install that, the installer needed to uninstall Beta 2 first. No problems so far. After the reboot, however, the installer didn’t continue and manually restarting it didn’t help, because of the persistence of the Windows Update client telling me to reboot. The IE8 setup told me (I have to recall this from memory because I did take a screen shot, d0h) ‘Setup cannot continue because another update is waiting for a reboot’.

I feel real stupid, because I didn’t save the setup logs before imaging my PC, so now I have to retrace my steps. Ok, here goes.

– C:\Windows\IE8.log: RegOpenKeyEx failed with error 0x2. No solutions found. This seems to be a generic error though, it is also in my IE8.log now, and the installation went OK.

– Uninstall IE7. This fixed nothing. Both the IE7 and IE8 installation now report the same error. Only thing proven by this, is that it’s no a IE7/IE8 setup error.

– I checked the REG_MULTI_SZ key PendingFileRenameOperations in HKLM\System\CurrentControlSet\Control\Session Manager. It was empty.

– Reset the permissions on the HKCR and HKLM keys in the registry. No change.

– Started my computer in a clean state. I opened msconfig and selected diagnostic start up thereby disabling any non-critical service and program including anti-virus. I ran the setup. No change.

– Rebooted in Safe Mode and tried to install. Same error.

– I created the DWORD registry key InstalledByUser in HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer. I got this from http://www.ie-vista.com/known_issues.html (bullet 6). Same error.

– ‘How to solve Internet Explorer 8 installation problems‘: I followed Microsoft’s instructions and ran the command ‘secedit /configure /cfg %windir%\repair\secsetup.inf /db secsetup.sdb /verbose’. It reported that permissions on some keys could not be reset. The error was still there, but I ran out of time to troubleshoot.

So, I rebooted, fired up RIS. Waited, installed SP3, rebooted, installed IE7, rebooted, installed IE8, rebooted, installed Office 2003 SP3, rebooted, installed all other updates from the Windows Updates site (except Windows Search 4.0, yuck). And all was fine. Until… see my next blog post =P