TLS/TLSv1.2 FAQs
- What exactly is TLS anyway?
- Why Is TLS 1.2 necessary?
- What are the consequences if I don’t upgrade to TLS 1.2?
- How can I tell if my site is vulnerable?
- I updated our SSL certificate. Isn’t that good enough?
- What do I need to do to ensure that my site is compliant?
- What browsers/versions will provide the option for TLS 1.2?
- Whare are some popular libraries to implement TLSv1.2?
- Why TLSv1.2 when TLSv1.3 is already out?
- What are the recommended ciphers for use with TLSv1.2?
TLS stands for “Transport Layer Security.” It is the security protocol that allows computers to communicate over the internet securely, without the transmissions being vulnerable to anyone they aren’t intended for. Without TLS, you wouldn’t be able to use your credit card on eCommerce sites or log into your bank account online.
Due to several weaknesses found in TLS 1.0, many websites and internet services are now starting to require the use of TLS1.2. The latest PCI compliance standards require that any site accepting credit card payments use TLS 1.2 after June 30th, 2018*. Even though you have some time before it is required for PCI compliance, several internet services are moving to require the support of TLS 1.2 as early as next year. Services such as PayPal, Authorize.net, Stripe, UPS, FedEx and many others already support TLS 1.2 and have indicated that they will eventually refuse TLS 1.0 connections. The dates for when they will refuse TLS 1.0 connections are not clear, but your safest action is to upgrade to TLS 1.2 sooner than later.
First and foremost, your customer’s data is at risk. In the event of a data breach, consequences for not being PCI compliant can include fines and your merchant bank can terminate your ability to process credit cards.
Second, crucial functions on your website will stop working overtime as the services your website uses require TLS 1.2. This means that your payment processing and real-time shipping rates could stop working at some point over the next year if you don’t address it.
The easiest and one of the simplest way to test the security of your site or web server is to run your website through the online ssl tester. The link for this SSL web server tester is here . SSL Labs by Qualys is a collection of documents, tools and thoughts related to SSL. It's an attempt to better understand how SSL is deployed, and an attempt to make it better.
No. To put it simply, your SSL certificate is literally step 1 of "50" to ensure that your webserver is hardened. There are a lot of configuration that needs to be done on your server to ensure that all aspects of server is closed to any sort of attacks. I would suggest also revisiting the page about "PIC" model to get a feel of what I am aiming at over here.
There are multiple configurations in most web servers which are weak by default. They use weak protocols such as SSLv2 or SSLv3. They support broken cipher suites such as RC4 etc. Security features such as HSTS, OCSP stapling are disabled by default.
In short, carefully vetting each and every aspect of configuration must be done meticulously to ensure that there are no holes that a potential adversary can use as an advantage to squirm their way into the server.
Unfortunately, this is not a simple answer. There are several variables and a number of systems and software platforms involved. Every business has a different configuration, and there is no easy set of step-by-step instructions that will work in all cases.
Below is a simple example: At a high level, you will need to ensure that the following platforms and connections are compatible with TLS 1.2:
- Web Server
- Internet Information Services (IIS)
- .NET Framework
- Maybe some eCommerce Application
You may also need to look at the compatibility of the browsers you support for your users as well as any web services involved in your payment and fulfillment process.
Another good practice is run your website through a bunch of tests in the SSL Labs site and ensure that your grade is A and above.
These browser versions will support the option to use TLS 1.2, regardless of what operating system they are used on. Below is a list of the browsers and versions that are usually certified for use on most third-party softwares and support TLS 1.2.
Browser Versions
------------------------------------
Internet Explorer 8, 9, 10 & 11
Chrome 42, 43 & 44
Firefox 34, 35 &36
Safari 7 & 8
Python:
ssl library
pyopenssl library
Java:
If your application runs on Java 1.7 or Java 1.6 (update 111 or later), you can set the https.protocols system property when starting the JVM to enable additional protocols for connections made using the HttpsURLConnection class – for example, by setting -Dhttps.protocols=TLSv1.2.
C++: Botan, PolarSSL, Mozilla NSS, Wolf and GnuTLS.
All except Botan are not C++ specific so they do not have nice C++ objects and resource management.
According to IETF document Overview and Analysis of Overhead Caused by TLS, For everything but very short connections, TLS is not inducing any major traffic overhead (nor CPU or memory overhead). Server people from Google Gmail has stated that “TLS accounts for less than 1% of the CPU load, less than 10 KB of memory per connection and less than 2% of network overhead”. Main impact of TLS is increased latency, this can by reduced by using session resumption, cache information closer to end users, or waiting for TLS 1.3.
GoDaddy, Symantec, Digicert are some of the well known CAs around. You could also consider options like Let'sencrypt which are free and well-trusted.
Simply for backware compatability. While TLSv1.3 does provide better configurational options in terms of improved versions of algorithms as well as improved performance, adoption of new protocols is slow and that might mean issues in interoperability. The safe option in this case where TLSv1.2 and TLSv1.3 are both equally safe protocols, is to run an environment which supports both the protocols.
TLS Recommended Ciphers:
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289
Avoid the following ciphers:
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256