Skip to main content

How to replace HTTP with HTTPS to help protect your network

Using clear-text protocols like HTTP can put your network at risk. Learn how to upgrade to HTTPS.

Image by DarkmoonArt_de from Pixabay

Clear-text protocols are trivially easy to capture and analyze, so using them puts your network security at risk. Many of these services were written when the internet was in its infancy; now that attackers have better tools to capture sensitive information, the bar is pretty low for this type of attack to succeed.

[ Check out this guide to boosting hybrid cloud security and protecting your business. ]

In this article, I'll explain why it's a good idea to replace clear-text and other insecure and obsolete network protocols with more secure options. First, I'll also show you how to replace HTTP with HTTPS, and my companion article explains how to switch Telnet for secure shell (SSH) and FTP for SFTP.

These articles will explain:

  • How to use Podman to set up throwaway services to learn about insecure settings and protocols
  • How to use TShark to capture and decode network traffic in real time
  • How to replace obsolete services with more modern alternatives to eliminate this type of attack

This tutorial assumes you have:

  • Access to Podman or Docker
  • Privileged access to run TShark and containers in a special mode
  • Basic knowledge of network protocols like TCP/IP, HTTP, or FTP (but don't worry too much if you don't)

[ Download now: Podman basics cheat sheet ]

Prepare your Apache sandbox

This tutorial will capture credentials for basic authentication against an unencrypted HTTPD Apache server.

You need a self-signed SSL certificate for this demo, so create a container. I used the Fedora 37 Linux distribution and the mkcert application:

[josevnz@dmaf5 self_signed_certificates]$ podman run --rm --interactive --tty --volume $HOME/Downloads:/certs mkcert_image mkcert -cert-file /certs/cert.pem -key-file /certs/cert.key dmaf5 localhost ::1

You will use this new SSL certificate for your Podman container running Apache:

Next, build a special Apache container:

Test the authentication with curl:

curl --silent --user admin:notsosecurepassword http://dmaf5:88080/secret/
# We use --insecure because is a self-signed certificate
curl --insecure --silent --user admin:notsosecurepassword https://dmaf5:8443/secret/

The next step is to check how much sensitive information you can get with TShark.

[ Learn more about TShark and how to interpret captured Wireshark information. ]

Use TShark to sniff the traffic between curl and a Podman container

HTTP sends data without encryption. To test this setup, create a Podman container that protects a directory with a user and password combination:

[josevnz@dmaf5 httpd]$ curl --silent --user admin:notsosecurepassword http://dmaf5:8080/secret/
<!-- Simple webpage used in our demo site. -->
    <title>ASCII art with Python 3</title>
<body bgcolor="black">
<script id="asciicast-518884" src="" async></script>

Any attacker running TShark could quickly get your password. Adding the -Y option to your TShark expression allows you to focus on the traffic you care about:

tshark -i eno1 -Y 'http.request.method == GET and == dmaf5:8080' -T json

The captured output may look like this:

TShark is "nice enough" to decode the Base64 password for you (echo YWRtaW46bm90c29zZWN1cmVwYXNzd29yZA==|base64 --decode).

The problem is much worse than just password leaking. Any data you transmit (including sensitive documents or credit card information) can be captured and extracted later.

Try an encrypted connection

Now try using a secure connection. For this demo, you can use a self-signed certificate. Make sure to use a proper setup when using this in production.

Because the traffic is encrypted, the following expression doesn't show any data, as TShark cannot see the encrypted payload:

tshark -i eno1 -Y 'http.request.method == GET and == dmaf5:8443' -T json

You have to go lower on the protocol stack:

tshark -i eno1 -Y 'tcp.port == 8443' -T json

No password this time!

[ Want to test your sysadmin skills? Take a skills assessment today. ]

Switch to HTTPS

The fix for HTTP is to use HTTPS instead. You can easily install a self-signed certificate for your test servers using mkcert. Or, if you have internet-facing services, you can use Certbot. This is an Ansible playbook fragment to secure an Nginx proxy:

- name: Setup Certbot
    requirements: /opt/requirements_certboot.txt
    virtualenv: /opt/certbot/
    virtualenv_site_packages: true
    virtualenv_command: /usr/bin/python3 -m venv
  tags: certbot_env

- name: Get SSL certificate
      - /opt/certbot/bin/certbot
      - --nginx
      - --agree-tos
      - -m {{ ssl_maintainer_email }}
      - -d {{ inventory_hostname }}
      - --non-interactive
    - Restart Nginx
  tags: certbot_install

- name: Creates a cron file under /etc/cron.d/certbot_renew
    name: certboot renew
    weekday: "5"
    minute: "0"
    hour: "0"
    user: root
    job: "/opt/certbot/bin/certbot renew --quiet --pre-hook 'systemctl stop nginx' --post-hook 'systemctl start nginx'"
    cron_file: certbot_renew
  tags: certbot_renew

What's next?

In my next article, I'll show you how to switch two other outdated, clear-text network protocols for better options: Telnet for SSH and FTP for SFTP. In the meantime:

Topics:   Security   Networking   Web servers  
Author’s photo

Jose Vicente Nunez

Proud dad and husband, software developer and sysadmin. Recreational runner and geek. More about me

Try Red Hat Enterprise Linux

Download it at no charge from the Red Hat Developer program.