AI Rules for HTTPS and TLS

AI Treats HTTPS as Optional

AI generates code with: HTTP URLs (http://api.example.com instead of https://), self-signed certificates in development that leak to production, no HTTP-to-HTTPS redirect (both protocols serve the same content), no HSTS header (browsers do not remember to use HTTPS), and outdated TLS versions (TLS 1.0/1.1 still enabled). Each of these enables man-in-the-middle attacks, credential interception, and session hijacking on public networks.

Modern HTTPS is: mandatory (HTTPS everywhere, HTTP redirects to HTTPS), enforced (HSTS tells browsers to never use HTTP), preloaded (HSTS preload list means HTTPS from the very first request), automated (Let's Encrypt with auto-renewal, no manual certificate management), and modern (TLS 1.3 only, no legacy cipher suites). AI generates none of these.

These rules cover: TLS 1.3 configuration, HSTS with preloading, automated certificate management, HTTP-to-HTTPS redirect enforcement, and cipher suite selection.

Rule 1: TLS 1.3 as Minimum Version

The rule: 'Set TLS 1.3 as the minimum version. TLS 1.0 and 1.1 are deprecated (RFC 8996, March 2021) — known vulnerabilities, weak ciphers. TLS 1.2 is acceptable as a fallback for older clients, but TLS 1.3 should be preferred. TLS 1.3 provides: faster handshakes (1-RTT, even 0-RTT for resumed connections), stronger ciphers (no legacy cipher negotiation), and simplified protocol (removed problematic features like renegotiation and compression).'

For server configuration: 'Nginx: ssl_protocols TLSv1.3 TLSv1.2; ssl_prefer_server_ciphers on;. Node.js: tls.createServer({ minVersion: 'TLSv1.2', maxVersion: 'TLSv1.3' }). Cloud providers (Vercel, Cloudflare, AWS CloudFront): TLS 1.3 is enabled by default — verify and disable TLS 1.0/1.1 in security settings. Test your configuration with: ssllabs.com/ssltest or testssl.sh.'

AI generates: no TLS configuration. The default is often TLS 1.0+ (accepting everything). A client using TLS 1.0 on public WiFi is trivially intercepted. Setting the minimum to TLS 1.2 (with 1.3 preferred) closes this vulnerability while maintaining compatibility with 99%+ of current clients.

Rule 2: HSTS with Preloading

The rule: 'Set the Strict-Transport-Security header: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload. max-age=31536000: browsers remember HTTPS-only for 1 year. includeSubDomains: all subdomains also HTTPS-only. preload: eligible for the HSTS preload list (browsers hard-code HTTPS for your domain — no first-request vulnerability). Submit to hstspreload.org after setting the header.'

For why HSTS matters: 'Without HSTS: the first request to your domain may be HTTP (user types example.com in the address bar). A man-in-the-middle on the network intercepts this HTTP request and either: serves a fake login page or strips HTTPS (replacing HTTPS links with HTTP). With HSTS: the browser upgrades to HTTPS before sending the request. With HSTS preload: the browser knows to use HTTPS even on the very first visit.'

AI generates: no HSTS header. The first visit is vulnerable to SSL stripping. After the first HTTPS visit, the browser does not remember — the next visit may be HTTP again. HSTS is one response header that tells the browser: this domain is HTTPS forever. One header, permanent protection.

• Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
• max-age=31536000: 1 year HTTPS enforcement in browser memory
• includeSubDomains: all subdomains inherit HSTS policy
• preload: submit to hstspreload.org for hard-coded browser HTTPS
• Test before preloading — HSTS preload is difficult to reverse

Rule 3: Automated Certificate Management

The rule: 'Use Let's Encrypt with automated renewal. Never manage certificates manually — manual certificates expire, renewal is forgotten, and the site goes down. Tools: certbot (standalone), Caddy (built-in HTTPS), Traefik (auto-provisioning). Cloud platforms (Vercel, Netlify, CloudFlare) manage certificates automatically. For custom domains: ensure auto-renewal is configured and monitored.'

For certificate monitoring: 'Monitor certificate expiration with: uptime checks that verify HTTPS (not just HTTP 200), certificate expiration alerts (warn at 30 days, critical at 7 days), and CT (Certificate Transparency) log monitoring (detect unauthorized certificates for your domain). Let's Encrypt certificates expire after 90 days — the short lifetime is intentional (limits exposure from compromised keys). Auto-renewal runs at 60 days — 30-day buffer for failures.'

AI generates: HTTPS setup instructions that involve manually downloading certificates. The developer follows the instructions once, gets HTTPS working, then forgets about renewal. 90 days later: certificate expired, site shows a security warning, users cannot access the app. Automated renewal means: set up once, monitored always, renewed automatically.

Rule 4: HTTP-to-HTTPS Redirect Enforcement

The rule: 'Redirect all HTTP requests to HTTPS with a 301 (permanent) redirect. Nginx: server { listen 80; return 301 https://$host$request_uri; }. Express middleware: if (req.protocol === "http") res.redirect(301, "https://" + req.headers.host + req.url). The 301 tells browsers and search engines: this URL is permanently HTTPS. Subsequent requests go directly to HTTPS (no redirect round trip).'

For redirect chains: 'Avoid redirect chains: http://example.com -> https://example.com -> https://www.example.com = two redirects. Configure: http://example.com -> https://www.example.com (one redirect to the canonical URL). http://www.example.com -> https://www.example.com (one redirect). Each redirect adds latency and loses a small amount of SEO value. Minimize redirects by going directly to the canonical HTTPS URL.'

AI generates: HTTP and HTTPS serving the same content with no redirect. Search engines index both versions (duplicate content). Users bookmark the HTTP version (insecure). APIs accept HTTP requests (credentials sent in plaintext). A 301 redirect centralizes all traffic on HTTPS and eliminates the insecure access path entirely.

Rule 5: Modern Cipher Suite Selection

The rule: 'For TLS 1.3: the protocol defines its cipher suites — no configuration needed (all TLS 1.3 ciphers are strong). For TLS 1.2 fallback: prefer ECDHE key exchange (forward secrecy), AES-GCM or ChaCha20 encryption, and SHA-256+ digests. Disable: RC4, 3DES, CBC-mode ciphers (BEAST/POODLE vulnerable), RSA key exchange (no forward secrecy), and export-grade ciphers (40/56-bit keys, trivially broken).'

For forward secrecy: 'Forward secrecy (via ECDHE) means: even if your private key is compromised in the future, past encrypted traffic cannot be decrypted. Without forward secrecy (RSA key exchange): an attacker records encrypted traffic today, steals your private key next year, and decrypts all historical traffic. ECDHE generates ephemeral keys per session — the private key cannot decrypt past sessions.'

AI generates: no cipher configuration. The server default may include weak ciphers for backward compatibility. One weak cipher in the list means: the attacker can force a downgrade to that cipher and break the encryption. Mozilla SSL Configuration Generator (ssl-config.mozilla.org) generates secure configurations for Nginx, Apache, and other servers. Copy-paste secure defaults, do not configure ciphers manually.

Complete HTTPS and TLS Rules Template

Consolidated rules for HTTPS and TLS.

• TLS 1.3 preferred, TLS 1.2 minimum — disable TLS 1.0 and 1.1
• HSTS: max-age=31536000; includeSubDomains; preload — submit to preload list
• Automated certificates: Let's Encrypt + certbot/Caddy — never manual management
• Monitor certificate expiration: alert at 30 days, critical at 7 days
• 301 redirect HTTP to HTTPS — one redirect to canonical URL, no chains
• Forward secrecy: ECDHE key exchange — compromised key cannot decrypt past traffic
• Mozilla SSL Config Generator for cipher suites — copy-paste secure defaults
• Test with ssllabs.com/ssltest — aim for A+ rating