Deep SSL/TLS Security Audits with SSLyze

Modern online systems live and die by the quality of their HTTPS (and other TLS-enabled) configurations. From e-commerce backends and APIs to email gateways and identity providers, the strength of your SSL/TLS setup dictates privacy, integrity, and resilience against a host of passive and active attacks. The good news is that you don’t have to guess whether your configuration is robust—tools like SSLyze can give you fast, repeatable, and deep visibility into your endpoints.

This guide explores how to conduct deep SSL/TLS security audits using SSLyze: what to test, how to interpret results, and practical steps to harden your configurations. You’ll also learn how to test online without installing anything and how to integrate audits into your operational workflows.

Why SSL/TLS Audits Matter More Than Ever

Attackers increasingly target misconfigurations and legacy crypto rather than zero-days. Common weaknesses include:

• Enabling deprecated protocols like SSLv3, TLS 1.0, or TLS 1.1.
• Offering weak ciphers (RC4, 3DES) or export-grade suites.
• Using old or mis-issued certificates, missing intermediates, or mismatched hostnames.
• Failing to enable features like OCSP stapling or strong session resumption.
• Leaving insecure renegotiation, compression, or heartbeat features that can be abused.
• Not providing modern TLS 1.3 support and efficient ciphers for performance and security.

An SSL/TLS audit surfaces these risks so you can fix them before they become incidents or compliance violations (e.g., PCI DSS requires disabling weak protocols and ciphers).

What Is SSLyze?

SSLyze is a fast, actively maintained TLS scanner that connects to a server and reports its SSL/TLS capabilities and vulnerabilities. It can:

• Enumerate supported protocol versions (TLS 1.0–1.3).
• Test cipher suites and preference ordering.
• Analyze certificates and chains (validity, strength, signature algorithms, SANs).
• Inspect features like session resumption, OCSP stapling, ALPN, compression, and renegotiation.
• Detect common misconfigurations and deprecated features.
• Negotiate TLS where STARTTLS is used (e.g., SMTP, IMAP), testing mail and other services.

It’s ideal for one-off audits, continuous monitoring, and pre-deployment checks.

Quick Start: Test Online Without Installing Anything

If you want to see results right away, run a scan online:

• Go to: https://www.web-psqc.com/security/sslyze
• Enter your domain or IP (you must own or be authorized to test).
• Review the results across certificates, protocols, ciphers, and features.

This is a convenient way to validate production endpoints or share results with stakeholders without CLI access.

Installing and Running SSLyze Locally

If you prefer local control or need automation, install SSLyze on your workstation or CI runner.

Installation

• Using pip:

  python3 -m pip install --upgrade sslyze
  

• Using pipx (isolated environment):

  pipx install sslyze
  

• Verify:

  sslyze --version
  

Note: Always keep SSLyze updated; TLS guidance evolves and newer features are detected in later releases.

Your First Scan

• Basic “regular” scan:

  sslyze --regular example.com
  

• Faster, high-level scan:

  sslyze --fast example.com
  

• Output to JSON for parsing:

  sslyze --regular --json_out=report.json example.com
  

• Specify host and port:

  sslyze --regular example.com:443
  

• SNI override (useful when scanning by IP or atypical host setups):

  sslyze --regular --sni=www.example.com 203.0.113.10:443
  

• STARTTLS (e.g., mail server on SMTP):

  sslyze --regular --starttls=smtp mail.example.com:25
  

Ethical reminder: Only scan systems you own or explicitly have permission to test.

Understanding What SSLyze Audits

SSLyze breaks down its audit into logical categories. Here’s what to look for and what to do about it.

Certificate and Chain Analysis

• Checks validity dates, expiration windows, and signature algorithms.
• Ensures SANs cover all hostnames.
• Reports key type and size (RSA/ECDSA) and strength.
• Highlights missing intermediates or chain-building issues.

Actionable advice:

• Use 2048-bit or larger RSA keys, or modern ECDSA keys.
• Ensure SANs include all domains; common SAN pitfalls cause breakage.
• Replace SHA-1-signed certs; prefer SHA-256+.
• Bundle intermediates; verify with an external resolver as local stores can mask issues.

Protocol Version Support

• Identifies supported TLS versions.
• Flags old versions (SSLv3, TLS 1.0, TLS 1.1).

Actionable advice:

• Disable TLS 1.0 and 1.1 completely unless a legacy requirement is documented and risk accepted.
• Ensure TLS 1.2 and 1.3 are enabled; prefer TLS 1.3 where clients support it.

Cipher Suites and Preference

• Enumerates server-accepted cipher suites.
• Reveals weak suites (RC4, 3DES) and whether the server enforces its preference order.

