What is SSL/TLS?
SSL (Secure Socket Layer) is a family of protocols that used to be the standard security technology for establishing an encrypted link between the web server and the browser. This secure link ensures that all data transferred remains confidential. The SSL Protocol was adopted by Netscape in 1994 as a response to the growing concern over Internet security. SSL 3.0 and earlier are vulnerable to a class of attacks that render those protocols fundamentally insecure.
Today's standard security technology for establishing secure connections is called TLS (Transport Layer Security). As part of Ubiquitous Encryption, TLS encryption should be used to secure connections to keep (personal) data safe from monitoring and tampering while in-transit.
Unfortunately people still refer to SSL when talking about "SSL-certificates" or "SSL-Termination". They, in fact, refer to just "a certificate" used for secure transmission/communication or a resource facilitating the handling of encrypted transmission.
SSL should be explicitely disabled or TLS 1.2 or newer explicity configured.
Why Use TLS
Every HTTP-based-resource on the Internet should be served over HTTPS because of:
- Performance: Modern TLS techniques can actually improve page load times
- No Search Rank Penalty: Search engines favour secure HTTPS websites. (source)
- Security: Encrypting traffic with TLS ensures less chance on confidentiality breach for data in transit
- Trust: By adding a metric and not displaying an insecure of unknown security notice leverages trust
- Regulatory Compliance: Modern TLS is a key component in PCI compliance.
Reminder: On the 30th of June 2018, PCI-DSS requires you to disable SSL and TLS1.0. One is highly urged to only use TLS 1.2 or newer and also to disable TLS1.1. (source) As of February 2018, Modern TLS, as in TLS 1.2 or newer (TLS 1.3) was supposed to be required by PCI-DSS v3.2 during assessment.
Performance
HTTPS can be faster, more secure, and due to quick adaptation by large providers and leveraged as key-indicator by search-engines, used by more websites than ever before. TLS enables HTTP/2 (h2 not h2c), which has the potential to make websites up to two times faster out-of-the-box without any changes to existing code. HTTP/2 also allows for server-push enabling you to send additional content in response to requests in anticipation.
Modern TLS also includes performance-oriented features like session resumption, OCSP stapling, and elliptic curve cryptography (ECC) which uses smaller keys (resulting in a faster handshake). TLS 1.3 can reduce latency even further and removes (more) insecure features (and cypher-suites) of TLS making HTTPS more secure and performant than any previous version of TLS.
For mobile devices and CPUs without AES support I recommend using the ChaCha20-Poly1305 cypher. It is up to three times faster than AES-128-GCM on mobile devices and less battery-draining compared to others.
Elliptic Curve Cryptography favours speed over security. It is not necessarily safer compared to RSA-based cryptography however relatively equal security can be achieved using documented and not-disproven safe-curves. "safe"-curves can be found at safecurves.cr.yp.to. ECC's main advantage is that you can use smaller keys for a similar level of security, especially at high levels of security. This due to algorithms for factoring like Number Field Sieve. Some even consider that standards like ECDSA are not state-of-the-art.
Different Implementations
Platforms and providers offer different services which operate in different modes depending on the level of security required and the amount of configuration you are willing to do. Traffic to the end user or resource must always be encrypted, however, traffic between the service and your origin server can be configured in a variety of ways.
"SSL"-Termination
TLS-Termination/SSL-Termination or sometimes called Flexible SSL, encrypts traffic from the load-balancer or service to end users of your website or consumers of your API, but not from the load-balancer to your origin server. This is by far the easiest way to enable HTTPS because it doesn't require you to install certificates on your origin. A common implementation is a reverse-proxy with TLS configured. While this is not as secure as the latterly named options, it does protect your consumers from a large class of threats including clear-text snooping.
This does not protect (personal) data from internal breaches and potential man-in-the-middle-attacks. Even worse: You cannot verify your path at all.
Unauthenticated TLS
Unauthenticated TLS or sometimes called Full SSL mode provides encryption from end users/your consumers to load-balancer or service and from the load-balancer or service to your origin server. This is considered defacto standard. This requires a (valid) certificate on your origin server. The usage of valid and verified certificates in conjunction with HSTS ensures for safe (unauthenticated) connections between producer and consumer.
Authenticated TLS
Authenticated TLS or Mutual TLS provides encryption from end users/your consumers to load-balancer or service and from the load-balancer or service to your origin server. Compared to Unauthenticated TLS, one verifies the identity of all participants in the chain. When used in conjunction with HSTS and an origin or client-side certificate, you can establish a secure path between your origin and your consumer and propagate its identity down the chain.
You can "mix" Unauthenticated and Authenticated TLS. You would simply use Authenticated TLS, but keep client verification as in end-user as optional. When using Authenticated TLS, do not add insecure versions (as in unauthenticated/no verifiable origins) to the chain.
End-to-End Encryption
End-to-End Encryption (E2EE) is a concept where communication is encrypted directly between the users of a system, whereas many systems just provide encryption between each individual user and the service provider. That is, with E2EE only the sender and receiver of a message can access the message content as they control the encryption keys. Neither the service provider nor any party involved in delivering the message is able to decode it to clear text at any time.