Secure and Optimized TLS | SolidCode

CONTACT US

Thank you for your interest in SolidCode Us. Please fill the form below, or contact us at:

617-755-5200

Skype: SolidCode US

MESSAGE SENT

You will receive reply to the email you provided.

Thank you.

Upload file

Your Web Solutions Partner

Blog

Secure and Optimized TLS

By Cyrus Khamak 2 Years 11 Months ago

This article is part of a web performance and web optimization series I had promised you at the bottom of this page. The main purpose of this topic is to have a basic understanding of how a network connection that uses TLS/SSL gets started and how this process may affect a website’s performance and page load speed. Furthermore, let us try to make sure that we install our TLS correctly, set up our server optimally and make sure that the installed TLS gives us the intended protection against the bad guys. In the meantime, there seem to be a confusion regarding TLS and SSL, so let us clear that out first:


SSL (Secure Socket Layer) was invented by Netscape Navigator and has been around for over 21 years. SSLV1 was never released. SSLV2 was released in 1995 but due to many security holes, in 1996, it was replaced with SSLV3. Since then, many security compromises in SSLV3 have been identified and corrected. As an aging protocol, it was only a matter of time before someone would find the next big issue in SSL and after 19 years of industry service, would force it to rest.


TLS (transport Layer Security) has been in existence since 1999. After Poodle Atttack on SSLV3 on October 14 of 2014, TLSV1 became a clear replacement for SSLV3.  To make the transition smooth and seamless, one could consider TLSV1 as SSLV3.1 and TLSV1.1 as SSLV3.2 and TLSV1.3 as SSLV3.3  In fact in “Client Hello” section of SSL Handshake, client using TLSV1.2 for instance, would introduce itself as using SSL{3,3}.


TLS or SSL is not the cure-all answer for an application security. It provides identification, authentication, confidentiality and Integrity of data in TRANSIT ONLY. Therefore, SSL is just ONE part of an overall application security. Furthermore, for TLS to be effective and to protect our data in transit it must be installed properly and the server also must be configured correctly.


At least for the past several years, website performance and page upload speed has been in the forefront of application development best practices. In fact, as far back as April of 2010, Google announced that website upload speed would be a factor in search engine ranking. We also know that in 2014 Google started to give a ranking boost to TLS/SSL secured websites. Recently, it has become even more aggressive by suggesting that HTTPS should be everywhere on the net..


While secure sites and “HTTPS everywhere” are necessary and welcome innitiatives, then how about its “negative impact” on site performance? After all, on a secure website, we make frequent extra calls to server and the server in turn, makes extra number crunching to encrypt data and keep a connection secure.


There certainly seems to be a performance cost overhead when switching to HTTPS. As mentioned above, with each transaction, there are extra calls to server and there is also some stress on the CPU encrypting and decrypting complex strings of characters. But the question is, with today’s high bandwidth network connectivity and CPUs that support dedicated AES cryptographic instructions at hardware level, can we still afford to compromise our online data transmission? Isn’t an extra 1-3% of CPU number crunching worth protecting our visitors and users’ data exchange?


If TLS is properly installed and some optimization steps taken, it will provide even more security and its performance overhead will be drastically minimized.


Before we do any TLS optimization however, we need to install TLS on our server. if you don’t want to pay for a TLS certificate, the folks at  Lets Encrypt  are doing a great job of providing it for free.


After TLS installation, you can go to SSL Labs and test your new install and examine your server configuration. Check the security level and whether your server is vulnerable against SSL downgrading, or any of the known attacks such as Poodle and Beast. Any TLS or server configuration warning need to be addressed otherwise your TLS install would probably not fully protect your data in transit. For instance, if you have weak cipher suite on your list, they will look as follows and they will have to be removed and/or replaced:


 

Cipher, SSL 3

 

 

Do you have HSTS Response Header installed?


HSTS is a security enhancement and an acronym for HTTP Strict Transport Security. It is a server setting that requires user agents to, next time, access a website using secure HTTPS connection ONLY. During the first visit of a client to a website however it can go straight to the HTTP version of a page, instead of HTTPS. This can happen inadvertently through using a bookmark or maliciously by requesting the insecure HTTP version of a page if it exists. At this point, the server feels violated and redirects the user agent to the HTTPS version of the page instead. So you see, even with the use of HSTS, the first visit of a client can always be an insecure one and an attacker can already do damages. Also, when you compare the 301 redirection overhead of 100a of ms, to browser redirection of several ms, we can clearly see the performance advantage of HTST for clients’ subsequent visits.


Finally, if you have properly installed HSTS and optimized TLS installation, you should receive an A or A+ from SSL Lab:

 

SSLLAB
 

 

As much as HTTP Strict Transport Security can help, that very first client visit to a page could be insecure. To take full advantage of HSTS, you may submit your site to the Chromium HSTS Preload list.  


If you are serious and would like your site to be protected against the first visit also, then you may want to submit your domain to HSTS preload list. This is a list maintained by Chromium Projects and the domains on this list are hard coded in Chrome, Firefox, Safari, Opera Ie and Edge. Please read and review the “Removal’ section at the bottom of this page, as it would take months to remove your domain from the preload list. If you are interested in this subject, you may read more about it at Mozila Developer Network


If you don’t have any special reason for not adding your domain to preload list maintained by Chromium, doing so will greatly improve your website’s security. This is so as the first time visitors will also be redirected to the HTTPS version of your site and it will be done at the browser level. According to Netcradt report, a vast majority of servers (95%) are not protected against secured connection downgrade vulnerabilities such as MIMA attach and Logjam attack. As a result, an attacker can force a user agent to make unencrypted connections to these servers and steal or modify the user data. HSTS header can further protect against other vulnerabilities such as malicious cookie hijacking. HSTS is supported by almost all modern browsers.


Now that we have covered the basics of TLS installations, we are ready to see what happens when we make a connection to a secure website. We know that the process starts with a TCP and a TLS handshake, which I will cover in the next and final pat of  Secure and Optimized TLS. For now, I will leave you with this

 

 

TCP-SSL Handshake

 
^