Today, HTTPS is faster and more secure, and more business websites use HTTPS than ever before. As busy as a web developer or network architect remains, it can be difficult to keep up with the latest developments in internet technology.
In this article, I'll discuss the best ways to secure modern websites with SSL. In addition to ensuring the security of corporate websites, modern SSL also takes into account performance. Therefore, this article will cover some SSL optimization methods that can help improve website performance.
Before discussing the so-called best approach, let's first look at a few SSL and TLS terms. Technically, SSL has been replaced by the TLS (Transport Layer Security) protocol, but most people still confuse SSL and TLS as SSL. This article still uses this idiom unless there is a version number after SSL.
Second, it's also important to have a basic understanding of the SSL/TLS handshake before diving into the discussion. This handshake occurs when the browser connects to the server via HTTPS, and is a method agreed upon by the client and server for session encryption. There are several different types of TLS handshakes, but the RSA handshake diagram shows the relevant parts.
First, the browser sends a large random number and a list of cipher suites to the web server, thus starting the TLS handshake. The web server chooses the primary cipher suite, which determines the type of handshake and the encryption mechanism used for this TLS session. The web server then sends the cipher suite to the browser, and also returns another large random number and the server's public SSL certificate to the browser. The browser needs to know if an SSL certificate is revoked, so it checks the CA's certificate revocation list (unless OCSP wrappers are supported).
If the certificate is still valid, the browser generates a "pre-master key" to generate a symmetric session key. The browser encrypts the "pre-master key" with the server's public key (contained in the server's SSL certificate) and transmits it back to the server. After the server decrypts the "pre-master key" with the private key, both the browser and the server obtain the symmetric key, which is used to encrypt the rest of the TLS session.
Each of the measures discussed in this article can make these steps safer or faster. The ssl certificate application can be applied in Wei Keyun.
Take advantage of the security features of modern SSL
There are many steps in the TLS handshake, which means that security administrators have many opportunities to improve the security of a website. Here we first discuss HSTS forcing HTTPS connections, then look at the current state of SHA-1 and SHA-2, how to protect future user session data, and the importance of upgrading to the latest TLS version.
Support HSTS header
Supporting the HSTS protocol is one of the easiest ways to better secure websites, APIs, and mobile applications. HSTS is an extension to the HTTP protocol that forces clients to use a secure connection for every request to a web server. By providing a Strict Transport Security (STS) header, a web server can tell browsers to connect to a website via HTTPS only during a specified period of time.
The browser then automatically turns all http requests into https requests before sending the user's request to the server. HSTS also tells the browser to display an error page when there is an issue with the security of the connection (for example, when the server's TLS certificate is no longer trusted). This type of error, unlike errors that users can intuitively ignore, cannot be circumvented.
This type of link rewriting provides protection against certain types of "downgrade attacks" such as SSL-stripping attacks, which prevent man-in-the-middle from snooping on user communications by turning HTTPS requests into HTTP requests.
Support SHA-2 certificate signing
SHA-2 is the next generation version of SHA (Secure Hash Algorithm). The hash algorithm is a one-way function that produces the unique fingerprint of a message and has been a key component since the inception of the Internet.
After the CA issues the TLS certificate for the website, it obtains all the information in the certificate (domain name, legal period, public key, serial number, etc.) information to create a signature and generate a private signing key. Before the browser can trust the server's certificate, it needs to hash the certificate information and use the CA's public key to verify that the fingerprint matches the certificate's signature.
If an attacker can generate the same digital fingerprint using different certificate information, it is possible to generate a fake certificate that can still be verified by a CA signature. An attacker could then use this forged certificate as a man-in-the-middle, and the end user wouldn't be able to tell if they were sending their sensitive information to someone on the Internet instead of a secure web server.
Generating such hash collisions requires significant computational resources. As computers get faster and cheaper, the more likely it is that an attacker can forge a TLS certificate signed with SHA-1. The solution is SHA-2.
Modern websites all use TLS certificates signed with SHA-2 instead of SHA-1. If a corporate website is still using SHA-1 certificates, major browser vendors will display a warning message telling the site's visitors that they are visiting an insecure site. By the end of 2016, browsers will completely block users from accessing such sites. In order to upgrade, the corporate website needs to purchase a new SHA-2 certificate from its own CA and install it on the web server.
If an enterprise still needs to support users who cannot use SHA-2, consider utilizing a certificate that selects the highest security and that the user's browser supports.
Encryption with EDH (Ephemeral Diffie-Hellman) support for forward forwarding
If the server keeps using the same private key to obtain the symmetric TLS session key, the private key becomes a weak link in the chain. For example, if an attacker logs a lot of communication between the server and the user, the private key can be stolen from the server, and the communication can then be decrypted.
EDH (Ephemeral Diffie-Hellman) or DHE can make a user's encrypted session more secure even if the private key is stolen at a later date. EDH is a key exchange mechanism that produces a unique symmetric key for each session, which means that even if the server's private key is stolen for years, an attacker cannot use it to decrypt recorded sessions.
Only supports TLS1.2
Encryption systems are not static, so a secure web server should always fully support the latest and greatest improvements in Internet security. Ideally, a corporate website should not support any system less than the latest version of TLS. Early versions of the TLS and SSL protocols included outdated cipher suites or some insecure implementations, which made an enterprise's encrypted communications vulnerable to attack.
TLS connections rely on client and server capabilities. Security managers may be concerned that if corporate websites don't support older versions, it may affect the customer experience, but in fact, most browsers have supported TLS 1.2 for a long time.
By the end of June 2016, upgrading to TLS 1.2 will be mandatory for businesses that must comply with PCI. So, now we have reason to implement a TLS1.2-only policy for websites.
Keeping your server's SSL up to date has real implications for the security of your corporate website. SSL3.0 is vulnerable to POODLE attacks, and also to compromised RC4 encryption with security issues. TLS 1.0 fixed this problem, but discovered a new vulnerability: incorrect handling of implicit initialization vectors and padding errors, resulting in insecure encrypted CBC. TLS1.1 is the same and vulnerable to Lucky 13 attack. TLS 1.2 supports the use of the AES-GCM cipher suite without the same vulnerabilities of CBC mode encryption.
Get the most out of modern SSL performance optimizations
SSL used to be much slower than HTTP, which is why many web developers and network managers prefer to use "http://". However, the development of Internet technology has made SSL more efficient. By taking advantage of the latest TLS performance features and SPDY or http/2 technologies, modern SSL websites tend to be faster than unencrypted websites.
Support OCSP encapsulation
CA and TLS are not always reliable. Sometimes a CA issues an unexpected certificate, sometimes a company changes its security policy in a way that makes the certificate invalid, and sometimes a certificate's key is stolen by a malicious user. Whatever the reason, CAs and browser vendors recognize that they need a way to revoke certificates that can be compromised.
In order for users of a website to trust the TLS certificate that the server handed them to, they need to query the Certificate Revocation List (CRL) maintained by the CA to see if the certificate has been revoked. Unfortunately, this extra revocation check can delay the user's page loading, and the browser has to wait until the CA returns the status of the TLS certificate. This check also often requires DNS lookups and downloads of many revoked certificates, resulting in a huge performance sacrifice.
The OCSP wrapper is part of OCSP, which fixes some performance issues with real-time revocation checking. Therefore, the Web server no longer forces the user's browser to directly query the CA, but the server itself queries the CA at a certain time to retrieve the OCSP response. This response is issued by the CA, proving the validity of the TLS certificate for the specified time period. The server can eliminate unnecessary round-trip time to the user's browser.
Support ECC (Elliptic Curve Cryptography)
ECC is a contemporary alternative to RSA. ECC uses the mathematical properties of elliptic curves to create one-way functions, which become the basis of public key cryptography.
The benefit of using ECC is that ECC requires a shorter key, so there is little need to transmit data to the end user's computer, speeding up the initial TLS handshake. Also, ECC takes 10 times less time to sign than RSA. Every handshake needs to be signed by the private key, so ECC can actually reduce the load on the server.
Support to restore TLS session through session ticket (Session Ticket)
Needless to say, TLS is expensive, but TLS does include a way to avoid unnecessary handshakes. Session resumption of TLS can use the symmetric key of the previous session to reconnect the client and server. This eliminates the need for additional data round trips and the cost of acquiring a new symmetric key. There are two different TLS recovery mechanisms: tickets and ids.
If both the browser and the server support TLS session tickets, the server returns a ticket containing the symmetric key as part of the handshake. This ticket is encrypted with an encryption key known only to the server, which makes storing TLS session information a secure method. When the browser tries to reconnect to the server, it returns an encrypted session ticket. Everyone can bypass the rest of the TLS handshake because both parties have access to the symmetric session key.
Unfortunately, Safari and IE do not support session tickets. These browsers use a mechanism called session IDs to resume TLS sessions. Session information is stored on the server instead of the client, and the client returns the session's ID to the server. Keeping a cache of all TLS connection parameters can be a burden on the server, but if you want to support TLS session resumption more broadly, supporting both session tickets and session IDs is a good idea.
Support SPDY or HTTP/2
SPDY and HTTP/2 are internet protocols that can greatly improve website loading speed. Technically, SSL does not require any of these protocols, but the major browser vendors support SPDY or http/2.
HTTP/1.1 enforces a TCP connection for every request, and browsers can only open a limited number of TCP connections at a time. As a result, the website's HTML, CSS, JavaScript, media assets, etc. are all downloaded continuously. HTTP/2 and SPDY added several new features called multiplexing that allow browsers to use a single TCP connection for the entire website. Unlike HTTP/1.1, multiplexing allows the browser to download all the assets of a website in parallel. So, it is much faster than HTTP/1.1.
Most Internet communications support SPDY or HTTP/2. If your web server doesn't support this widely supported SPDY and HTTP/2 browser, you won't be able to take full advantage of the full value of a TLS-enabled web server. This is a good example of how modern SSL really makes web servers faster, albeit at some cost to the handshake initially.
Conclusion: All About HTTPS
After taking into account the security and performance benefits of modern SSL, there is no longer a reason for a corporate website not to utilize HTTPS for every request. This simplifies the work of web developers and system administrators because they no longer need to write complex URL redirects to use HTTP for some pages and HTTPS for others.
Choosing TLS also builds trust between businesses and corporate websites. HTTPS ensures that visitors to a website see what they should see on a business website. By providing content through HTTPS, companies can avoid the situation that ISPs insert advertisements into corporate web pages when using ordinary HTTP.
Four useful SSL best practices when it comes to securing corporate websites are:
1. Support HSTS header
2. Sign with SHA-2 certificate
3. Forward encryption using EDH handshake
4. Upgrade to TLS1.2
Also, here are the four best ways to make your SSL-enabled business website perform better:
1. Support OCSP package
2. Utilize Elliptic Curve Cryptography (ECC)
3. Support TLS session recovery
4. Support HTTP/2 and SPDY