If you're a developer looking to learn more about the steps you can take to begin deploying secure infrastructure as code (IaC) in your organization, then you've come to the right place. This is the next chapter in our IaC series, designed to level you up in IaC security best practices.

Before we start, how did you fare with the challenge from the last installment? If you have mastered insecure cryptography, let's see how you go with insufficient transport layer protection before we dig into the details:

Want to learn more and achieve a perfect score? Read on:

In our last article, we talked about the importance of having secure cryptography to protect any important or personal data stored by applications and programs. If you have strong encryption, it acts as a perfect last line of defense. Even if an attacker is able to steal that data, if it's strongly encrypted, then the information locked inside those files is still protected.

Protecting data at rest, however, is only one part of a complete data defense. Whenever valid users need to access protected data, it has to be sent to them. At times, applications will also share data with other programs as part of an overall workload. Unless the transport layer is protected, it makes it vulnerable to both outside snooping and unauthorized internal viewing. As such, having insufficient transport layer protection can cause serious issues.

It's a common problem. The OWASP security organization even maintains a full page about insufficient transport layer protection.

Why is insufficient transport layer protection dangerous?

If you don't sufficiently protect your transport layers, then it's relatively easy for skilled hackers to intercept information flowing between your users and your applications using techniques like man-in-the-middle attacks. Probably the most dangerous aspect of this kind of snooping is that it's almost completely invisible to any internal cybersecurity platforms or scans because it occurs outside of your network and your control.

For example, in a Docker environment deploying an Nginx service:

services:
 nginx:
   image: localhost:5000/scw_nginx
   build: ./nginx
   secrets:
     - nginx_cert
     - nginx_key
   volumes:
     - type: bind
       source: ./nginx/nginx.conf
       target: /etc/nginx/nginx.conf
       read_only: yes
   ports:
     - 80:8443
   networks:
     - frontend
   deploy:
     restart_policy: *default-restart_policy
     resources: *default-resources_policy

The Nginx service configuration will not encrypt or protect the connection, making all information exchanged through the link vulnerable to a variety of attacks or snooping.

server {
       server_name scw-dev-blog.org;
       listen 8443;
       ssl_protocols TLSv1.2 TLSv1.3;
       ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
       ssl_prefer_server_ciphers on;
       ssl_certificate /run/secrets/nginx_cert;
       ssl_certificate_key /run/secrets/nginx_key;
       access_log /dev/stdout;
       error_log /dev/stderr;
       location / {
           proxy_pass http://wordpress:8080;
           proxy_set_header Host $http_host;
           proxy_set_header X-Forwarded-Host $http_host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
       }
   }

Often times, the first signal that someone might be snooping through your transport layers is when a large number of stolen user passwords are used in subsequent attacks. If other data like customer information, financial records or important company secrets are stolen via an insecure transport layer, you may never even realize that you have been compromised.

And it's not just the transport layer between users and applications that requires protection. On the backend, many applications communicate with one another and with servers farther along in the workflow chain. While these internal communications are generally not vulnerable to outside snooping, it can expose data to users who may be allowed on the network but not authorized to see certain highly-protected or sensitive information.

Properly securing transport layers for total data protection

Protecting transport layers is best done while applications are being created. This process begins with having a secure backend infrastructure. For websites, everything should be done using HTTPS. Never mix HTTP and HTTPS infrastructure. You should even set your sites to automatically route unsecured HTTP requests over to the HTTPS infrastructure.

In the example from above, a proper method of protecting the transport layer would be:

server {
       server_name scw-dev-blog.org;
       listen 8443 ssl;
       ssl_protocols TLSv1.2 TLSv1.3;
       ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
       ssl_prefer_server_ciphers on;
       ssl_certificate /run/secrets/nginx_cert;
       ssl_certificate_key /run/secrets/nginx_key;
       access_log /dev/stdout;
       error_log /dev/stderr;
       location / {
           proxy_pass http://wordpress:8080;
           proxy_set_header Host $http_host;
           proxy_set_header X-Forwarded-Host $http_host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
       }
   }

In that example, all connections with the Nginx service are strongly encrypted. The server section of the Nginx configuration only includes listen 8443 ssl in order to force SSL to protect connections.

To protect your data from insider threats, developers should employ a strong transport layer encryption protocol like TLS 1.2. Once you have TLS 1.2 or its equivalent in place, weaker protocols like SSL v2 should be completely removed from your infrastructure and automatically barred from ever being used.

And always keep in mind that securing an application isn't fully complete until both the data at rest and the transport layers are sufficiently protected. That way you can guarantee complete end-to-end protection for data both internally and when flowing to authorized external users.
Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and customers from the ravages of other security flaws. You can also try a demo of the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.