In our chapters, you can find interesting and important information about SSL and TLS certificates. You will understand what is a differences between certificates and train to setup and configure your security certificates on your servers.
Many thanks for public sources and Ilya Grigorik from Google (High Performance Browser Networking)
We wish to create a really helpful and interesting section, so we invite you to be our co-authors.
Please, send us your articles toand we will publish most interesting of them under your copyright.
Signing Request. A file ending in ".csr" which is presented to a 3rd party and which is used by that 3rd party to generate the "public key".Private Key: A file ending in ".key" which is installed on the server and which is kept secret and secure.
Public Key: A file ending in ".crt" which is installed on the server, but which is given freely to any connecting device (client). Anyone can have a copy of this file without interfering with the security of the system.Intermediate Certificates. Additional files provided by the 3rd party that generated and signed your "public key". These are public files and need to be installed on the server so that connecting devices can properly verify your site's identity. If you forget to install this, your users connecting to your web site may get SSL warnings and be wary of trusting your site.
A "self-signed" certificate is one in which you yourself have "signed" the certificate (e.g. when you or your hosting company created it). Self-signed certificates are free and anyone can make them with any information in them regarding organization and domain name. E.g. you could make one yourself that is for the computers of the NSA (National Security Agency). However, anyone who connects to a server using a self-signed certificate will immediately get a significant warning message in their connecting program (e.g. web browser, email program, etc.) that the server it is connecting to is not trusted and that you should proceed with extreme caution.
Self-signed certificates are typically used only for:
If there is information about your organization (e.g. your company name) in the certificate, then this must also be verified. People in charge of this company must approve the certificate. So
You should purchase SSL Certificates that use the above forms of validation in order to:
Make it visually obvious to the end user that an Extended Validation SSL Certificate is in use.
The net result is that the end user can differentiate sites that use these more trusted certificates and thus
When an end user goes to a secure site that is using an EV certificate, they will see "green" in the address bar. End users then associate "green sites" with "very secure sites". Simple, clear, concise, no technical knowledge needed.
If it is very important that users feel safe and secure when visiting your site, (e.g. financial institutions, tax preparers, legal and medical firms), you should take steps to protect them from any kind of phishing attack. Extended Validation SSL Certificates offer a visible acknowledgment that you value your end users' privacy and security on your website. If you need SSL for basic security and your users do not pay much attention to the degree of trust or the possibility of phishing, or if cost is a constraint, then a standard SSL certificate, from a reputable CA, is acceptable.
That depends on if those services are located on the same server (IP Address). If your domain was "secure.com" and you wanted to use this for both secure email (e.g. POP and IMAP) and your web site, then these things would generally need to be served on the same server. So that the IP address of your web site and your email is the same and thus you can configure the address of "secure.com" with that address. If your mail and web sites were on different servers or IP addresses, then you would not be able to setup your domain "secure.com" so that it goes to one place for web and another place for email (without special hardware firewalls and other types of traffic redirecting rules that are not generally in place in common configurations). If you have your email on one server, your web sites on another server, and your WebMail on a third set of servers - this is for security and performance reasons. So, if you wanted to secure all three things with your own branded domain name and SSL, you would need up to 3 certificates (or 1 wild card certificate) - one for each server. Dedicated servers can have all of your services located on your single machine and can use 1 regular certificate for all of them.
Figure 1. Transport Layer Security (TLS) When the SSL protocol was standardized by the IETF, it was renamed to Transport Layer Security (TLS). Many use the TLS and SSL names interchangeably, but technically, they are different, since each describes a different version of the protocol. SSL 2.0 was the first publicly released version of the protocol, but it was quickly replaced by SSL 3.0 due to a number of discovered security flaws. Because the SSL protocol was proprietary to Netscape, the IETF formed an effort to standardize the protocol, resulting in RFC 2246, which was published in January 1999 and became known as TLS 1.0. Since then, the IETF has continued iterating on the protocol to address security flaws, as well as to extend its capabilities: TLS 1.1 (RFC 4346) was published in April 2006, TLS 1.2 (RFC 5246) in August 2008, and now TLS 1.3 was drafted in March 2018. That said, don't let the abundance of versions numbers mislead you: your servers should always prefer and negotiate the latest stable version of the TLS protocol to ensure the best security, capability, and performance guarantees. In fact, some performance-critical features, such as HTTP/2, explicitly require the use of TLS 1.2 or higher and will abort the connection otherwise. Good security and performance go hand in hand. TLS was designed to operate on top of a reliable transport protocol such as TCP. However, it has also been adapted to run over datagram protocols such as UDP. The Datagram Transport Layer Security (DTLS) protocol, defined in RFC 6347, is based on the TLS protocol and is able to provide similar security guarantees while preserving the datagram delivery model.
A mechanism to obfuscate what is sent from one host to another.
A mechanism to verify the validity of provided identification material.
A mechanism to detect message tampering and forgery. In order to establish a cryptographically secure data channel, the connection peers must agree on which ciphersuites will be used and the keys used to encrypt the data. The TLS protocol specifies a well-defined handshake sequence to perform this exchange, which we will examine in detail in . The ingenious part of this handshake, and the reason TLS works in practice, is due to its use of public key cryptography (also known as asymmetric key cryptography), which allows the peers to negotiate a shared secret key without having to establish any prior knowledge of each other, and to do so over an unencrypted channel. As part of the TLS handshake, the protocol also allows both peers to authenticate their identity. When used in the browser, this authentication mechanism allows the client to verify that the server is who it claims to be (e.g., your bank) and not someone simply pretending to be the destination by spoofing its name or IP address. This verification is based on the established chain of trust - see . In addition, the server can also optionally verify the identity of the client - e.g., a company proxy server can authenticate all employees, each of whom could have their own unique certificate signed by the company. Finally, with encryption and authentication in place, the TLS protocol also provides its own message framing mechanism and signs each message with a message authentication code (MAC). The MAC algorithm is a one-way cryptographic hash function (effectively a checksum), the keys to which are negotiated by both connection peers. Whenever a TLS record is sent, a MAC value is generated and appended for that message, and the receiver is then able to compute and verify the sent MAC value to ensure message integrity and authenticity. Combined, all three mechanisms serve as a foundation for secure communication on the Web. All modern web browsers provide support for a variety of ciphersuites, are able to authenticate both the client and server, and transparently perform message integrity checks for every record.
Encryption prevents intruders from tampering with exchanged data - e.g. rewriting content, injecting unwanted and malicious content, and so on.
HTTPS protects the privacy and security of the user
Encryption prevents intruders from listening in on the exchanged data. Each unprotected request can reveal sensitive information about the user, and when such data is aggregated across many sessions, can be used to de-anonymize their identities and reveal other sensitive information. All browsing activity, as far as the user is concerned, should be considered private and sensitive.
HTTPS enables powerful features on the web
A growing number of new web platform features, such as accessing users geolocation, taking pictures, recording video, enabling offline app experiences, and more, require explicit user opt-in that, in turn, requires HTTPS. The security and integrity guarantees provided by HTTPS are critical components for delivering a secure user permission workflow and protecting their preferences. To further the point, both the Internet Engineering Task Force (IETF) and the Internet Architecture Board (IAB) have issued guidance to developers and protocol designers that strongly encourages adoption of HTTPS:
The HTTPS-Only Standard published by the White House’s Office of Management and Budget is a great resource for additional information on the need for HTTPS, and hands-on advice for deploying it.
Figure 2. TLS handshake protocol Figure 2 assumes the same (optimistic) 28 millisecond one-way "light in fiber" delay between New York and London as used in previous TCP connection establishment examples.
TLS runs over a reliable transport (TCP), which means that we must first complete the TCP three-way handshake, which takes one full roundtrip.
With the TCP connection in place, the client sends a number of specifications in plain text, such as the version of the TLS protocol it is running, the list of supported ciphersuites, and other TLS options it may want to use.
The server picks the TLS protocol version for further communication, decides on a ciphersuite from the list provided by the client, attaches its certificate, and sends the response back to the client. Optionally, the server can also send a request for the client's certificate and parameters for other TLS extensions.
Assuming both sides are able to negotiate a common version and cipher, and the client is happy with the certificate provided by the server, the client initiates either the RSA or the Diffie-Hellman key exchange, which is used to establish the symmetric key for the ensuing session.
The server processes the key exchange parameters sent by the client, checks message integrity by verifying the MAC, and returns an encrypted Finished message back to the client.
The client decrypts the message with the negotiated symmetric key, verifies the MAC, and if all is well, then the tunnel is established and application data can now be sent.
As the above exchange illustrates, new TLS connections require two roundtrips for a "full handshake" - that's the bad news. However, in practice, optimized deployments can do much better and deliver a consistent 1-RTT TLS handshake:
$> openssl speed ecdh
$> openssl speed aes
Note that the units between the two tests are not directly comparable: the Elliptic Curve Diffie-Hellman (ECDH) test provides a summary table of operations per second for different key sizes, while AES performance is measured in bytes per second. Nonetheless, it should be easy to see that the ECDH operations are much more computationally expensive. The exact performance numbers vary significantly based on used hardware, number of cores, TLS version, server configuration, and other factors. Don’t fall for an outdated benchmark! Always run the performance tests on your own hardware and refer to Reduce Computational Costs for additional context.
Next Protocol Negotiation (NPN) is a TLS extension, which was developed as part of the SPDY effort at Google to enable efficient application protocol negotiation during the TLS handshake. Sound familiar? The end result is functionally equivalent to ALPN. ALPN is a revised and IETF approved version of the NPN extension. In NPN, the server advertised which protocols it supports, and the client then chose and confirmed the protocol. In ALPN, this exchange was reversed: the client now specifies which protocols it supports, and the server then selects and confirms the protocol. The rationale for the change is that this brings ALPN into closer alignment with other protocol negotiation standards. In short, ALPN is a successor to NPN. Server Name Indication (SNI)
An encrypted TLS tunnel can be established between any two TCP peers: the client only needs to know the IP address of the other peer to make the connection and perform the TLS handshake. However, what if the server wants to host multiple independent sites, each with its own TLS certificate, on the same IP address — how does that work? Trick question; it doesn't. To address the preceding problem, the Server Name Indication (SNI) extension was introduced to the TLS protocol, which allows the client to indicate the hostname the client is attempting to connect to as part of the TLS handshake. In turn, the server is able to inspect the SNI hostname sent in the ClientHello message, select the appropriate certificate, and complete the TLS handshake for the desired host. TLS, HTTP, and Dedicated IPs
The TLS+SNI workflow is identical to Host header advertisement in HTTP, where the client indicates the hostname of the site it is requesting: the same IP address may host many different domains, and both SNI and Host are required to disambiguate between them. Unfortunately, some older clients (e.g., most IE versions running on Windows XP, Android 2.2, and others) do not support SNI. As a result, if you need to provide TLS to such clients, then you may need a dedicated IP address for each and every host.
The first Session Identifiers (RFC 5246) resumption mechanism was introduced in SSL 2.0, which allowed the server to create and send a 32-byte session identifier as part of its ServerHello message during the full TLS negotiation we saw earlier. With the session ID in place, both the client and server can store the previously negotiated session parameters - keyed by session ID and reuse them for a subsequent session. Specifically, the client can include the session ID in the ClientHello message to indicate to the server that it still remembers the negotiated cipher suite and keys from previous handshake and is able to reuse them. In turn, if the server is able to find the session parameters associated with the advertised ID in its cache, then an abbreviated handshake (Figure 3) can take place. Otherwise, a full new session negotiation is required, which will generate a new session ID. Figure 3. Abbreviated TLS handshake protocol
Leveraging session identifiers allows us to remove a full round trip, as well as the overhead of public key cryptography, which is used to negotiate the shared secret key. This allows a secure connection to be established quickly and with no loss of security, since we are reusing the previously negotiated session data. Session resumption is an important optimization both for HTTP/1.x and HTTP/2 deployments. The abbreviated handshake eliminates a full roundtrip of latency and significantly reduces computational costs for both sides. In fact, if the browser requires multiple connections to the same host (e.g. when HTTP/1.x is in use), it will often intentionally wait for the first TLS negotiation to complete before opening additional connections to the same server, such that they can be "resumed" and reuse the same session parameters. If you've ever looked at a network trace and wondered why you rarely see multiple same-host TLS negotiations in flight, that's why! However, one of the practical limitations of the Session Identifiers mechanism is the requirement for the server to create and maintain a session cache for every client. This results in several problems on the server, which may see tens of thousands or even millions of unique connections every day: consumed memory for every open TLS connection, a requirement for a session ID cache and eviction policies, and nontrivial deployment challenges for popular sites with many servers, which should, ideally, use a shared TLS session cache for best performance. None of the preceding problems are impossible to solve, and many high-traffic sites are using session identifiers successfully today. But for any multi-server deployment, session identifiers will require some careful thinking and systems architecture to ensure a well operating session cache. Session Tickets
To address this concern for server-side deployment of TLS session caches, the "Session Ticket" (RFC 5077) replacement mechanism was introduced, which removes the requirement for the server to keep per-client session state. Instead, if the client indicates that it supports session tickets, the server can include a New Session Ticket record, which includes all of the negotiated session data encrypted with a secret key known only by the server. This session ticket is then stored by the client and can be included in the SessionTicketextension within the ClientHello message of a subsequent session. Thus, all session data is stored only on the client, but the ticket is still safe because it is encrypted with a key known only by the server. The session identifiers and session ticket mechanisms are respectively commonly referred to as session caching and stateless resumption mechanisms. The main improvement of stateless resumption is the removal of the server-side session cache, which simplifies deployment by requiring that the client provide the session ticket on every new connection to the server—that is, until the ticket has expired. In practice, deploying session tickets across a set of load-balanced servers also requires some careful thinking and systems architecture: all servers must be initialized with the same session key, and an additional mechanism is required to periodically and securely rotate the shared key across all servers.
What we have just done is established a chain of trust: Alice trusts Bob, Bob trusts Charlie, and by transitive trust, Alice decides to trust Charlie. As long as nobody in the chain is compromised, this allows us to build and grow the list of trusted parties. Authentication on the Web and in your browser follows the exact same process as shown. Which means that at this point you should be asking: whom does your browser trust, and whom do you trust when you use the browser? There are at least three answers to this question:
Manually specified certificates Every browser and operating system provides a mechanism for you to manually import any certificate you trust. How you obtain the certificate and verify its integrity is completely up to you. Certificate authorities A certificate authority (CA) is a trusted third party that is trusted by both the subject (owner) of the certificate and the party relying upon the certificate. The browser and the operating system Every operating system and most browsers ship with a list of well-known certificate authorities. Thus, you also trust the vendors of this software to provide and maintain a list of trusted parties. In practice, it would be impractical to store and manually verify each and every key for every website (although you can, if you are so inclined). Hence, the most common solution is to use certificate authorities (CAs) to do this job for us (Figure 5): the browser specifies which CAs to trust (root CAs), and the burden is then on the CAs to verify each site they sign, and to audit and verify that these certificates are not misused or compromised. If the security of any site with the CA's certificate is breached, then it is also the responsibility of that CA to revoke the compromised certificate. Figure 5. CA signing of digital certificates
Every browser allows you to inspect the chain of trust of your secure connection (Figure 6), usually accessible by clicking on the lock icon beside the URL. Figure 6. Certificate chain of trust for igvita.com (Google Chrome, v25)
Every operating system vendor and every browser provide a public listing of all the certificate authorities they trust by default. Use your favorite search engine to find and investigate these lists. In practice, yo'’ll find that most systems rely on hundreds of trusted certificate authorities, which is also a common complaint against the system: the large number of trusted CAs creates a large attack surface area against the chain of trust in your browser. The good news is, the Certificate Transparency project is working to address these flaws by providing a framework—a public log—for monitoring and auditing of issuance of all new certificates. Certificate Revocation
Occasionally the issuer of a certificate will need to revoke or invalidate the certificate due to a number of possible reasons: the private key of the certificate has been compromised, the certificate authority itself has been compromised, or due to a variety of more benign reasons such as a superseding certificate, change in affiliation, and so on. To address this, the certificates themselves contain instructions (Figure 7) on how to check if they have been revoked. Hence, to ensure that the chain of trust is not compromised, each peer can check the status of each certificate by following the embedded instructions, along with the signatures, as it verifies the certificate chain. Figure 7. CRL and OCSP instructions for igvita.com (Google Chrome, v25) Certificate Revocation List (CRL)
Certificate Revocation List (CRL) is defined by RFC 5280 and specifies a simple mechanism to check the status of every certificate: each certificate authority maintains and periodically publishes a list of revoked certificate serial numbers. Anyone attempting to verify a certificate is then able to download the revocation list, cache it, and check the presence of a particular serial number within it - if it is present, then it has been revoked. This process is simple and straightforward, but it has a number of limitations:
To address some of the limitations of the CRL mechanism, the Online Certificate Status Protocol (OCSP) was introduced by RFC 2560, which provides a mechanism to perform a real-time check for status of the certificate. Unlike the CRL file, which contains all the revoked serial numbers, OCSP allows the client to query the CA’s certificate database directly for just the serial number in question while validating the certificate chain. As a result, the OCSP mechanism consumes less bandwidth and is able to provide real-time validation. However, the requirement to perform real-time OCSP queries creates its own set of problems:
For the reasons listed above, neither CRL or OSCP revocation mechanisms offer the security and performance guarantees that we desire for our applications. However, don't despair, because OCSP stapling (RFC 6066, "Certificate Status Request" extension) addresses most of the issues we saw earlier by allowing the validation to be performed by the server and be sent ("stapled") as part of the TLS handshake to the client:
The best way to minimize both latency and computational overhead of setting up new TCP+TLS connections is to optimize connection reuse. Doing so amortizes the setup costs across requests and delivers a much faster experience to the user. Verify that your server and proxy configurations are setup to allow keepalive connections, and audit your connection timeout settings. Many popular servers set aggressive connection timeouts (e.g. some Apache versions default to 5s timeouts) that force a lot of unnecessary renegotiations. For best results, use your logs and analytics to determine the optimal timeout values. Leverage Early Termination
As we discussed in Primer on Latency and Bandwidth, we may not be able to make our packets travel faster, but we can make them travel a shorter distance. By placing our "edge" servers closer to the user (Figure 9), we can significantly reduce the round trip times and the total costs of the TCP and TLS handshakes. Figure 9. Early termination of client connections A simple way to accomplish this is to leverage the services of a content delivery network (CDN) that maintains pools of edge servers around the globe, or to deploy your own. By allowing the user to terminate their connection with a nearby server, instead of traversing across oceans and continental links to your origin, the client gets the benefit of "early termination" with shorter roundtrips. This technique is equally useful and important for static and dynamic content: static content can also be cached and served by the edge servers, whereas dynamic requests can be routed over established connections from the edge to origin. Uncached Origin Fetch
The technique of using a CDN or a proxy server to fetch a resource, which may need to be customized per user or contains other private data, and hence is not a globally cacheable resource at the edge, is commonly known as an "uncached origin fetch." While CDNs work best when the data is cached in geo-distributed servers around the world, the uncached origin fetch still provides a very important optimization: the client connection is terminated with the nearby server, which can dramatically reduce the handshake latency costs. In turn, the CDN, or your own proxy server, can maintain a "warm connection pool" to relay the data to the origin servers, allowing you to return a fast response back to the client. In fact, as an additional layer of optimization, some CDN providers will use nearby servers on both sides of the connection! The client connection is terminated at a nearby CDN node, which then relays the request to the CDN node close to the origin, and the request is then routed to the origin. The hop within the CDN network allows the traffic to be routed over the optimized CDN backbone, which can help to further reduce latency between client and origin servers. Configure Session Caching and Stateless Resumption
Terminating the connection closer to the user is an optimization that will help decrease latency for your users in all cases, but once again, no bit is faster than a bit not sent - send fewer bits. Enabling TLS session caching and stateless resumption allows us to eliminate an entire roundtrip of latency and reduce computational overhead for repeat visitors. Session identifiers, on which TLS session caching relies, were introduced in SSL 2.0 and have wide support among most clients and servers. However, if you are configuring TLS on your server, do not assume that session support will be on by default. In fact, it is more common to have it off on most servers by default—but you know better! Double-check and verify your server, proxy, and CDN configuration:
Session resumption provides two important benefits: it eliminates an extra handshake roundtrip for returning visitors and reduces the computational cost of the handshake by allowing reuse of previously negotiated session parameters. However, it does not help in cases where the visitor is communicating with the server for the first time, or if the previous session has expired. To get the best of both worlds - a one round trip handshake for new and repeat visitors, and computational savings for repeat visitors - we can use TLS False Start, which is an optional protocol extension that allows the sender to send application data (Figure 10) when the handshake is only partially complete. Figure 10. TLS handshake with False Start False Start does not modify the TLS handshake protocol, rather it only affects the protocol timing of when the application data can be sent. Intuitively, once the client has sent theClientKeyExchange record, it already knows the encryption key and can begin transmitting application data - the rest of the handshake is spent confirming that nobody has tampered with the handshake records, and can be done in parallel. As a result, False Start allows us to keep the TLS handshake at one round trip regardless of whether we are performing a full or abbreviated handshake. Deploying TLS False Start
Because False Start is only modifying the timing of the handshake protocol, it does not require any updates to the TLS protocol itself and can be implemented unilaterally - i.e., the client can simply begin transmitting encrypted application data sooner. Well, that's the theory. In practice, even though TLS False Start should be backwards compatible with all existing TLS clients and servers, enabling it by default for all TLS connections proved to be problematic due to some poorly implemented servers. As a result, all modern browsers are capable of using TLS False Start, but will only do so when certain conditions are met by the server:
All application data delivered via TLS is transported within a record protocol (Figure 8). The maximum size of each record is 16 KB, and depending on the chosen cipher, each record will add anywhere from 20 to 40 bytes of overhead for the header, MAC, and optional padding. If the record then fits into a single TCP packet, then we also have to add the IP and TCP overhead: 20-byte header for IP, and 20-byte header for TCP with no options. As a result, there is potential for 60 to 100 bytes of overhead for each record. For a typical maximum transmission unit (MTU) size of 1,500 bytes on the wire, this packet structure translates to a minimum of 6% of framing overhead. The smaller the record, the higher the framing overhead. However, simply increasing the size of the record to its maximum size (16 KB) is not necessarily a good idea. If the record spans multiple TCP packets, then the TLS layer must wait for all the TCP packets to arrive before it can decrypt the data (Figure 11). If any of those TCP packets get lost, reordered, or throttled due to congestion control, then the individual fragments of the TLS record will have to be buffered before they can be decoded, resulting in additional latency. In practice, these delays can create significant bottlenecks for the browser, which prefers to consume data in a streaming fashion. Figure 11. WireShark capture of 11,211-byte TLS record split over 8 TCP segments
Small records incur overhead, large records incur latency, and there is no one value for the "optimal" record size. Instead, for web applications, which are consumed by the browser, the best strategy is to dynamically adjust the record size based on the state of the TCP connection:
Verifying the chain of trust requires that the browser traverse the chain, starting from the site certificate, and recursively verify the certificate of the parent until it reaches a trusted root. Hence, it is critical that the provided chain includes all the intermediate certificates. If any are omitted, the browser will be forced to pause the verification process and fetch the missing certificates, adding additional DNS lookups, TCP handshakes, and HTTP requests into the process. How does the browser know from where to fetch the missing certificates? Each child certificate typically contains a URL for the parent. If the URL is omitted and the required certificate is not included, then the verification will fail. Conversely, do not include unnecessary certificates, such as the trusted roots in your certificate chain - they add unnecessary bytes. Recall that the server certificate chain is sent as part of the TLS handshake, which is likely happening over a new TCP connection that is in the early stages of its slow-start algorithm. If the certificate chain size exceeds TCP's initial congestion window, then we will inadvertently add additional roundtrips to the TLS handshake: certificate length will overflow the congestion window and cause the server to stop and wait for a client ACK before proceeding. In practice, the size and depth of the certificate chain was a much bigger concern and problem on older TCP stacks that initialized their initial congestion window to 4 TCP segments—see Slow-Start. For newer deployments, the initial congestion window has been raised to 10 TCP segments and should be more than sufficient for most certificate chains. That said, verify that your servers are using the latest TCP stack and settings, and optimize and reduce the size of your certificate chain. Sending fewer bytes is always a good and worthwhile optimization. Configure OCSP Stapling
Every new TLS connection requires that the browser must verify the signatures of the sent certificate chain. However, there is one more critical step that we can’t forget: the browser also needs to verify that the certificates have not been revoked. To verify the status of the certificate the browser can use one of several methods: Certificate Revocation List (CRL), Online Certificate Status Protocol (OCSP), or OCSP Stapling. Each method has its own limitations, but OCSP Stapling provides, by far, the best security and performance guarantees-refer to earlier sections for details. Make sure to configure your servers to include (staple) the OCSP response from the CA to the provided certificate chain. Doing so allows the browser to perform the revocation check without any extra network roundtrips and with improved security guarantees.
HTTP Strict Transport Security is an important security policy mechanism that allows an origin to declare access rules to a compliant browser via a simple HTTP header - e.g., "Strict-Transport-Security: max-age=31536000". Specifically, it instructs the user-agent to enforce the following rules:
The HSTS mechanism leaves the very first request to an origin unprotected from active attacks - e.g. a malicious party could downgrade the client's request and prevent it from registering the HSTS policy. To address this, most browsers provide a separate "HSTS preload list" mechanism that allows an origin to request to be included in the list of HSTS-enabled sites that ships with the browser. Enable HTTP Public Key Pinning (HPKP)
One of the shortcomings of the current system - as discussed in Chain of Trust and Certificate Authorities - is our reliance on a large number of trusted Certificate Authorities (CA's). On the one hand, this is convenient, because it means that we can obtain a valid certificate from a wide pool of entities. However, it also means that any one of these entities is also able to issue a valid certificate for our, and any other, origin without their explicit consent. The compromise of the DigiNotar certificate authority is one of several high-profile examples where an attacker was able to issue and use fake-but valid-certificates against hundreds of high profile sites. Public Key Pinning enables a site to send an HTTP header that instructs the browsers to remember ("pin") one or more certificates in its certificate chain. By doing so, it is able to scope which certificates, or issuers, should be accepted by the browser on subsequent visits:
To get the best security and performance guarantees it is critical that the site actually uses HTTPS to fetch all of its resources. Otherwise, we run into a number of issues that will compromise both, or worse, break the site:
Content-Security-Policy-Report-Only: default-src https:;
report-uri https://example.com/reporting/endpoint 1. Tells the browser to upgrade all (own and third-party) requests to HTTPS.
2. Tells the browser to report any non-HTTPS violations to designated endpoint.
CSP provides a highly configurable mechanism to control which asset are allowed to be used, and how and from where they can be fetched. Make use of these capabilities to protect your site and your users. Performance Checklist
As application developers we are shielded from most of the complexity of the TLS protocol - the client and server do most of the hard work on our behalf. However, as we saw in this chapter, this does not mean that we can ignore the performance aspects of delivering our applications over TLS. Tuning our servers to enable critical TLS optimizations and configuring our applications to enable the client to take advantage of such features pays high dividends: faster handshakes, reduced latency, better security guarantees, and more.
With that in mind, a short checklist to put on the agenda:
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=2 /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing
/CN=StartCom Certification Authority
depth=1 /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing
/CN=StartCom Class 1 Primary Intermediate Server CA
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read finished A
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing
/CN=StartCom Class 1 Primary Intermediate Server CA
1 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing
/CN=StartCom Class 1 Primary Intermediate Server CA
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing
/CN=StartCom Certification Authority
... snip ...
--- No client certificate CA names sent
SSL handshake has read 3571 bytes and written 444 bytes
New, TLSv1/SSLv3, Cipher is RC4-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Protocol : TLSv1
Cipher : RC4-SHA
Session-ID: 269349C84A4702EFA7 ...
Master-Key: 1F5F5F33D50BE6228A ...
Key-Arg : None
Start Time: 1354037095
Timeout : 300 (sec)
Verify return code: 0 (ok)
--- 1. Client completed verification of received certificate chain.
2. Received certificate chain (two certificates).
3. Size of received certificate chain.
4. Issued session identifier for stateful TLS resume.
SSL: Secure Sockets Layer
While SSL and TLS are not the only protocols of their kind, they are the two most common protocols for communications of sensitive data such as passwords, personal information, financial information, etc. Protect your company's systems from cyberattack, secure your communication, and stay HIPAA compliant using the right security protocol. Protocol Overview
SSL v3.0 laid the foundation for TLS v1.0
Both use similar ciphers and message digests (though there are newer and better ciphers that are only available with newer versions of TLS such as TLS v1.0 and or v1.2). Differences in how the secure communications are established are also evident and make TLS v1.0 (and higher) clearly stronger than SSL v3.0. Which protocol is used TLS v1.x or SSL v3.0 is determined by a negotiation between the client and server, based on what software is installed on each and how each is configured. SSL V3.0
Was exploited by the POODLE attack and is now obsolete TLS V1.2
The newest, most widely-used TLS protocol
Enables better use of more secure ciphers
Features enhanced negotiation of the encrypted connections Server Connection: How It Works
By Port (explicit) -"SSL"
Client connects to a secure port like:
Client reaches out to an insecure server with a "handshake" and begins secure communication once the connection is successful ("client hello" and "server hello" messages are exchanged)
If the handshake proves to be unsuccessful, the connection is severed
This handshake is often called "STARTTLS"
If the client and server support multiple protocols, they must negotiate to agree upon which one they will use (note: websites that use SSL v3.0 have outdated security and should be updated ASAP). Configuration: Which Protocol to Use
Use the latest version of TLS and configure it properly
Extremely strong security (made even more secure with a high-quality security certificate)
Stay away from SSL v3.0 as it does not provide the proper level of security
Use only strong ciphers (especially if the server requires compliance) Program Configuration
In terms of explicit vs. implicit connections, both SSL and TLS are fine options for program configuration (as long as they are supported by the server)
However, TLS should be used for the actual protocol
If no SSL to TLS protocol is selected, your connection to the server becomes easily accessible to prying eyes. HIPAA Compliance -Requirements
SSL: SSL v3.0 must not be used (must be disabled along with SSL v2.0)
TLS: TLS v1.0 is allowed (newer versions are better) Which is more secure -SSL or TLS or TLS v1.x?
It used to be believed that TLS v1.0 was only marginally more secure than SSL v3.0, its predecessor. However, SSL v3.0 is very old and attacks such as the POODLE vulnerability have shown that SSL v3.0 is now completely insecure (especially for web sites using it). Even before the POODLE was set loose, the US Government had already mandated that SSL v3 not be used for sensitive government communications or for HIPAA-compliant communications. If that was not enough, POODLE certainly was. In fact, as a result of POODLE, SSL v3 was disabled on web sites all over the world and for many other services as well. SSL v3.0 is effectively "dead" as a useful security protocol. Places that still allow its use for web hosting are placing their "secure web sites" at extreme risk. Organizations that allow SSL v3 use to persist for other protocols (e.g., IMAP) should take steps to remove that support at the soonest software update maintenance window. Subsequent versions of TLS -v1.1, v1.2, and v1.3 are significantly more secure and fix many vulnerabilities present in SSL v3.0 and TLS v1.0. For example, the BEAST attack that can completely break web sites running the older SSL v3.0 and TLS v1.0 protocols. The newer TLS versions, if properly configured, prevent the BEAST, other attack vectors, and provide many stronger ciphers and encryption methods. As of the time of this writing (May, 2018), 11% of web sites still support SSL v3.0. However, a great majority 92% already support TLS v1.2+. Check the latest statics over at SSLLabs. The trend is, of course, to deprecate the older protocols in favor of the new ones. For example, use of TLS 1.0 by web sites that accept credit cards (and services used by the US government) must stop by June 30th, 2018. Instead, they must use TLS 1.1 with TLS 1.2+ strongly encouraged). As early as 2014, NIST (National Institute of Standards and Technology) revised its guidelines and recommends only use of TLS 1.1+ for government communications. NIST does indicate that TLS v1.0 is OK for non-government communications even in its latest 2018 draft updates. Everyone should use TLS 1.2 and 1.3 when possible. However, so many organizations still have older computers (more than 5 years old) that completely turning off TLS 1.0 and 1.1 support could cause a large disruption. As a result, we are seeing the transition to TLS 1.2 as being more gradual where sites and systems that need it (for PCI and government work) leading the way, followed by those whose users are likely to have more recent computed systems. Likely, in the next several years, TLS 1.0 support across the internet will steadily decline. However, as we see with SSL 3.0, it will not go away in general for some time to come. But wait: are not TLS and SSL different encryption mechanisms?
If you setup an email program you may see separate options for "no encryption", "SSL", or "TLS" encryption of you transmission. This leads one to assume that TLS and SSL are very different things. In truth, this labeling is a misnomer. You are not actually selecting which method to use (SSL v3 or TLS v1.x) when making this choice. You are merely selecting between options that dictate how the secure connection will be initiated. No matter which "method" you choose for initiating the connection, TLS or SSL, the same level of encryption will be obtained when talking to the server and that level is determined by the software installed on the server, how that is configured, and what your program actually supports. If the SSL vs TLS choice is not SSLv3 vs TLS v1.0+, what is it?
There are two distinct ways that a program can initiate a secure connection with a server: By Port (a.k.a. explicit): Connecting to a specific port means that a secure connection should be used. For example, port 443 for https (secure web), 993 for secure IMAP, 995 for secure POP, etc. These ports are setup on the server ready to negotiate a secure connection first, and do whatever else you want second. By Protocol (a.k.a. implicit): These connections first begin with an insecure "hello" to the server and only then switch to secured communications after the handshake between the client and the server is successful. If this handshake fails for any reason, the connection is severed. A good example of this is the command "STARTTLS" used in outbound email (SMTP) connections. The "By Port" method is commonly referred to as "SSL" or "explicit" and the "By Protocol" method is commonly referred to as "TLS" or «implicit» in many program configuration areas.
Sometimes, you have only the option to specify the port and if you should be making a secure connection or not and the program itself guesses from that what method should be used many old email programs like Outlook and Mac Mail did that. In such cases, you need to know if the program will try and explicit or implicit connection to initiate security, and choose your port appropriately (or else the connection could fail). To Review: In email programs and other systems where you can select between SSL or TLS and choose the port a connection will be made on: 1. SSL means a "by port" explicit connection to a port that expects to the session to start with security negotiation
2. TLS means a "by protocol" connection where the program will connect «insecurely» first and use special commands to enable encryption (implicit).
3. Use of either could result in a connection encrypted with either SSL v3 or TLS v1.0+, based on what is installed on the sever and what is supported by your program.
4. Both methods of connection (implicit and explicit) result in equally secure (or insecure) communications. Sidebar: It is unclear why the "By Protocol" method is referred to as «TLS» as it could result in either TLS or SSL actually being used. It is likely because the folks who designed the SMTP protocol decided to name their command to switch to SSL/TLS in the SMTP protocol to "STARTTLS" (using "TLS" in the name as that is the newer protocol name). Then email programs started listing "TLS" next to this and "SSL" next to the old "By Port" option which came first. Once they started labeling things this way, that expanded to general use in the configuration of other protocols (like POP and IMAP) for "consistency". I am not certain if this is the real reason, but based on my experience dealing with all versions of email programs and servers over the last 15 years, it seems very plausible. Both methods ensure that your data is encrypted as it is transmitted across the Internet. They also both enable you to be sure that the server that you are communication with is the server you intend to contact and not some "middle man eavesdropper". This is possible because servers that support SSL and TLS must have certificates issued to them by a trusted third party, like Comodo. These certificates verify that the domain name they are issued for really belongs to the server. Your computer will issue warnings to you if you try to connect to a server and the certificate that it gets back is not trusted or doesn't match the site you are trying to connect to. What about TLS v1.3?
TLS v1.3 is the latest and greatest version of TLS. It became an Internet standard on March 25th, 2018. According to NIST, organizations should make plans to support TLS v1.3 by January 1st, 2020 or sooner.
TLS v1.3 brings many significant changes over TLS v1.2. Some of these include: