Claude skill TLS certificate validation security

TLS validation bypasses are among the most dangerous single-line vulnerabilities in backend code because their effect is total and invisible — every outbound HTTPS call silently becomes an unencrypted, unverified channel once the bypass is in place. In MCP skills the blast radius is especially high: a skill typically holds API keys, OAuth tokens, and database credentials that it forwards in outbound request headers. An attacker on the same network as the skill host (a shared cloud VPC, a container network, a compromised dependency running a local proxy) intercepts all of this. The fix in every case is a one-line removal, but the bypass patterns are easy to introduce during local development with self-signed certificates and hard to find in code review because they are buried in HTTP client options objects.

SA-SKL-TLS-001: rejectUnauthorized: false in HTTPS request options — certificate validation disabled

The most common TLS bypass in Node.js skills is passing { rejectUnauthorized: false } in the options object to https.request(), https.get(), or the agent option of a higher-level HTTP library. The option disables all certificate chain validation for that connection: expired certificates, self-signed certificates, certificates for the wrong hostname, and certificates signed by an untrusted CA are all accepted silently. This is the standard workaround for local development with a self-signed certificate, but it routinely makes it into production because there is no runtime warning when the option is set:

// VULNERABLE: rejectUnauthorized:false disables all certificate validation
import https from 'https';

async function callExternalApi(endpoint: string, token: string): Promise<unknown> {
  return new Promise((resolve, reject) => {
    const req = https.request(endpoint, {
      method: 'GET',
      headers: { Authorization: `Bearer ${token}` },
      rejectUnauthorized: false,  // <-- bypass: certificate not validated
    }, (res) => {
      let body = '';
      res.on('data', (chunk) => { body += chunk; });
      res.on('end', () => resolve(JSON.parse(body)));
    });
    req.on('error', reject);
    req.end();
  });
}

// ALSO VULNERABLE: same option in axios, node-fetch, got, undici, etc.
import axios from 'axios';
const client = axios.create({
  httpsAgent: new https.Agent({ rejectUnauthorized: false }), // bypass
});

// ATTACK: network-positioned MITM
// 1. Attacker positions between skill host and target API server
//    (shared container network, VPC peering, ARP spoofing, DNS hijack)
// 2. Attacker presents any certificate (self-signed, expired, wrong CN)
// 3. Node.js accepts it because rejectUnauthorized:false skips chain validation
// 4. TLS handshake completes normally to attacker's proxy
// 5. Attacker reads: Authorization header with Bearer token
//    Attacker modifies: response body → inject malicious tool data, false AI responses
// 6. All subsequent skill calls to the same endpoint are compromised
//    Token extracted in step 5 can be replayed from outside the skill's network

// SECURE: remove rejectUnauthorized:false and handle the root cause instead
// Root cause 1 (self-signed cert): add CA to NODE_EXTRA_CA_CERTS
// Root cause 2 (internal PKI): bundle the CA cert with the skill container
// Root cause 3 (expired cert): rotate the certificate
const secureReq = https.request(endpoint, {
  method: 'GET',
  headers: { Authorization: `Bearer ${token}` },
  // rejectUnauthorized defaults to true — do not override it
});

// If you need to trust an internal CA (e.g. a corporate PKI):
import { readFileSync } from 'fs';
const secureClient = axios.create({
  httpsAgent: new https.Agent({
    ca: readFileSync('/etc/ssl/internal-ca.pem'),  // trust your CA
    // rejectUnauthorized is implicitly true — certificate IS checked against this CA
  }),
});

SA-SKL-TLS-002: checkServerIdentity override that always returns undefined — hostname validation disabled

Node.js allows overriding the server identity check that runs after the certificate chain is validated. The checkServerIdentity function receives the hostname and the parsed certificate object; if it returns undefined, the connection proceeds; if it throws an error, the connection is rejected. Developers override this function to suppress hostname mismatch errors when working with internal services that use wildcard certificates or certificates with the wrong Common Name. The override that always returns undefined (or returns without throwing) silently accepts any certificate for any hostname, defeating the hostname binding that is the second half of TLS authentication:

// VULNERABLE: checkServerIdentity override suppresses all hostname validation errors
import https from 'https';
import tls from 'tls';

const insecureAgent = new https.Agent({
  checkServerIdentity: (hostname, cert) => {
    // "fix" for SAN mismatch — returns undefined unconditionally
    return undefined;
  },
});

// Also common: empty function body
const alsoInsecure = new https.Agent({
  checkServerIdentity: () => {},  // returns undefined — hostname check suppressed
});

