In recent years the call for safe websites increased significantly. Various internet-organisations and privacy regulators currently are strongly endorsing measures to protect the visitors’ privacy. In alignment with this current the awareness among website visitors for this topic raises as well. Clients now expect a decent protection of their privacy while surfing on the web, quite rightly to our estimate.
An accompanying and simultaneous stimulating force behind these developments is the internet giant Google. During the years they empathically motivated website owners and builders to adopt security measures. For instance, in 2014 the corporation decided to include the visitor’s privacy protection by a website in their search engine result page. Whenever a website does not comply to Google’s standards it risks a drop in its ranking. While this marked a significant change in the thinking and practice of website security, another more recent decision of this corporation ensured an impetus for a global enhancement of website security: from the start of 2017 on Google’s browser Chrome alerts the person when visiting a non-secure web page. Google’s most distinguishing criterion for a safe web page? The usage of HTTPS!
In this blog post I highlight five of the main concerns when implementing SSL/HTTPS on an Umbraco website. Three of them are general rules, while the first two apply to the usage of the Umbraco CMS:
Let Umbraco know that the website is using SSL
When using multiple sites in one Umbraco instance, define the protocol(s)
Use protocol relative URLs
Use URLRewrite to redirect to HTTPS
Disabled obsolete encryption methods on your server
Have you ever been confronted with this message in the Umbraco log?
System.Web.HttpException (0x80004005): A public action method 'Index' was not found on controller 'Umbraco.Web.WebServices.ScheduledPublishController'. at System.Web.Mvc.Controller.HandleUnknownAction(String actionName) at System.Web.Mvc.Async.AsyncResultWrapper.<>c__DisplayClass4.<MakeVoidDelegate>b__3(IAsyncResult ar) at System.Web.Mvc.Controller.EndExecuteCore(IAsyncResult asyncResult) at System.Web.Mvc.Async.AsyncResultWrapper.<>c__DisplayClass4.<MakeVoidDelegate>b__3(IAsyncResult ar) at System.Web.Mvc.MvcHandler.<>c__DisplayClass8.<BeginProcessRequest>b__3(IAsyncResult asyncResult) at System.Web.Mvc.Async.AsyncResultWrapper.<>c__DisplayClass4.<MakeVoidDelegate>b__3(IAsyncResult ar) at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
It appears because the umbracoUseSSL is set to the default value ‘false’ while hosting the website on the https protocol. Simply set umbracoUseSSL in the web.config to ‘true’ to avoid this error. This setting ensures to implement the secure flag to cookies set after logging in into the Umbraco backoffice.
Not uncommon is an implementation of multiple websites under one Umbraco instance, all available under a different root node. For each root node a hostname/domain is specified under the ‘culture and hostnames’ setting. However a problem appears when using both HTTPS and HTTP websites in one instance while cross referencing between the different websites using the content picker in Umbraco. In that case the HTML link towards the page of the destination site uses the same protocol as the website one currently visits.
For instance, when you link with a content picker from a page on the site hosted under the HTTPS protocol, the HTML link automatically includes HTTPS as the protocol whether the destination site/page supports that protocol or not. If this destination page is only hosted under the HTTP protocol it results in a broken link.
To avoid this issue define the protocol under the ‘culture and hostnames’ setting for each root node of the sites. For example, define ‘http://examplesite1.com’ rather than ‘examplesite1.com’. The destination link now includes the HTTP protocol rather than of the HTTPS protocol.
Use https for 'Example site 1' and http for 'Example site 2'
This is a concern one has to care about particularly in implementing HTTPS on existing websites. One of the benefits of a secure page is the marking ‘secure’ in the browser of the visitor. However, if a web page is hosted under the HTTPS protocol while using resources from a non-secure origin (available by HTTP), the browser marks as explicitly non-secure. Thus the browser indicates this illusion of safety and reports this to the visitor.
The way to avoid this problem is by using protocol relative URLs. While it is common practice to include the protocol in the HTML link, for example ‘http://example.com’ or ‘https://example.com’ another possibility is just to define the link as ‘//example.com’ and just leaving the protocol determination to the browser. It will automatically use https on a secure site and http on a non-secure site.
So do not use:<a href="http://example.com/includefile.js">link</a>
Use however:<a href="//example.com/includefile.js">link</a>
This practice is especially recommended when using external resources such as hosted libraries like JQuery or Bootstrap.
A simple way to force the usage of HTTPS is just redirecting a request over the HTTP protocol to the HTTPS protocol. This is possible in IIS by setting up a redirect from HTTP to HTTPS. Just download and install the URL Rewrite module and setup a rule with these settings:
Or just look put this into the system.webServer/rewrite/rules section of the web.config, and replace <domain name> by your domain:
<rule name="redirect to HTTPS" stopProcessing="true"> <match url="(.*)" /> <conditions> <add input="{HTTPS}" pattern="off" ignoreCase="true" /> <add input="{HTTP_HOST}" pattern="<domain name>" negate="true" /> </conditions> <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent" /> </rule>
While HTTPS offers a secure connection to the web server, this secure connection is built up from different cryptographic techniques or algorithms: a protocol (f.e. SSL 2, TLS 1.2), hash (f.e. RC4, AES), cipher (f.e. RC4, AES) and key exchange algorithm (f.e. PKCS, Diffie-Hellman). Each of these techniques can vary and thus a safe connection over HTTPS uses a certain configuration existing of these four, also known as a ‘cipher suite’. When client and server connect a negotiation follows between the two which determines the cipher suite used in that connection.
The problem with these cryptographic techniques is that a secure connection may seem secure, while it is not due to the usage of one or more obsolete ones. For example SSL 3.0 has been compromised (POODLE), the RC4 cipher (BEAST) as well as the Diffie-Hellman key exchange (Logjam). It is therefore imperative to disable the techniques that are insecure and consequently the cipher suits consisting of these obsolete techniques.
The management of cipher suites and cryptographic algorithms is a Windows affair. While this can be done by direct manipulation of the registry (see for example this article on Microsoft support) there is also a nifty little tool that lets you go through all the options by a user interface is: IIS Crypto. This third party and free tool lets you diasable and enable the various algorithms, and you can change the cipher suite order freely as you want. However you can select the best practices template and the software will do the work for you.
IIS Crypto
You can check out the security level, vulnerabilities and recommendations of your hosted environment SSL Labs.