Description

This rule verifies that every DigitalOcean Load Balancer terminates TLS and enforces HTTPS for client-facing traffic instead of accepting or forwarding plaintext HTTP. On a DigitalOcean Load Balancer, HTTPS enforcement is expressed through the forwarding rules: an entry rule with an entry_protocol of https, http2, or http3 on port 443 must be bound to a TLS certificate (certificate_id) or configured for TLS passthrough, and the load balancer's redirect_http_to_https setting must be enabled so that any request arriving on HTTP port 80 is redirected to the encrypted listener.

The rule inspects each load balancer's forwarding_rules and redirect_http_to_https flag. It flags load balancers that expose an http entry rule with no corresponding https/http2/http3 rule, and load balancers that accept HTTP on port 80 without redirect_http_to_https enabled, so that plaintext requests are served rather than upgraded to TLS.

Remediation is to add an HTTPS (or HTTP/2 / HTTP/3) entry rule bound to a valid certificate, enable Force HTTPS (redirect_http_to_https) so the port-80 listener 307-redirects to 443, and remove any standalone HTTP entry rule that no legacy client depends on.

  • Load balancers with an HTTP (port 80) forwarding rule and no HTTPS/HTTP2/HTTP3 rule.

  • Load balancers serving HTTP on port 80 with redirect_http_to_https disabled (no Force HTTPS).

  • HTTPS entry rules with no certificate_id and tls_passthrough not set.

Rationale

Traffic that reaches the load balancer over plain HTTP travels unencrypted across the network segment between the client and the load balancer, where it can be read or modified by anyone in the path. Enforcing TLS termination at the load balancer ensures credentials, session cookies, and payloads are confidential and integrity-protected end to the load balancer, and redirecting HTTP to HTTPS closes the window in which a client might otherwise transmit sensitive data in cleartext before being upgraded.

Serving both HTTP and HTTPS without a redirect leaves a downgrade path that attackers can exploit (for example, stripping the connection back to HTTP). A single enforced HTTPS entry point removes that ambiguity and is a baseline expectation of most compliance frameworks.

  • Protects data in transit against interception and tampering on the client-to-load-balancer hop.

  • Removes HTTP downgrade / SSL-stripping opportunities.

  • Aligns with PCI DSS, SOC 2, and GDPR expectations for encrypting data in transit.

Impact

Pros:

  • All client traffic is encrypted or automatically upgraded to an encrypted listener.

  • Eliminates plaintext listeners that can leak credentials and session data.

  • Consistent, auditable HTTPS-only posture across the fleet.

Cons:

  • Requires a valid certificate provisioned and bound to the load balancer.

  • Legacy clients or health probes hard-coded to HTTP port 80 may need updating.

  • TLS termination adds a small amount of processing on the load balancer.

Default Value

New DigitalOcean Load Balancers do not redirect HTTP to HTTPS by default (redirect_http_to_https defaults to false), and forwarding rules are whatever you define at creation, so HTTPS enforcement is not on unless you configure it.

Pre-Requisite

  • A DigitalOcean account role that can view and edit Load Balancers (for example Owner or a member with modify access to Networking).

  • A doctl instance authenticated with a DigitalOcean API token, or the token exported as $DIGITALOCEAN_TOKEN, with read/write scope.

  • A TLS certificate available in the account (Let's Encrypt managed or a custom uploaded certificate) for the load balancer's domain.

Remediation

Test Plan

Using the DigitalOcean Control Panel:

  1. Sign in to the DigitalOcean Control Panel at cloud.digitalocean.com.

  2. In the left menu, go to Networking, then open the Load Balancers tab.

  3. Select the load balancer you want to inspect.

  4. Open the Settings tab and review the Forwarding Rules: confirm at least one rule uses HTTPS (or HTTP/2 / HTTP/3) on entry port 443 with a certificate selected.

  5. Confirm the 'Redirect HTTP to HTTPS' (Force HTTPS) option is enabled.

  6. Check whether a standalone HTTP entry rule on port 80 exists that is not covered by the redirect.

  7. Pass: An HTTPS/HTTP2/HTTP3 entry rule with a valid certificate exists and Redirect HTTP to HTTPS is enabled (or no HTTP listener exists at all).

  8. Fail: The load balancer exposes an HTTP port-80 rule with no HTTPS rule, or Redirect HTTP to HTTPS is disabled while HTTP is still accepted.

Using doctl or the API:

List load balancers and inspect each one's forwarding_rules and redirect_http_to_https flag.

doctl compute load-balancer list --format ID,Name,RedirectHttpToHttps,ForwardingRules
doctl compute load-balancer get <load-balancer-id> --format ForwardingRules,RedirectHttpToHttps
curl -s -X GET "https://api.digitalocean.com/v2/load_balancers" -H "Authorization: Bearer $DIGITALOCEAN_TOKEN" | jq '.load_balancers[] | {id, name, redirect_http_to_https, forwarding_rules}'

Pass: for each load balancer, redirect_http_to_https is true and forwarding_rules includes an entry_protocol of https/http2/http3 with a certificate_id set (or tls_passthrough true). Fail: forwarding_rules contains an http entry rule with no https/http2/http3 counterpart, or redirect_http_to_https is false while an http rule is present.

Implementation Steps

Using the DigitalOcean Control Panel:

  1. In the Control Panel, go to Networking, then Load Balancers, and select the load balancer.

  2. Open the Settings tab and locate Forwarding Rules.

  3. Add or edit a rule so entry protocol is HTTPS (or HTTP/2 / HTTP/3) on port 443, and select a certificate (Let's Encrypt or a custom certificate) for TLS termination.

  4. Enable the 'Redirect HTTP to HTTPS' option so port-80 requests are redirected to 443.

  5. Remove any remaining HTTP-only forwarding rule that no client legitimately requires.

  6. Save the changes and confirm the forwarding rules reflect the new HTTPS-only posture.

Using doctl or the API:

Update the load balancer's forwarding rules and enable redirect_http_to_https via doctl or the API.

doctl compute load-balancer update <load-balancer-id> --redirect-http-to-https --forwarding-rules "entry_protocol:https,entry_port:443,target_protocol:http,target_port:80,certificate_id:<certificate-id>"
curl -s -X PUT "https://api.digitalocean.com/v2/load_balancers/<load-balancer-id>" -H "Authorization: Bearer $DIGITALOCEAN_TOKEN" -H "Content-Type: application/json" -d '{"redirect_http_to_https": true, "forwarding_rules": [{"entry_protocol":"https","entry_port":443,"target_protocol":"http","target_port":80,"certificate_id":"<certificate-id>"}]}'

Backout Plan:

  1. Record the current forwarding_rules and redirect_http_to_https value before changing them (doctl compute load-balancer get <id>).

  2. If the HTTPS change breaks a client, re-run the update with the previous forwarding_rules JSON to restore the earlier configuration.

  3. Set redirect_http_to_https back to false only if the redirect itself is the cause, and re-add the prior HTTP rule if it was required.

  4. Verify the restored load balancer serves traffic as before.

References:

  1. DigitalOcean Load Balancers — Features (SSL termination, Force HTTPS)

  2. DigitalOcean Load Balancers API reference

  3. How to Manage Regional Load Balancers

  4. doctl compute load-balancer update