HTTPS Fundamentals and Configuration - 1

Recently, I encountered something related to SSL, so I opened a new topic on a whim - “HTTPS Basic Principles and Configuration”

This article is the first article to introduce the SSL TLS encryption protocol.

Cryptographic protocol history summary

The SSL TLS encryption protocol doesn’t actually have a long history, 1995NetscapeSSL v2.0 was released, which was also the beginning of web encryption. This allows people in the e-commerce world to submit passwords and credit cards online and at least be fairly secure.

SSLv3.0 was released soon after, and this version was completely rewritten by Paul Kerker and others. This is a very solid agreement. In fact, IETF uses SSL v3.0 and makes it a protocol that is not unique to Netscape, called TLS (Transport Layer Security). SSL stands for Secure Sockets Layer, but is now called Transport Layer Security.

So, TLS v1.0 is almost identical to SSL v3.0, with one or two minor optimizations and standardization by IAF. If you dig deeper into these protocols, TLS v1.0 is actually SSL v3.1; so you can think of them as continuous.

But eventually the IETF came up with a new version v1.1 (with some minor optimizations) and then v1.2, introducing some new cryptographic algorithms. But seeing this you might think “OK, some clients support these, some clients support newer ones, depending on when they’re released. It may not be too much worse in terms of security”. But in reality, most of these have been cracked in a security sense.

Key historical nodes

• SSL v2.0 was released in 1995 with Netscape
• SSL v3.0 released in 1996 Fixed major issues with v2
• TLS v1.0 1999 IETF released; Minor optimizations for SSLv3
• TLS v1.1 2006 Minor optimizations released
• TLS v1.2 released in 2008 Improved hash and AEAD patterns

😂 Cracked historical synopsis

The first is SSL v2.0, which was cracked at the beginning of its design: joy:😂😂, so SSL v2.0 is really not recommended; it has been cracked for a long, long time, and it is not safe. The supported SSL versions we often hear about generally start with SSL v3.0.

SSL v3.0 was used until it was cracked in November 2014.

TLS
v1.0 and v1.1 are basically secure.

The latest v1.2 (in fact, it is not the latest now, TLS v1.3 has come out, but the latest protocol in the mainstream is still 1.2), is the only version that has not yet targeted attacks (PS: Of course, there have been vulnerabilities for TLS v1.2 recently, but it is OK).

TLS has a confusing history and doesn’t really have the best security record, but TLS v1.2 has always been the best, and when it comes to interacting with browsers and services, it’s built into almost everything in browsers and servers (up to date).

So, TLS
v1.2 is the trend if it involves business-critical data interactions, such asUser critical information pay financeIn other scenarios, TLS v1.2 can be truly guaranteed, and other old encryption protocols have been cracked, and it is only a matter of time before hackers want to get your data (if you use old encryption protocols), and there is no technical difficulty. Therefore, the evaluation of ATS (Apple’s security-related requirements) compliance also requires this version.

😂 Cracked key history node

• ❗❗❗❗❗ SSL v2.0 released in 1995 - Cracked at the beginning of the design
• ❗❗❗ SSL v3.0 released in 1996 – cracked by POODLE (2014.11)
• ❗❗ TSL v1.0 released in 1999 – Vulnerabilities discovered by BEAST (2011) and Lucky 13 (2013).
• ❗ TLS v1.1 released in 2006 – vulnerabilities discovered by Lucky 13 (2013) and RC4 (2013, 2015).
• TLS v1.2 2008 released – safe only in AEAD mode

Client compatibility

❗ Note:

If conditional, highly recommendedSelect TLS v1.2 onlyVersion. (For traditional companies, it’s really hard to do)

According to the above content, then I only choose the TLS v1.2 protocol, but the actual situation is that TLS v1.2 is2008It was released only (annotated release), and it took longer to actually implement it. Therefore, many clients do not support TLS v1.2.

These clients, aregeneralizedof clients, including:

• operating system
• browser
• cell phone
• Rich clients (such as Java clients)
• …

So, if you plan to only choose version 1.2 of the server, you may lose a lot of potential customers (customers who are still using old clients, and of course, employees with old computers will be turned away…). This is not the best move, unless it is very sensitive to absolute security. Otherwise, it is still recommended to support more security protocols so that more customers can be compatible. Right? After all, compared to HTTP this naked, other old protocols are still wearing clothes.😏

However, other large platforms have begun to lean towards v1.2. For example, before iOSATS compliance requirementsLike whatMicrosoft recommends that you drop support for TLS v1.0 and TLS v1.1。 As a result, the industry is moving towards standards.

List of clients that support TLS v1.2

• Windows 8 and above (Windows Server 2008 and above - supported in the second half of 2017) (❗ Win7 not supported!) Not to mention Win XP)
• RHEL or CentOS ≥ 6.5 (❗ Note with CentOS 5.X, TLS v1.2 is not supported)
• Chrome ≥ 30
• Android ≥ 5.0
• Firefox ≥ 27
• IE/Edge ≥ 11 (❗ mainstream IE8 9 10 is not supported!)
• iOS ≥ 5
  • Note: iOS 9 apps require TLS 1.2 support. (ATS compliance requirements, which seemed difficult to push down at the time)

List of clients that support TLS 1.0

TLS 1.0 (the oldest version of true security) is supported almost all (except for win XP SP2).

Configuration recommendations

Recommended againSSL Labs, the scores are as follows:

High security Low compatibility

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1

Only TLS v1.2 is supported. When you configure the encryption protocol, if only TLS is selected
1.2, the score will beA。

Medium security High compatibility

SSLProtocol all -SSLv3

Only supportedTLSProtocol, the score will also beA. (Previous, not sure in the near future, interested can be measured).

Low security Maximum compatibility

SSLProtocol all

If you use SSLv3.0, you are risky, get C.

summary

The choice of encryption protocol should be based on specific needs, focused, and also achieve both security and compatibility.

I had a related PPT before, if you are interested, I will post it later.