Let me start by painting a picture. You are using Azure. You have an App Service configured with a Web App that is hosting a website; this website for example. The website could be single-instanced or it could be multi-instanced using Azure Load Balancer, Azure Traffic Manager, Azure Application Gateway, or any other number of load balancing and traffic distribution technologies. One day, your web application fails to respond and you get a dreaded HTTP 500 or another error code. As a dedicated Azure consumer, you use Azure Application Insights to monitor your website. Application Insights not only gives you user metrics akin to Google Analytics but also gives you performance and availability metrics.
The picture I painted just then explains my scenario. I use Azure App Service with an Azure Web App to host this blog. I use Azure Application Insights to provide me with all of the metrics and data I need to understand the site. The availability monitoring feature is quite excellent. It allows me to monitor the website availability from up to five locations around the world with performance data for each region so I can see how the site performs for each geography. If the site goes down for any reason, I get an email notification to warn me.
An email landed in my inbox this morning from Microsoft Azure regarding HTTP Public Key Pinning, a subject I have posted about at some length recently. If you don’t know what HPKP is or how it is used, refer back to some of my previous posts on the subject.
A normal HPKP implementation would see you configure your website to pin your own public certificate. Whilst I would advise against it because you have no ownership or control over the certificates, it would be entirely possible to pin the Microsoft Azure Websites certificates using HPKP to your site. The email from Microsoft this morning was an advisory that Microsoft is changing the certificate it uses.
If you are using HPKP and think there is a chance you may have pinned the Microsoft certificates, I would strongly advise you to read the Microsoft Knowledge Base article at https://blogs.technet.microsoft.com/kv/2017/04/20/azure-tls-certificates-changes/?WT.mc_id=azurebg_email_Trans_33716_1407_SSL_Intermediate_Cert_Change for more information.
If you are unsure if you are using HPKP or if you are unsure of which public keys you have pinned, I would suggest you use the Qualys SSL Test site as this will report the certificates in use with HPKP and whether it is enabled.
Deflate and GZip compression have been with us on the web for many years. They do a decent job but as times move on, so do compression algorithms. This is something I have talked about before using services like TinyPNG to squeeze the spare bytes out of your images to reduce page load times but this only applies to images obviously.
Brotli is a Google project for a newer, more modern compression algorithm for the web. According to the claims of Google, using Brotli over GZip not only increases the content compression reducing page size but also reduces CPU usage in the decompression process too. With the ever expanding usage of mobile devices, both of these are great things to have.
If you are interested in reducing your page size to improve load times and reduce your outbound bandwidth on your site then read on to learn now. I will cover the requirements, fallback compatibility and also how to get Brotli for Linux and Windows as well as the main point, how to enable it for an Azure Web App.
In previous posts, I’ve talked about implementing web security features such as HTTPS, CSP, HPKP and HSTS. Almost all of these are things we can configure ourselves within our web applications responses to client requests however one of these features, HSTS requires a little more work to fully implement.
HSTS is a technology of two halves. HTTP Strict Transport Security (HSTS) is a feature which allows a website to instruct the client that it should never be downgraded to HTTP and should only ever request and receive data from the site over HTTPS. We can easily implement this, in the case of Windows and IIS, using a web.config file outbound rewrite rule which I covered in the previous post, Working Hard on Web Security.
The trouble is, this is only half the battle. If a client repeatedly visits your site, their browser will know as a result of previous visits to always use HTTPS due to having previously seen the HSTS header but what about new visitors? What happens if your site is victim of a downgrade attack between you implementing HTTPS and HSTS and the first time a user visits? Their browser doesn’t know it should be using HSTS already so we have a problem.