Elasticsearch Does Not Enforce HTTPS: Risks and Remediation

Amazon Elasticsearch Service, now called Amazon OpenSearch Service, exposes an HTTP endpoint that your applications use to index documents and run queries. By default, a domain can accept connections over both HTTP and HTTPS. This Lensix check, elasticsearch_http, looks at the domain's endpoint configuration and fails when HTTPS is not enforced, meaning unencrypted traffic is still allowed.

If a search cluster holds anything sensitive, and most do, sending that data over plain HTTP is a problem worth fixing today.

---

What this check detects

The check inspects the DomainEndpointOptions of each OpenSearch/Elasticsearch domain in your account. Specifically, it reads the EnforceHTTPS field. When that value is false or unset, the domain accepts requests on port 80 over unencrypted HTTP, and the check reports a failure.

You can confirm the current state for any domain with the AWS CLI:

aws opensearch describe-domain \
  --domain-name my-search-domain \
  --query 'DomainStatus.DomainEndpointOptions'

A passing domain returns something like this:

{
  "EnforceHTTPS": true,
  "TLSSecurityPolicy": "Policy-Min-TLS-1-2-2019-07"
}

---

Why it matters

When HTTPS is not enforced, the door to unencrypted connections stays open even if most of your clients use TLS. That gap creates a few concrete risks.

Data exposure in transit

Search clusters frequently store logs, user records, application events, and analytics data. Indexing requests and query responses carry that data across the network. Over HTTP, anyone positioned between the client and the domain can read it in clear text. That includes a malicious actor on a shared network, a compromised intermediate hop, or a misconfigured proxy.

Credential and token leakage

If you use HTTP basic auth or pass signed headers and session tokens to your cluster, those credentials travel with the request. On an unencrypted channel they can be captured and replayed. An attacker who grabs a valid request can impersonate your application against the cluster.

Compliance findings

Encryption in transit is a baseline requirement across PCI DSS, HIPAA, SOC 2, and most internal security policies. An auditor who finds a search domain accepting plain HTTP will flag it, and remediation under audit pressure is never fun.

---

How to fix it

The fix is to enable EnforceHTTPS. When you do this, all HTTP requests are redirected to HTTPS, and clients that only speak HTTP will need to switch. While you are there, set a modern TLS policy.

Using the AWS CLI

aws opensearch update-domain-config \
  --domain-name my-search-domain \
  --domain-endpoint-options '{
    "EnforceHTTPS": true,
    "TLSSecurityPolicy": "Policy-Min-TLS-1-2-PFS-2023-10"
  }'

For legacy Elasticsearch domains still using the es CLI:

aws es update-elasticsearch-domain-config \
  --domain-name my-search-domain \
  --domain-endpoint-options '{
    "EnforceHTTPS": true,
    "TLSSecurityPolicy": "Policy-Min-TLS-1-2-2019-07"
  }'

Using the AWS Console

1. Open the Amazon OpenSearch Service console.
2. Select your domain from the list.
3. Go to the Security configuration tab and choose Edit.
4. Under Network, enable Require HTTPS for all traffic to the domain.
5. Pick a TLS security policy. Choose the most recent policy your clients support, ideally one with perfect forward secrecy.
6. Save changes and wait for the domain status to return to Active.

Using Terraform

If you manage domains as code, set the endpoint options in the resource so drift does not creep back in:

resource "aws_opensearch_domain" "search" {
  domain_name    = "my-search-domain"
  engine_version = "OpenSearch_2.11"

  domain_endpoint_options {
    enforce_https       = true
    tls_security_policy = "Policy-Min-TLS-1-2-PFS-2023-10"
  }

  encrypt_at_rest {
    enabled = true
  }

  node_to_node_encryption {
    enabled = true
  }
}

---

How to prevent it from happening again

Fixing one domain is easy. Keeping every domain compliant as teams spin up new clusters is the real work. Push the requirement left into your pipeline so a non-compliant domain never reaches production.

Block it at the IaC layer

If you use Terraform, scan plans with a policy-as-code tool before apply. Here is an example Open Policy Agent rule for use with Conftest or a similar gate:

package terraform.opensearch

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_opensearch_domain"
  options := resource.change.after.domain_endpoint_options[_]
  options.enforce_https != true
  msg := sprintf("Domain '%s' must enforce HTTPS", [resource.change.after.domain_name])
}

Wire that into CI so a pull request that introduces a non-enforcing domain fails the build before merge.

Detect drift in running accounts

IaC gates only catch what flows through IaC. Someone can still flip a setting in the console or create a domain by hand. Continuous scanning catches those cases. Lensix runs the elasticsearch_http check across your accounts on a schedule and surfaces any domain that stops enforcing HTTPS, so a regression gets caught without anyone remembering to look.

---

Best practices

• Enforce HTTPS on every domain, no exceptions. There is no good reason for a production search cluster to accept plain HTTP.
• Use the newest TLS policy your clients support. Prefer a policy with perfect forward secrecy, such as Policy-Min-TLS-1-2-PFS-2023-10, and avoid policies that still permit TLS 1.0.
• Layer your encryption controls. Enforce HTTPS for client traffic, enable node-to-node encryption inside the cluster, and turn on encryption at rest. Each one covers a different threat.
• Keep domains inside a VPC. A VPC endpoint reduces exposure further by keeping traffic off the public internet, which complements HTTPS rather than replacing it.
• Audit your clients. Make sure every application, dashboard, and ingestion pipeline points at the HTTPS endpoint before you enforce, so the change is a non-event.

Encryption in transit is one of the cheapest security wins available. It costs nothing extra, takes minutes to enable, and removes an entire class of interception risk. The only real work is making sure your clients are ready for it.

Turn on HTTPS enforcement, set a strong TLS policy, and add a check to your pipeline so the setting stays put. Once it is in place and monitored, this finding stops coming back.