ssl Archives - Richard J Green

Azure Web App SSL Cipher Suite Changes

Richard Green on 4th June 2015

Earlier this week, I got an email form the Azure Team to announce that as part of security improvements to the Azure App Service Web Apps (formerly known as Azure Websites) they will be making changes to the supported SSL cipher suites with the changes taking effect as of July 18th 2015. Additionally, Microsoft have provided a test site that is running the new suite of ciphers at https://testsslclient.trafficmanager.net.

I decided to take the test site for a drive over on the Qualys SSL Labs tool the SSL Server Tester. I’ve been using this site for a long time now as a means to test SSL enabled websites as it allows you to verify the whole configuration in one place including the certificate, protocols and cipher suites. I ran the test site through Qualys SSL Server Tester as well as this blog which is running on a current generation Azure Web App site to compare the results.

It’s important to understand the difference between a Web App and a Cloud Service before we get much further into this too. Some people will be looking at this post and thinking why don’t I just enable or disable the relevant protocols or ciphers within my application however herein lies the difference between the Web App and a Cloud Service. The Web App in web hosting terms is a website running on a multi-instance web server. A Cloud Service is a dedicated instance that you are responsible for so allow you more control but at the expense of additional complexity. With a Cloud Service, we can configure the ciphers and protocols as part of the service definition which runs in the form of a start-up script. With a Web App, we don’t have any of these levels of deep system level access so have to accept what we are given.

Running the test on this site, richardjgreen.net I get the same result I have achieved for some time, a overall score of Grade B. The grade in this instance is limited to B because the server is allowing weak RC4 ciphers as well as a Triple DES (3DES) cipher. Additionally, the current site does not support Forward Secrecy, sometimes seen at Perfect Forward Secrecy or PFS for short. The final message stating that the site only works with browsers supporting Server Name Indication or SNI for short is not a security failure. This is due to the fact that I have opted to only support SSL for SNI browsers on my Azure Web App instance.

Running the test again against the test site, we can see that the result has improved to an overall score of Grade A. This is achieved because support for the weak RC4 ciphers has been dropped along with the Tripe DES (3DES) cipher. Additionally, the cipher suites have been re-ordered slightly and a new SHA384 3072 RSA key cipher has been added at the top of the cipher suite order meaning that this cipher should be the most preferable to use.

Looking at some of the details for the test, I also appears that the Web App instances are being built now on Windows Server 2012 R2 although how long this has may have been the case, I do not know? In the HTTP Server Signature for the SSL Server Tester results, richardjgreen.net shows Microsoft-IIS/8.0 whereas the Microsoft test site shows Microsoft-IIS/8.5.

I look forward to re-running the SSL Server Tester after the 18th July and seeing if the test result for my own site is as good as the test site shown.

SSL Certificates and Wild Pricing

Richard Green on 9th October 2013

As part of a project of work I’m looking into currently, we are planning a move from Exchange 2007 to Exchange 2010. As those of you who’ve done this before will know, you need to setup the environment with two namespaces for a period of the migration which Microsoft refer to as the Exchange 2010 namespace and the legacy namespace (the Exchange 2007 namespace). As part of this, we need to get a new SSL certificate.

Normally we buy our certificates from VeriSign as a standard rule of thumb however after looking at the costs today, I’m starting to wonder how VeriSign do so well in the SSL certificate business? I’m not going to go into exact specifics, but the overall cost for the certificate I was looking to purchase was £69,000 which is frankly unbelievable for a certificate to secure a messaging platform. The cost of the certificate is over double what we paid for a pair of HP DL380p servers fully loaded with 900GB SAS disk for local storage to host the DAG Mailbox roles. To make it worse than just the price on it’s own, that’s just for one year validity on the certificates too.

Out of curiosity and because they are starting to develop a bit of a name for themselves, I decided to compare the cost of this to GoDaddy. That very same certificate, offering me the same number of SAN names for the Exchange features with GoDaddy is a mere £165 a year.

How I wonder, when you compare £69,000 to £165, do VeriSign actually sell any certificates? Sure VeriSign offer more in the way of commercial compensation that GoDaddy ($1,500,000 for VeriSign and $160,000 for GoDaddy) but commercial compensation really only applies to transactional or commerce websites. When you are talking about a messaging platform, coupled with a two factor authentication system, the compensation loses it’s value quickly. GoDaddy offer a Malware inspection service for secured sites, something which VeriSign also offer. VeriSign have some value add propositions that GoDaddy don’t, I will grant them that. Features such as Norton Secured Seal and a Symantec Search Seal are on offer but both of those things are dependant on people having Norton software and browser plugins installed to show the seal. Installing browser plugins which really aren’t needed and adding a true sense of value is something which I don’t recommend and nor do Microsoft hence the popups that modern versions of Internet Explorer have asking you to disable addons.

With GoDaddy being so popular these days, their Trusted Root CA certificate is valid on a claimed 99.9% of devices therefore gone are the days of use the likes GoDaddy or Comodo SSL at your peril due to the possibility of getting certificate invalid warnings on the clients.

I haven’t taken a decision on the purchase just yet as it needs some consultation within the company, but one or two people I spoke to today agreed with me in so much as why shouldn’t we use GoDaddy and frankly, I’m not seeing a lot of reasons why currently?