// And the no-op arrow
const alsoInsecure2 = new https.Agent({
  checkServerIdentity: (host, cert) => undefined,
});

// ATTACK: hostname mismatch exploitation
// Scenario: skill connects to https://api.billing.internal (internal service)
// Attacker controls DNS for api.billing.internal (internal DNS compromise, or
//   DNS spoofing on the container network)
// Attacker redirects api.billing.internal → attacker's server
// Attacker presents a valid certificate for a DIFFERENT hostname:
//   e.g. a Let's Encrypt cert for attacker-controlled.example.com
// Without checkServerIdentity override: Node.js rejects — CN/SAN mismatch
// With checkServerIdentity: () => undefined: Node.js accepts — MITM complete
// Attacker now intercepts all billing API calls, reads invoice data, issues credits

// ALSO VULNERABLE: checkServerIdentity that only checks cert.subject.CN
// but not cert.subjectaltname (SANs take precedence over CN in TLS 1.3+)

// SECURE: use the built-in check as a base, only relax specific constraints
const secureAgent = new https.Agent({
  checkServerIdentity: (hostname, cert) => {
    // Run the built-in check first — throws on mismatch
    const err = tls.checkServerIdentity(hostname, cert);
    if (err) {
      // Only suppress for explicitly known internal hosts, never wildcard suppress
      const allowedInternalHosts = new Set(['api.billing.internal', 'db.internal']);
      if (allowedInternalHosts.has(hostname)) {
        // Log the suppression so it's visible in audit logs
        console.warn(`TLS hostname check suppressed for known internal host: ${hostname}`);
        return undefined;  // explicitly allowed
      }
      throw err;  // all other mismatches are fatal
    }
    return undefined;  // built-in check passed
  },
});

// BEST PRACTICE: fix the certificate instead of suppressing the check
// Add the correct SAN/CN to your internal certificate via your PKI
// Use cert-manager (Kubernetes) or AWS ACM Private CA for internal certs

SA-SKL-TLS-003: Deprecated TLS version allowed via minVersion option — BEAST and POODLE exposure

Node.js allows configuring the minimum TLS protocol version accepted for a connection. TLSv1.0 and TLSv1.1 were deprecated by RFC 8996 in March 2021 and are disabled by default in modern OpenSSL builds and Node.js ≥18. However, MCP skill codebases sometimes explicitly re-enable them via the minVersion option when connecting to legacy internal services, or inherit them from an older dependency’s HTTPS agent configuration. Explicitly setting minVersion: 'TLSv1' or 'TLSv1.1' overrides the Node.js default and re-exposes the connection to attacks against these protocols:

// VULNERABLE: explicitly re-enabling deprecated TLS versions
import https from 'https';

const legacyCompatAgent = new https.Agent({
  minVersion: 'TLSv1',    // TLSv1.0: BEAST (CBC chosen-plaintext), POODLE-TLS
  // or:
  minVersion: 'TLSv1.1',  // TLSv1.1: still vulnerable to some CBC padding attacks
});

// Also vulnerable: secureProtocol option (older API, still works)
const alsoVulnerable = new https.Agent({
  secureProtocol: 'TLSv1_method',  // forces TLS 1.0 specifically
});

// ATTACK SURFACE: BEAST (Browser Exploit Against SSL/TLS)
// TLS 1.0 uses CBC mode with predictable IV chaining
// Chosen-plaintext attack recovers plaintext of HTTPS cookies
// In MCP skill context: session tokens, API keys in Cookie header
// Practical exploit: attacker with network visibility + BEAST injection
//   can recover session token from TLS 1.0 traffic in <1000 requests

// ATTACK SURFACE: POODLE (Padding Oracle On Downgraded Legacy Encryption)
// SSL 3.0 / TLS 1.0: CBC padding not fully authenticated
// POODLE variant against TLS: some TLS 1.0 implementations vulnerable
// Practical: session hijacking via padding oracle in MitM position

// NODE.JS DEFAULT: TLSv1.2 minimum since Node 18 (OpenSSL 3.0)
// Explicitly overriding minVersion downgrades below the safe default

// SECURE: do not set minVersion below TLSv1.2
import https from 'https';
import tls from 'tls';

const secureAgent = new https.Agent({
  minVersion: 'TLSv1.2',  // explicit, not relying on the default
  // For new services that you control: TLSv1.3 is preferred
  // minVersion: 'TLSv1.3',  // only TLS 1.3 — eliminates all CBC-mode cipher suites
});

