Transport security (TLS)

All connections to Teleperson services use HTTPS with TLS 1.2 or higher. This page summarizes how that is enforced and how anyone — customer, auditor, or vendor security reviewer — can verify it without internal access.

What's enforced

• TLS 1.2+ on every endpoint. Both web surfaces (teleperson.com, docs.teleperson.com) and the API (*.supabase.co) negotiate TLS 1.2 or TLS 1.3 only. SSL 2/3 and TLS 1.0/1.1 are rejected at the handshake.

• HSTS with two-year max-age. Every response from *.teleperson.com includes:

  Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
  Content-Security-Policy: upgrade-insecure-requests
  X-Content-Type-Options: nosniff

  Once a browser has visited the site once, it will refuse to make cleartext HTTP connections for the next two years, even if a network attacker tries to strip the upgrade.

• Forward-secret AEAD ciphers only. ECDHE key exchange with AES-GCM or ChaCha20-Poly1305. Static-RSA, CBC, RC4, and 3DES are not offered.

• Browser extension restricted to HTTPS. The TelepersonLens extension only injects on https:// pages. The manifest's host_permissions and content_scripts.matches are restricted to https://*/* (with localhost retained for developer testing). The extension's outbound API calls are 100% HTTPS, to either Teleperson or vendor-managed endpoints (Plaid, Stripe, Anthropic, ElevenLabs, Vapi, MX) that publish their own TLS posture.

• CI guard against regressions. A GitHub Actions workflow fails any pull request that introduces a non-localhost http:// URL into extension or Supabase Edge Function source.

How to verify

Anyone can verify our TLS posture from the public internet:

• Quick check via Qualys SSL Labs:

  • teleperson.com →
  • docs.teleperson.com →
  • teleperson2026.supabase.co →

• Header probe:

  curl -sI https://teleperson.com | grep -iE 'strict-transport|content-security'

• Downgrade rejection:

  openssl s_client -connect teleperson.com:443 -tls1_1 </dev/null
  # Expected: handshake fails with a protocol-version alert

For the full reproducible verification procedure we run before each vendor security review, see the internal runbook docs/security/runbooks/TLS_VERIFICATION.md (referenced in the Information Security Policy §8.2). The runbook is repo-internal because it includes scan commands and artifact-filing instructions, not because the procedure itself is sensitive.

Reporting a TLS issue

If a Teleperson endpoint negotiates anything below TLS 1.2, or a header listed above is missing, please email security@teleperson.com with the hostname and a curl -v or openssl s_client transcript. We treat TLS regressions as P1.