The basic tenets of data security (confidentiality and integrity)- data must be protected while in motion and at storage (rest). Let me focus on data protection while in motion today.
It’s important that companies do comply with regulations but it is more important to secure the data from unauthorized access and go above and beyond what regulations call for. Regulations require that data in transit must be encrypted while travelling over public internet. What happen when data travels between on-premise data centers and cloud providers (Azure, AWS) and vice-versa? Let me be little specific, do you think data is encrypted end-to-end when travels over dedicated private network (Azure Express Route or AWS Direct Connect and on-premise data center)? The short answer is- No. While your connection may be encrypted between your on-premise data centers and co-locations (i.e. Equinox), connections between co-locations and cloud gateways are not encrypted. Point here is, you may be in compliance in terms of regulations but data is not secure (encrypted) when travelling over dedicated private network.
Okay, you have got some context and we need to go beyond what required by regulations. TLS (Transport Layer Security) should be implemented at the application endpoint and end users. Same is true when dependent systems are communicating between on-premise data centers and cloud providers. For security best practice, you may be exposing the application endpoint via Azure Application Gateway or AWS CloudFront. Both of them do support WAF, DDOS, etc. and they do integrate with many other cloud services natively. Endpoints should be configured with TLS v1.2 or v1.3(if available) and with strong cipher suites. For the purpose of this post, we would be focusing on Azure Application Gateway and how we can customize the SSL Policy to achieve A+ rating at SSL Lab tests.
How do you go from A (or B) to A+ rating at Azure Application Gateway? Unlike AWS CloudFront, Azure Application Gateway allows customer to adjust the cipher suites (a plus for Azure on this important capability). First thing first, we would select the cipher suites (RSA in my case) those are recommended by NIST (Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations). Let’s take a look at the section 3.3.1.1.2 of SP 800-52 Rev. 2.
NIST does not recommend use of TLS_RSA_* cipher suites because they don’t provide perfect forward secrecy. So, we would select TLS_ECDHE_RSA_* ciphers at App Gateway. You would configure custom SSL Policy at app gateway Listeners and select TLS v1.2 as minimum protocol version. Then, edit the cipher suites. In my case, I selected the following-
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
The above configurations may get you a score of “A”! There are two items in Qualys report those were highlighted for my certificate (api.aspnet4you.com)- DNS CAA and Certificate Transparency. If you are the admin of domain registrar, you can add CAA record for the domain. My domain is registered with GoDaddy and I followed GoGaddy’s documentation to add CAA record at my domain.
Are we there yet? No, I still get the score of A from SSL Labs! My next task is to fix Certificate Transparency. This is not in my hand and I contacted my certificate issuer (COMODO). Techs at COMODO knew what I was talking about and they told me certificate transparency would not get me A+! They advised me to enable HSTS at the endpoint.
I am using Azure App Gateway Standard Tier and it does not have the feature to add custom response headers. Standard V2 has the feature but I was not going to pay extra just for one extra feature! So, I moved to the backend which is a dotnetcore app deployed at App Services. Two things need to be done for HSTS- auto redirect all HTTP requests to HTTPS and add “Strict-Transport-Security” custom header. First part was easy, just enable the auto redirect by marking the checkbox at the app service. For the second part, I had to edit the web.config file to add the custom header.
It’s time to test the rating/score again, let’s test at SSL Labs! Yahoo!, we got A+! Now that I know I still have Certificate Transparency in yellow, I would fix it at the next renewal of the certificate. Why settle for less!
For the sake of comparisons, I look at the NSA.Gov and the site is configured with Tls 1.2 and Tls 1.1 and bunch of weak ciphers. NSA.gov is not configured for DNA CAA but it complies with Certificate Transparency. So, I am yet to figure how it still managed to score A+! NIST.Gov, on the other hand, is configured for Tls 1.2 and same set of ciphers used in this example. NIST is not configured for DNA CAA but it is configured for Certificate Transparency and the score is A+. Hope someone at Qualys has better explanation as to why NSA.gov or defense.gov got A+ with Tls 1.1 enabled!