Unorthodox Design: Using Nginx as a Reverse Proxy for CloudFront

In this blog post, we will explore a unique and effective design pattern that involves using Nginx as a reverse proxy in front of an Amazon CloudFront CDN (Content Delivery Network). This unconventional setup allows for enhanced control and customization over content delivery while leveraging the global reach and scalability of CloudFront.

It is Unorthodox …

The term “Unorthodox” is used in this context to highlight that the design choice of using Nginx as a reverse proxy for CloudFront is not the most common or traditional approach. In typical setups, CloudFront is often used directly without an intermediate reverse proxy like Nginx

Introduction

Content delivery is a critical aspect of web applications, and leveraging a Content Delivery Network (CDN) can significantly enhance performance and user experience. In this blog post, we’ll dive into a design choice that involves placing Nginx, a powerful and flexible web server, as a reverse proxy in front of a CloudFront distribution.

In addition, we will briefly discuss about the self-sign certificates configuration on Nginx for the “demoserver.com”

Design

In this unconventional design, Nginx takes center stage as a robust reverse proxy, orchestrating the flow of incoming requests. The use of self-signed SSL certificates adds a layer of security, while the Nginx configuration file (nginx.conf) becomes a canvas for customization, housing directives for SSL settings, proxy configurations, and even bespoke scripts for dynamic URL modifications. This orchestration allows for fine-grained control over the content delivery process. Nginx acts as a gatekeeper, forwarding requests to the CloudFront CDN distribution, and enabling users to implement specific behaviors, redirects, or adjustments to incoming URLs before they reach the global edge locations. This unorthodox yet powerful setup not only enhances security but also empowers users with a high degree of flexibility in tailoring the content delivery network to unique application requirements.

The Nginx Proxy Requirement!

As our intention is to redirect requests from https://demoserver.com/hel/demofile.zip?Expires=AAsLFEn80....&Key-Pair-Id=TY8J74ABCD1EF to https://a1b54cd98ef9gh.cloudfront.net/demofile.zip?Expires=AAsLFEn80....&Key-Pair-Id=TY8J74ABCD1EF (Sample CFN URL) using Nginx as a proxy before CFN

You can customize "/hel" or "/heav"or "/anything" based on your need for re-writing of the url or for any customizations!!!

Let us look at the components we are going to use in this demonstration,

Nginx.conf, docker-compose.yaml and an existing CloudFront URL (this is not discussed in this blog, out of scope for us, cheers …)

Nginx Configuration

Brief explanation of SSL Params!!

• ssl_session_timeout 5m;: This parameter sets the maximum time a client SSL session may be reused. In this case, it's set to 5 minutes (5m), meaning that if a client reconnects within this time frame, the SSL session can be reused, improving performance by avoiding unnecessary handshakes.
• ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;: Specifies the SSL/TLS protocols that the server will accept. This configuration allows for a range of protocols to ensure compatibility with a variety of clients while prioritizing the use of modern and secure TLS versions.
• ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';: Defines the allowed ciphers for the SSL connection. The specified ciphers prioritize those that offer strong encryption and are considered secure.
• ssl_prefer_server_ciphers on;: This directive instructs the server to prefer the order of ciphers specified on the server side over the client's order. It ensures that the server's preferred ciphers are used whenever possible.
• ssl_dhparam /etc/nginx/certs/dhparam.pem;: Specifies the location of the Diffie-Hellman parameter file. Diffie-Hellman is used to provide Perfect Forward Secrecy (PFS), enhancing the security of the SSL/TLS connection.
• ssl_trusted_certificate /etc/nginx/certs/fullchain.crt;: Specifies a file containing trusted certificates when acting as a client. In this case, it helps establish trust with the CloudFront distribution when making requests.

These SSL parameters collectively contribute to a secure and performant SSL/TLS configuration for the Nginx reverse proxy.

Certificate Generation with OpenSSL

Before deploying the Nginx reverse proxy, we need to generate self-signed certificates for secure communication. OpenSSL can help us accomplish this. Follow these steps to generate the required certificates:

Generate a Private Key:

The first step is to generate a private key using the openssl genpkey command. In this case, we use the RSA algorithm and secure it with AES-256 encryption. The private key is a crucial component of the SSL/TLS process, providing a secure means of encrypting and decrypting data.

openssl genpkey -algorithm RSA -out selfsigned.key -aes256

Generate a Certificate Signing Request (CSR):

Next, we create a Certificate Signing Request (CSR) using the private key generated in the previous step. The CSR includes information about the entity requesting the certificate, such as its country, state, organization, and more.

openssl req -new -key selfsigned.key -out selfsigned.csr

During this step, you will be prompted to provide details for the certificate. Ensure that the Common Name (CN) matches the domain or hostname for which the certificate is intended.

Generate a Self-Signed Certificate:

With the CSR in hand, we proceed to generate a self-signed certificate using the openssl x509 command. This certificate is valid for a specified duration, in this case, 365 days. The self-signed certificate establishes the trustworthiness of the server to clients.

openssl x509 -req -days 365 -in selfsigned.csr -signkey selfsigned.key -out selfsigned.crt

Generate an Intermediate Certificate Signing Request (CSR)

This command generates a new CSR (intermediate.csr) using the same private key (selfsigned.key). Intermediate CSRs are optional and may be used in more complex certificate chain configurations.

