Viewer HTTPS configuration

In CloudFront, the HTTPS setting is configurable for two different connections:

• Viewer to CloudFront

• CloudFront to your origin servers

In the context of HTTPS from viewer to CloudFront, CloudFront is a server which receives the TLS-initiating “Client Hello” in the TLS handshake process. Because the HTTPS is initiated by the client, CloudFront has options to:

• Accept both HTTP and HTTPS,

• Redirect HTTP requests to HTTPS requests, or

• Only accept HTTPS. If a viewer sends an HTTP request instead of an HTTPS request, CloudFront returns HTTP status code 403 (Forbidden) and does not return the object.

These options can be applied to a specific URI path so you can configure some part of your website to accept HTTP. However, we recommend using HTTPS for all traffic to avoid possible vulnerabilities or bad user experiences such as mixed content warnings.

When you serve your applications using your own domain name (other than the default *.cloudfront.net), you will need to set up a TLS certificate for your CloudFront distribution. In this case, you will leverage AWS Certificate Manager (ACM), to request the issuance of a new certificate, or import your existing certificate, at no additional cost. ACM supports certificate automatic renewals for Amazon-issued certificates.

Another important configuration is choosing the TLS security policy. CloudFront provides a number of security policies, each of which defines available TLS versions and cipher suites for viewer HTTPS. The oldest security policy still includes SSLv3 to support legacy clients, but we recommend that you use the latest security policy. This way the viewer HTTPS connection will not use outdated ciphers, and it will get the benefit of the latest cipher; for example, perfect forward secrecy (PFS).

By default, CloudFront will use SNI to identify the correct TLS certificate for an incoming request. SNI is a TLS extension, which enables the client to put the server name in the initial TLS handshake Client Hello step. Because CloudFront serves multiple domains, this extension helps CloudFront to choose the correct TLS certificate to provide to the client. CloudFront offers the ability to turn off Server Name Indication (SNI) to support legacy clients, which will incur extra cost. SNI is supported by most modern browsers and according to caniuse.com, more than 99% of clients use SNI-enabled agents.

CloudFront also supports Online Certificate Status Protocol (OCSP) stapling without further configuration, which enhances the performance of HTTPS delivery by providing a certificate validation response together with TLS certification during the TLS handshake.

For Viewer-side HTTPS, TLS 1.3 is automatically supported when the client initiates a TLS 1.3 handshake. TLS 1.3 eliminates weak cipher suites, provides perfect forward secrecy, and support 1-RTT TLS handshakes. Perfect forward secrecy means each session will not be compromised, even if the private key used in session key exchange is compromised in the future. Because previous sessions are protected, attackers have limited access to private data. TLS 1.3 mandates this by using only ephemeral key exchange algorithms such as Elliptic Curve Diffie-Hellman (ECDHE).

TLS 1.3 reduces the TLS handshake from two roundtrips to one. For connections using HTTP/1 or HTTP/2, shortening the TLS handshake to one roundtrip effectively reduces connection setup time by 33%.

Figure 1 — 2-RTT TLS handshake (TLS 1.2) and 1-RTT TLS handshake (TLS 1.3)