In this section, we will explain the security-related aspects of using CloudFront, as many cloud-based applications use it. In CloudFront, the efficient delivery of dynamic content (not cacheable) is achieved by proxying data to the origin and back over a highly-optimized network. When an end-user makes a request for content, the user is automatically routed to the nearest edge location. A high-quality, consistent connection is maintained between the edge location back to the origin, and the connection is kept alive over the AWS backbone. So, even when you are not caching data, the data going out from your application or coming in from the user can be performant and secure. 

CloudFront protects data in transit by delivering content over HTTPS. HTTPS authenticates the viewers to CloudFront and also the origin to CloudFront. The process starts by terminating SSL at the edge location. The communication between the edge location and the user is secured using a SSL certificate. Aiming towards a goal of ensuring secure content delivery, more and more developers are shifting to a complete HTTPS model that covers 100% of your site's contents delivered end to end over HTTPS. CloudFront enables advanced SSL features automatically.

Some of the key security-related CloudFront features include:

• High security ciphers: CloudFront uses strong ciphers and cipher suites that are optimized for performance and security. 
• Perfect forward secrecy: Enables perfect forward secrecy so that even if your certificate is compromised and someone gains access to your private key, they will still not be able to decrypt data collected in the past.
• Online Certificate Status Protocol (OCSP stapling): When the client sends a TLS client connection or "hello" request, CloudFront requests the certificate status from an OCSP responder. The OCSP responder sends the certificate status and CloudFront completes a TLS handshake with the client.
• TCP fast open: A TCP cookie returned to the client upon establishing the TCP session. The client sends the cookie the next time it connects to the server, along with the client "hello" request. CloudFront supports this for TLS connections only.
• Validate origin certificate: CloudFront validates SSL certificates to the origin, for example, the origin domain name must match the subject name on the certificate; the certificate must be issued by a trusted CA, and the certificate date must be within the expiration window.
• Session tickets: We have to do two round trips for the client to establish a TLS connection after the TCP connection (so it is a total of three round trips). Round trips are expensive and add a fair bit of latency. Session tickets allow clients to resume a session. CloudFront sends encrypted session data to the client and the client does an abbreviated SSL handshake.

You can create a site that can deliver both HTTP and HTTPS content; that is, you can use a single CloudFront domain name for both HTTP and HTTPS content. You can choose between enforcing Strict HTTPS, where HTTP requests are failed, or implement an HTTP to HTTPS redirect.

Additionally, CloudFront offers three options for TLS: 

• Default CloudFront SSL domain name: This option means using a non-human friendly domain name where the CloudFront certificate is shared across customers. 
• SNI-enabled custom SSL: Allows you to use your own SSL certificate and relies on the SNI extension of the TLS protocol (for the right certificate to be selected for a specific customer). You can have your own domain name and certificate. However, some older browsers/OSs do not support the SNI extension.
• Dedicated IP custom SSL: In this option, you can use your own SSL certificate. CloudFront allocates dedicated IP addresses to serve SSL content. It is supported by all browsers/OSs, however, there is an extra charge for using this option.