Actionable advice:

• For TLS 1.3, you don’t configure per-suite order; include:
  • TLS_AES_128_GCM_SHA256
  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256
• For TLS 1.2, prefer:
  • ECDHE-ECDSA-AES128-GCM-SHA256
  • ECDHE-RSA-AES128-GCM-SHA256
  • ECDHE-ECDSA-CHACHA20-POLY1305
  • ECDHE-RSA-CHACHA20-POLY1305
  • ECDHE-ECDSA-AES256-GCM-SHA384
  • ECDHE-RSA-AES256-GCM-SHA384
• Disable RC4, 3DES, MD5, NULL, EXPORT, and suites without forward secrecy.
• Enforce server-side cipher preference on servers that support it.

Key Exchange and Forward Secrecy

• Confirms use of ECDHE/DHE for forward secrecy.
• Detects small DH parameter sizes.

Actionable advice:

• Prefer ECDHE for performance and security.
• Ensure DH parameters are at least 2048 bits if you must support DHE.
• Avoid plain RSA key exchange for TLS 1.2.

Compression and Renegotiation

• Tests TLS-level compression (CRIME risk).
• Checks renegotiation, which historically led to vulnerabilities.

Actionable advice:

• Disable TLS compression entirely.
• Avoid client-initiated renegotiation; disable insecure renegotiation.

Heartbeat, ALPN, and OCSP Stapling

• Heartbeat frames historically linked to Heartbleed; most endpoints should not expose risky behavior.
• ALPN determines protocol negotiation (e.g., h2 vs http/1.1).
• OCSP stapling enhances revocation checking efficiency and privacy.

Actionable advice:

• Enable ALPN with http/1.1 and h2 if your app supports HTTP/2.
• Enable OCSP stapling; ensure responders are reliable, or configure caching/fallbacks.

Session Resumption

• Detects session IDs and tickets.
• Provides insight into performance and privacy trade-offs.

Actionable advice:

• Enable session tickets for performance but rotate ticket keys frequently (hours to a few days).
• For high-privacy contexts, consider disabling tickets or using short lifetimes.

A Deep-Dive SSLyze Auditing Playbook

Use this repeatable workflow to go beyond “just run a scan.”

1. Scope and Targets

• Identify FQDNs, IPs, and services (HTTPS, SMTP STARTTLS, IMAP STARTTLS, etc.).
• For CDNs and load balancers, test multiple edges if possible.

2. Baseline Scan

sslyze --regular --json_out=baseline.json www.example.com

• Review top-level findings and confirm basic hygiene: no TLS 1.0/1.1, no weak ciphers, valid certificate, OCSP stapling enabled.

3. Certificate and Chain Validation

sslyze --regular --sni=www.example.com 203.0.113.10:443

• This simulates routing by IP with proper SNI, catching SAN issues or misrouted virtual hosts.

4. STARTTLS Services

sslyze --regular --starttls=smtp mail.example.com:25
sslyze --regular --starttls=imap imap.example.com:143

• Validate email endpoints; mail is often overlooked and can be a compliance gap.

5. Focused Cipher and Protocol Checks

sslyze --regular api.example.com:443

• Confirm TLS 1.3 support. Check that TLS 1.2 ciphers are exclusively AEAD and forward-secret.

6. Performance Features

• Verify ALPN negotiation:
  • Expect h2 and http/1.1 where appropriate.
• Check session resumption and ticket behavior:
  • Confirm tickets and lifetimes match your privacy/performance decision.

7. Export and Share

sslyze --regular --json_out=team-report.json *.example.com

• Aggregate results for stakeholders or tickets. Use your SIEM or scripts to parse JSON.

8. Remediation and Re-Validation

• Apply configuration changes, then re-run SSLyze to ensure fixes stick across restarts/rollouts.

Sample Outputs and How to Interpret Them

Here’s what a condensed SSLyze snippet might look like and how to read it:

Hostname: www.example.com
Port: 443

Supported TLS versions:
 - TLS 1.2: YES
 - TLS 1.3: YES
 - TLS 1.1: NO
 - TLS 1.0: NO

TLS 1.3 cipher suites:
 - TLS_AES_128_GCM_SHA256
 - TLS_AES_256_GCM_SHA384
 - TLS_CHACHA20_POLY1305_SHA256

TLS 1.2 cipher suites (server preference order):
 1) ECDHE-RSA-AES128-GCM-SHA256
 2) ECDHE-RSA-CHACHA20-POLY1305
 3) ECDHE-RSA-AES256-GCM-SHA384

Certificate:
 - CN: www.example.com
 - SANs: www.example.com, example.com
 - Signature algorithm: sha256WithRSAEncryption
 - Key: RSA 2048 bits
 - Validity: Not expired
 - Chain issues: none

