Bleichenbacher Attack in Restify

The Bleichenbacher attack (CVE-1999-0702) is a classic chosen-ciphertext attack against RSA PKCS#1 v1.5 padding, often targeting TLS handshakes. In a Restify API context, the vulnerability manifests not in Restify's core itself—which is an HTTP server framework built on Node.js—but in how TLS termination is configured when Restify serves HTTPS directly or sits behind a misconfigured proxy.

Restify applications typically enable HTTPS by passing a TLS configuration object to the server.listen(port, host, tlsOptions) method or by using middleware like restify-ssl. The attack becomes possible if the underlying Node.js tls module (or the fronting proxy like Nginx) is configured to allow SSL/TLS renegotiation or returns distinct error messages for different padding failures. An attacker can exploit this by sending thousands of malformed ClientHello messages with crafted ciphertexts, observing subtle differences in server responses (e.g., timing, alert codes, or HTTP status codes) to gradually decrypt a captured RSA ciphertext—often a session ticket or a pre-master secret.

For example, a common Restify setup might look like this:

const restify = require('restify');
const server = restify.createServer({
  name: 'api-service',
  tls: {
    key: fs.readFileSync('server.key'),
    cert: fs.readFileSync('server.crt')
    // Missing secure renegotiation or padding checks
  }
});
server.listen(8443, '0.0.0.0');

If the TLS configuration does not explicitly disable insecure renegotiation (renegotiation: false in Node.js) or use a constant-time padding validation (which Node's TLS stack does by default in modern versions), the server may leak information through TLS alert messages that Restify then converts into HTTP responses. An attacker targeting an endpoint that uses client certificate authentication or session resumption could abuse this to recover encrypted session tokens or other RSA-encrypted data.

Detecting a Bleichenbacher vulnerability in a Restify API requires testing the TLS layer for padding oracle behavior. Since middleBrick performs black-box scanning without credentials, it simulates the attack by sending a series of malformed TLS ClientHello packets containing ciphertexts with manipulated PKCS#1 v1.5 padding to the target endpoint. The scanner then analyzes response patterns—including TLS alert types (e.g., bad_record_mac vs. decryption_failed), timing discrepancies, and HTTP-level error codes returned by Restify after TLS termination.

middleBrick's Encryption check (one of its 12 parallel security tests) specifically includes probes for RSA PKCS#1 v1.5 padding oracle vulnerabilities. After scanning a Restify endpoint, the report will show a per-category score for Encryption, and if a Bleichenbacher flaw is detected, it will appear as a high-severity finding with details like:

• Evidence: Differential response patterns for invalid padding (e.g., HTTP 400 vs. 500, or varying TLS alert codes).
• CWE Reference: CWE-327 (Use of a Broken or Risky Cryptographic Algorithm).
• OWASP Category: Cryptographic Failures (A02:2021).

For example, a middleBrick scan of a vulnerable Restify API might return a JSON snippet like:

{
  "category": "encryption",
  "severity": "critical",
  "title": "RSA PKCS#1 v1.5 Padding Oracle (Bleichenbacher)",
  "evidence": "Server returns TLS alert 0x15 (handshake_failure) for malformed padding, but alert 0x2A (decrypt_error) for valid structure with bad padding",
  "remediation": "Disable TLS renegotiation and ensure Node.js uses constant-time padding validation"
}

This actionable finding allows Restify developers to pinpoint the exact TLS misconfiguration without needing internal access.

Remediation focuses on securing the TLS configuration that Restify relies on. Since Restify delegates TLS to Node.js's tls module (or an external proxy), the fix must be applied at that layer. The primary steps are:

1. Disable TLS renegotiation in the Node.js TLS options. Modern Node.js versions (v12+) disable insecure renegotiation by default, but it must be explicitly set if supporting older clients.
2. Ensure constant-time padding validation—Node.js's TLS implementation uses constant-time checks for RSA decryption in versions >= 8.4.0, but this can be bypassed if custom certificate verification callbacks are used.
3. Prefer TLS 1.3, which eliminates RSA key exchange and PKCS#1 v1.5 padding entirely.

Here is a secure Restify server configuration:

const restify = require('restify');
const server = restify.createServer({
  name: 'secure-api',
  tls: {
    key: fs.readFileSync('/path/to/server.key'),
    cert: fs.readFileSync('/path/to/server.crt'),
    // Explicitly disable renegotiation (though default in Node >= 12)
    renegotiation: false,
    // Enforce TLS 1.2+; TLS 1.3 avoids RSA key exchange
    minVersion: 'TLSv1.2',
    // Cipher suites that exclude RSA key exchange (forward secrecy)
    ciphers: [
      'ECDHE-RSA-AES128-GCM-SHA256',
      'ECDHE-ECDSA-AES128-GCM-SHA256'
    ].join(':'),
    // Honor the cipher order
    honorCipherOrder: true
  }
});

// If using client certificates, ensure verification is constant-time
server.on('tlsClientError', (err, socket) => {
  // Do not leak error details in responses
  socket.destroy(err);
});

server.listen(8443, '0.0.0.0', () => {
  console.log('API listening securely');
});

If Restify is behind a proxy like Nginx, the proxy must also be configured to disable renegotiation and use secure ciphers. For example, in Nginx:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers on;
ssl_session_tickets off; # Disable session tickets if using RSA key exchange

After applying these changes, re-scan the endpoint with middleBrick to verify the Encryption category score improves and the Bleichenbacher finding is resolved. The remediation guidance in the middleBrick report will provide these exact configuration adjustments tailored to the detected flaw.