Onionspray and EOTK does not verify the upstream TLS certificate

Description

EOTK (and hence Onionspray) currently does not verify the upstream TLS certificate situation.

Steps to reproduce

Click here for a list of steps to reproduce this behavior

1. Install Onionspray

Proceed with the Install Onionspray guide. Or test with EOTK if you prefer.

2. Create a test service

Create and run a project with the following configuration:

set nginx_resolver 8.8.8.8 8.8.4.4 ipv6=off
set log_separate 1
set project badssl
hardmap %NEW_V3_ONION% badssl.com

This will create a Onion Service proxy to https://badssl.com.

3. Test

Access both https://badssl.com flavours and the corresponding .onion from the badssl project.

Expected behavior

It's expected that the generated Onion Service would have a bad gateway when accessing an upstream with problematic TLS certificate, eg. https://expired.etzuksalmgy62xvhv7tj427jkzow4o5j364mwfmsronu2we3ird3puad.onion/

Actual behavior

No warnings or error, and the site is rendered as if the certificate was valid.

Screenshots

Compare each version (non-onionsite and onionsite) when acessed through Tor Browser.

Main badssl.com and it's .onion counterpart

Nothing unusual here, just for setting a baseline:

Expired certificate in the backend

Wrong host in the backend's certificate

Self-signed certificate in the backend

Untrusted root in the backend

Revoked certificate in the backend

Bad HPKP pin in the backend certificate

Impact

• Severity: CRITICAL.
• All Onion Services running with current Onionspray and EOTK are affected.
• The impact Onion Service may be prone to machine-in-the-middle (MITM) attacks that can rewrite the website content and also listen to all traffic between the user and the affected onionsite.

Fix

The fix basically involves adding the following into the NGINX template:

proxy_ssl_verify on;
proxy_ssl_trusted_certificate /path/to/some.crt;

File /etc/ssl/certs/ca-certificates.crt will work in most cases, but it's not widely available in all Operating systems.

The complete fix is currently available in branch fix/nginx_proxy_ssl_verify from my personal Onionspray fork (which is currently set to private, so you need at least Reporter access there to browse).

Security advisory and Timeline

A security advisory draft is available privately and has a timeline for this issue.

References

• badssl.com
• Securing HTTP Traffic to Upstream Servers | NGINX Documentation
• Module ngx_http_proxy_module

Tasks

• Investigate:
  • Make the issue easily reproducible.
  • Write a issue report so it can be easily understood.
  • Test reproducing with EOTK to make sure it's also affected.
• Fix:
  • Create a patch for Onionspray:
    • Fixing the issue.
    • Updating all example configurations.
    • Giving a warning if the option is not used in a project.
    • Adding a dedicated security advisory page.
    • Documenting how a proper setup should be done.
  • Create a patch for EOTK.
• Release:
  • Get a TROVE-ID, if applicable. TROVE-2024-002.
  • Get a CVE-ID, if applicable.
  • Responsible Disclosure:
    • Write a draft message to Alec Muffett.
    • Write a draft template message to known affected operators.
    • Contact Alec Muffett discreetly, sending the patch for EOTK (Cc security@torproject.org, and attaching it's OpenPGP key).
    • Contact known affected operators, discreetly. Try to coordinate a security release for both EOTK and Onionspray (Cc security@torproject.org, and attaching it's OpenPGP key).
    • Give some time to these people apply the fixes. That was not possible to do since EOTK went ahead and released a fix earlier than we planned.
    • Publish the Onionspray patch.
    • Publish the EOTK patch.
    • Make this ticket public.
    • Update the TROVE-ID page.

Time estimation

• Complexity: small (1 day)
• Uncertainty: low (x1.1)
• Reference (adapted)