OCSP stapling: enabled
ALPN: h2, http/1.1
Compression: disabled
Renegotiation: secure renegotiation supported; client-initiated disabled
Session resumption: tickets enabled

What’s good:

• Only TLS 1.2 and 1.3 are enabled—modern.
• TLS 1.3 standard ciphers present.
• TLS 1.2 uses AEAD and forward secrecy; no legacy suites.
• Proper certificate with SAN coverage and a strong signature algorithm.
• OCSP stapling and ALPN configured.
• No compression or insecure renegotiation.

What might be tuned:

• If your audience includes very old clients and you’ve intentionally disabled TLS 1.0/1.1, document this for support teams to handle edge cases.
• Evaluate whether session ticket lifetime aligns with privacy requirements.

Advanced Techniques and Tips

Scan Multiple Targets at Once

If you have a long list of domains:

# targets.txt contains one host:port per line
sslyze --regular --targets_in=targets.txt --json_out=bulk.json

Tips:

• Rate-limit scans to avoid overwhelming shared infrastructure.
• Group targets by environment (prod/stage/dev) and service type.

Timeouts and Reliability

Network environments vary. Tune as needed:

• Increase timeouts for high-latency regions.
• Re-scan transient failures; treat them as potential availability signals worth investigating.

SNI and Virtual Hosting

When scanning IPs with multiple vhosts, use SNI:

sslyze --regular --sni=shop.example.com 203.0.113.50:443

This ensures you test the right certificate and cipher policy for that hostname.

STARTTLS Protocols

Many non-HTTPS services use TLS upgrades:

• SMTP: --starttls=smtp on port 25 or 587.
• IMAP: --starttls=imap on port 143.
• POP3 and FTP may also use STARTTLS in some deployments.

Auditing these services uncovers stale crypto that wasn’t addressed in web server hardening.

Hardening: From Findings to Fixes

Here’s how to address common SSLyze findings with practical configurations. Adjust for your environment, test changes in staging, and maintain compatibility with your client base.

Nginx (HTTPS)

Example secure baseline:

ssl_protocols TLSv1.2 TLSv1.3;

ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:
             ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:
             ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers on;

ssl_ecdh_curve X25519:secp256r1;
ssl_session_timeout 1d;
ssl_session_tickets on;
ssl_session_ticket_key current.key;
ssl_session_ticket_key previous.key;

ssl_stapling on;
ssl_stapling_verify on;
resolver 1.1.1.1 1.0.0.1 valid=300s;
resolver_timeout 5s;

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

# Enable HTTP/2
listen 443 ssl http2;

Notes:

• Rotate session ticket keys regularly.
• If you serve both ECDSA and RSA certs (dual-stack), modern clients will pick ECDSA for performance.
• HSTS is an HTTP header (not TLS) but complements TLS hardening for web traffic.

Apache httpd (mod_ssl)

SSLProtocol             TLSv1.2 TLSv1.3
SSLCipherSuite          TLSv1.2 HIGH:!aNULL:!MD5:!3DES:!RC4
SSLHonorCipherOrder     on

# For TLS 1.3, OpenSSL internally selects standard suites.

SSLUseStapling          on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCache        shmcb:/var/run/ocsp(128000)

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

HAProxy

ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 prefer-server-ciphers
ssl-default-bind-ciphers ECDHE+AESGCM:CHACHA20+ECDHE
ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

Postfix (SMTP STARTTLS)

smtpd_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_ciphers = high
smtpd_tls_eecdh_grade = strong
smtpd_tls_security_level = may
smtpd_tls_cert_file = /etc/ssl/certs/mail.crt
smtpd_tls_key_file = /etc/ssl/private/mail.key
smtpd_tls_OCSP_enable = yes

Always test with SSLyze’s STARTTLS scans after changes.

Interpreting Risk and Prioritizing Remediations

Use these heuristics to prioritize fixes:

• Critical/Immediate

  • Deprecated protocols enabled (SSLv3, TLS 1.0/1.1).
  • Non-forward-secret ciphers or export/NULL suites.
  • Broken certificate chain or expired certificate.
  • Insecure renegotiation allowed.

• High Priority

  • 3DES enabled (SWEET32 risk).
  • Missing OCSP stapling (especially for high-traffic sites).
  • Weak DH parameters (< 2048 bits).
  • Lack of TLS 1.3 on modern public-facing endpoints.

• Medium Priority

  • No HTTP/2 support (performance).
  • Session ticket keys not rotated regularly (privacy).
  • ALPN misconfiguration leading to suboptimal client behavior.