openssl req -new -key selfsigned.key -out intermediate.csr

Generate an Intermediate Self-Signed Certificate

This command signs the intermediate CSR, creating an intermediate self-signed certificate (intermediate.crt). The certificate is valid for 365 days in this example.

openssl x509 -req -days 365 -in intermediate.csr -signkey selfsigned.key -out intermediate.crt

Generate a Diffie-Hellman Parameter for Perfect Forward Secrecy(Optional):

For enhanced security, you can generate a Diffie-Hellman parameter file. This file, created with the openssl dhparam command, is used to enable Perfect Forward Secrecy (PFS) in the SSL/TLS handshake process.

openssl dhparam -out dhparam.pem 2048

Concatenate Certificates to Create the Certificate Chain

cat selfsigned.crt intermediate.crt > fullchain.crt

This command concatenates the self-signed certificate (selfsigned.crt) and the intermediate certificate (intermediate.crt) into a single file (fullchain.crt). The resulting file represents the complete certificate chain, which is used in the Nginx configuration for SSL/TLS

PFS ensures that even if an attacker compromises the private key in the future, past communications remain secure.

What to do with all these certificates ????

Place these generated files (selfsigned.key, selfsigned.crt, and dhparam.pem if generated) in the certs directory as specified in the Docker Compose script.

Docker compose script ??? what is this? Ok, let us look at the script below, and we look into further

Docker Compose Integration

This Docker Compose script defines a service named nginx-proxy based on the official Nginx image. It mounts configuration files, certificates, and logs as volumes, ensuring that changes to the configuration are reflected in the running container. The service is exposed on ports 80 and 443 for HTTP and HTTPS traffic, respectively.

Now that I have the generated self-signed certificates, I have nginx.conf script and the docker-compose.yaml, let us see how can we get this proxy ready and up!!!

Simple, copy nginx.conf and docker-compose.yaml into a folder called , “nginx”

“certs” folder looks like the below, I mean you can put all the generated self-signed certificates here.

I have all this now, what to do next?

Go to your “nginx” folder, run the below command

docker-compose up

This will bring your Nginx proxy setup up with the redirection, ssl termination and forward your request to your CDN URL, refer to the requirement section.

With this, your docker container with Nginx proxy is up on your host machine listening on 80 and 443, go and use “demoserver.com”

Generate a CloudFront pre-signed url (you know it is active for pre-defined time) and use the Nginx redirection with the setup we have developed, access the url (it is just sample!)

Hit the URL https://demoserver.com/hel/demofile.zip?Expires=AAsLFEn80....&Key-Pair-Id=TY8J74ABCD1EF in browser

and will be redirected to

https://a1b54cd98ef9gh.cloudfront.net/demofile.zip?Expires=AAsLFEn80....&Key-Pair-Id=TY8J74ABCD1EF

demoserver.com to be mapped to your localhost, and you know it!!!

The blog mentions the redirection of URLs from /hel to / as an example of unconventional URL rewriting. This customization may be necessary for specific use cases or application requirements

Best Practices for CloudFront Signed URLs

When using CloudFront to distribute content via signed URLs, it’s crucial to follow best practices. Always sign URLs with an alternate domain name (CNAME) rather than using the default CloudFront domain. This practice ensures that the signed URLs match the SSL/TLS certificate used by the Cloud

Considerations and Challenges!!!

While the described architecture provides unique advantages, it comes with a set of considerations. One aspect to consider is the potential increase in data transfer costs. AWS CloudFront optimizes data delivery with its global edge locations, but the additional layer introduced by Nginx may lead to increased data transfer, particularly if not carefully managed. Furthermore, in the context of CA-signed SSL certificates, ensuring widespread trust across client applications becomes essential. CA-signed certificates enhance security and trust but may involve additional costs and management overhead compared to self-signed alternatives.

Scaling considerations should also be taken into account, as the setup might introduce complexity in managing and scaling the Nginx layer alongside CloudFront. Monitoring and optimizing data flow, considering the cost implications of CA-signed certificates, and addressing potential scaling challenges are essential aspects when adopting this unorthodox design. Ultimately, the decision to embrace this configuration should align with specific use cases, balancing the benefits of customization with the associated considerations and the choice between self-signed and CA-signed certificates.

Conclusion

Some of the concepts like generating Pre-signed URLs, docker/docker-compose setup, proxy setups are left to reader’s understanding and experience!

I tried to put the blog around the use of Nginx proxy before CFN URLs, with re-write URL (as additional )

In this exploration of an unorthodox yet powerful architecture, we delved into the intricacies of leveraging Nginx as a versatile reverse proxy in conjunction with AWS CloudFront. The orchestration of self-signed SSL certificates, fine-grained Nginx configurations, and custom scripts for URL modifications provides a unique avenue for control and customization over the content delivery process. While this setup may be unconventional, its strength lies in the ability to enhance security, tailor content delivery to specific application needs, and exercise granular control over the flow of incoming requests. As technology continually evolves, such innovative configurations underscore the adaptability and versatility of these foundational tools. Whether for testing environments or specific use cases demanding a high level of customization, this unorthodox design showcases the flexibility and power that Nginx brings to the realm of content delivery networks.