// STARTUP VALIDATION: detect accidental downgrade early
function validateTlsConfig() {
  const allowedVersions = new Set(['TLSv1.2', 'TLSv1.3']);
  const minVer = process.env.NODE_OPTIONS?.match(/--tls-min-v(\S+)/)?.[1];
  if (minVer && !allowedVersions.has(`TLSv${minVer}`)) {
    throw new Error(`Insecure TLS minVersion configured via NODE_OPTIONS: TLSv${minVer}`);
  }
}

// If you must connect to a legacy service that requires TLS 1.0/1.1:
// Use a dedicated sidecar proxy (Envoy, nginx) for the legacy connection
// and connect to the proxy on localhost/TLS 1.3
// Never lower the minimum version for the entire process

SA-SKL-TLS-004: NODE_TLS_REJECT_UNAUTHORIZED=0 environment variable — process-wide validation disabled

The NODE_TLS_REJECT_UNAUTHORIZED environment variable is a process-wide override that disables TLS certificate validation for every HTTPS connection made by the Node.js process. Setting it to 0 is equivalent to passing rejectUnauthorized: false in every HTTPS request options object simultaneously. It is used during local development to bypass TLS issues without modifying source code, and it is the standard suggestion in many stack overflow answers and framework documentation pages. The critical failure mode is that this variable is set in the skill’s deployment environment (a Dockerfile, a container environment spec, a cloud run service YAML, a CI secret) and never removed after the original debugging session:

// VULNERABLE: environment variable that disables TLS validation process-wide
// Set in one of these common locations:

// 1. Dockerfile (most dangerous — permanently in the container image)
ENV NODE_TLS_REJECT_UNAUTHORIZED=0

// 2. docker-compose.yml
environment:
  - NODE_TLS_REJECT_UNAUTHORIZED=0

// 3. .env file (picked up by dotenv / Docker Compose)
NODE_TLS_REJECT_UNAUTHORIZED=0

// 4. Shell startup script / entrypoint.sh
export NODE_TLS_REJECT_UNAUTHORIZED=0
node dist/index.js

// 5. CI/CD pipeline secrets (most subtle — appears at runtime, not in code)
// GitHub Actions: ACTIONS_RUNNER_DEBUG=true often paired with TLS bypass

// EFFECT: every HTTPS call made by the skill, by any dependency,
//   by any SDK, is now unvalidated
// Including: Anthropic SDK calls, database TLS connections,
//   monitoring agent HTTPS, logging SDK, OpenTelemetry exporter

// ATTACK: container network MITM
// Skill deployed in Kubernetes or Docker Compose with NODE_TLS_REJECT_UNAUTHORIZED=0
// Compromised sidecar container or network plugin intercepts traffic
// Attacker reads all outbound API calls: Anthropic API key in Authorization header,
//   database connection string parameters, OAuth client secrets
// No code change needed — the env var does the work

// SECURE: startup validation that throws if the env var is set to 0
// Add this to your skill's initialization code, before any HTTPS calls

function assertTlsValidationEnabled(): void {
  if (process.env.NODE_TLS_REJECT_UNAUTHORIZED === '0') {
    throw new Error(
      'NODE_TLS_REJECT_UNAUTHORIZED=0 is set — TLS certificate validation is disabled. ' +
      'This is not allowed in production. Remove the variable or set it to 1. ' +
      'If you need to trust a custom CA, use NODE_EXTRA_CA_CERTS=/path/to/ca.pem instead.'
    );
  }
  // Also check for the deprecated equivalent
  if (process.env.NODE_TLS_REJECT_UNAUTHORIZED === 'false') {
    throw new Error('NODE_TLS_REJECT_UNAUTHORIZED=false is equivalent to =0 — same fix applies.');
  }
}

// Call at the top of your skill's entry point, before any SDK initialization
assertTlsValidationEnabled();

// ALTERNATIVE: if the cert is from an internal CA, use this instead:
// NODE_EXTRA_CA_CERTS=/etc/ssl/my-internal-ca.pem
// This appends your CA to the built-in CA store WITHOUT disabling validation
// All certificates signed by your CA are trusted; all others still require a valid chain

Remediation summary

SkillAudit detects all four SA-SKL-TLS-001 through TLS-004 patterns through static analysis of skill source code and configuration files: rejectUnauthorized: false in HTTPS options, checkServerIdentity overrides that do not call the base check, minVersion values below TLSv1.2, and NODE_TLS_REJECT_UNAUTHORIZED=0 in Dockerfiles, .env files, and shell scripts included in the repository. For related security patterns see SA-SKL-NET network egress security, SA-SKL-SSRF server-side request forgery, and SA-SKL-KMG key management security. See the complete SA-SKL attack surface reference for the full vulnerability taxonomy.