• Low Priority

  • Excess legacy compatibility options that are controlled and documented.

Building SSLyze into Your CI/CD and Ops

Make TLS health a continuous signal rather than a one-off project.

GitHub Actions Example

name: TLS Audit
on:
  schedule:
    - cron: '0 3 * * *'   # daily
  workflow_dispatch:

jobs:
  sslyze:
    runs-on: ubuntu-latest
    steps:
      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.x'
      - name: Install SSLyze
        run: pip install --upgrade sslyze
      - name: Run SSLyze
        run: |
          echo "www.example.com:443" > targets.txt
          echo "api.example.com:443" >> targets.txt
          sslyze --regular --targets_in=targets.txt --json_out=sslyze.json
      - name: Upload report
        uses: actions/upload-artifact@v4
        with:
          name: sslyze-report
          path: sslyze.json

Cron-Based Monitoring

#!/usr/bin/env bash
DATE=$(date +%F)
sslyze --fast --json_out=/var/reports/sslyze-$DATE.json $(cat /etc/sslyze/targets) || true

• Parse the JSON to flag regressions (e.g., weak ciphers reintroduced).
• Alert on certificate expirations well in advance (30/14/7 days).

Change Management

• Treat TLS changes like code: version-controlled config, peer review, and a rollback plan.
• After any SSL/TLS change, run SSLyze in staging and then production.

Common Pitfalls and How to Avoid Them

• Certificate Chains Work “On My Machine”: Your local trust store might include intermediates missing from the server chain. Always test externally.
• CDN or Load Balancer Drift: Backends may be hardened, but edge configuration lags. Scan the actual public endpoint, not only origin.
• SNI Mismatches: Scanning by IP without SNI can show the wrong certificate. Include --sni for accurate testing.
• Overly Aggressive Deprovisioning: Disabling TLS 1.2 too early will break many clients. Use telemetry to guide deprecations.
• Session Ticket Hygiene: Tickets on but keys never rotated undermines privacy. Automate rotation.
• OCSP Must-Staple Without Resilience: “Must-Staple” can backfire if responders are unavailable. Plan for caching and fail-open as appropriate.

Governance, Risk, and Compliance Mapping

• PCI DSS: Requires disabling weak protocols/ciphers and maintaining strong crypto. Use SSLyze reports as evidence during audits.
• HIPAA/HITRUST: Emphasize encrypted channels with strong algorithms. Document TLS posture and continuous monitoring.
• SOC 2: Demonstrate controls for secure transmission and configuration management; show automated scans and remediation workflows.

Keep a record of:

• Approved cipher lists and protocol versions.
• Change tickets tied to SSLyze findings.
• Evidence of continuous scanning and incident response for crypto-related issues.

A Practical Checklist for SSL/TLS Health

Use this as a quick, recurring review anchored by your SSLyze reports:

• Protocols

  • TLS 1.3 enabled
  • TLS 1.2 enabled
  • TLS 1.0/1.1 disabled

• Ciphers

  • Only AEAD suites on TLS 1.2
  • No RC4, 3DES, MD5, NULL, EXPORT
  • Forward secrecy enforced (ECDHE)

• Certificates

  • Valid, not near expiration
  • SANs cover all hostnames
  • Chain complete with intermediates
  • RSA ≥ 2048 bits or modern ECDSA

• Features

  • OCSP stapling enabled (and reliable)
  • ALPN includes h2 and http/1.1 where applicable
  • TLS compression disabled
  • Secure renegotiation only
  • Session resumption tuned; ticket keys rotated

• Operations

  • Scans integrated into CI/CD
  • Scheduled scans and alerting
  • Documented compatibility plan for legacy clients

Using the Online Scanner Strategically

For rapid validation or executive visibility, the online option is invaluable:

• Visit https://www.web-psqc.com/security/sslyze
• Run scans after configuration changes, certificate renewals, or before marketing events.
• Download or screenshot results for change advisory boards or incident postmortems.

Pair online checks with local, automated scans for full coverage.

Bringing It All Together

A mature SSL/TLS posture is equal parts configuration, continuous verification, and informed trade-offs. SSLyze gives you the deep, actionable visibility needed to:

• Confirm that TLS 1.2/1.3 are enforced with modern, forward-secret ciphers.
• Catch certificate issues before they cause outages.
• Validate performance optimizations like ALPN and session resumption.
• Harden mail and other STARTTLS services often left behind in security programs.
• Provide auditable evidence of strong cryptographic controls.

Whether you start with a quick online scan or automate audits across your fleet, the key is to make TLS health a repeatable habit. Run a scan today, fix what you find, and bake SSLyze into your operational rhythm—your users, auditors, and on-call engineers will thank you.