SSL Certificates

SSL Scanning

Overview of SSL Certificate Scanning

As part of our comprehensive asset discovery and vulnerability assessment process, we scan your organization's digital assets to identify and analyze SSL/TLS certificates. This process helps ensure the security and compliance of your web services.

How We Scan for SSL Certificates

  1. Asset Discovery:
    • We start by identifying all domains and subdomains associated with your organization.
    • This includes public-facing web servers, mail servers, and other services that use SSL/TLS.
  2. Port Scanning:
    • We scan common SSL/TLS ports (e.g., 443 for HTTPS, 25 for SMTP) across all identified IP addresses.
  3. SSL/TLS Handshake:
    • For each responsive port, we initiate an SSL/TLS handshake to retrieve the certificate information.
  4. Certificate Chain Analysis:
    • We analyze the entire certificate chain, including root and intermediate certificates.
  5. Certificate Data Extraction:
    • We extract key information from each certificate, including:
      • Subject (domain name)
      • Issuer (Certificate Authority)
      • Valid from/to dates
      • Key size and algorithm
      • Serial number

What We Look For

  1. Certificate Expiry:
    • We identify certificates that are expired or nearing expiration (e.g., within 30 days).
  2. Weak Cryptography:
    • We flag certificates using outdated algorithms (e.g., SHA-1) or insufficient key sizes.
  3. Hostname Mismatch:
    • We check if the certificate's subject matches the hostname it's served from.
  4. Self-Signed Certificates:
    • We identify self-signed certificates, which are generally not trusted for public-facing services.
  5. Revoked Certificates:
    • We check certificate revocation status using CRL and OCSP.
  6. Vulnerable SSL/TLS Versions:
    • We detect if servers support outdated and vulnerable SSL/TLS versions (e.g., SSL 3.0, TLS 1.0).
  7. Certificate Transparency:
    • We verify if certificates are logged in Certificate Transparency logs, as required by many browsers.
  8. Wild Card Certificates:
    • We identify and flag the use of wildcard certificates, which can pose additional risks if compromised.

Reporting

Our scanning process generates a comprehensive report that includes:

Risks Associated with SSL Certificate Issues

When our scanning process identifies problems with SSL certificates across your organization's assets, it's crucial to understand the associated risks. These issues can have significant impacts on your security, user trust, and operational continuity.

  1. Expired Certificates
    • Risk: Immediate loss of trusted HTTPS connections
    • Impact:
      • Users face security warnings, leading to loss of trust and potential traffic decline
      • Disruption of business operations and services
      • Potential data exposure if users proceed despite warnings
  2. Certificates Nearing Expiration
    • Risk: Potential for sudden service disruption if not renewed in time
    • Impact:
      • Operational scramble to renew certificates
      • Possible downtime if renewal process isn't smooth
  3. Weak Cryptography
    • Risk: Increased vulnerability to cryptographic attacks
    • Impact:
      • Potential for data breaches and information theft
      • Non-compliance with industry security standards (e.g., PCI DSS)
  4. Hostname Mismatch
    • Risk: Security warnings in browsers and potential for man-in-the-middle attacks
    • Impact:
      • Loss of user trust
      • Increased vulnerability to phishing and impersonation attacks
  5. Self-Signed Certificates
    • Risk: Lack of third-party validation and user trust issues
    • Impact:
      • Security warnings in browsers, deterring users
      • Increased susceptibility to man-in-the-middle attacks
  6. Revoked Certificates
    • Risk: Continued use of certificates that have been invalidated due to compromise or other issues
    • Impact:
      • Potential for using certificates that are known to be insecure
      • Legal and compliance risks
  7. Vulnerable SSL/TLS Versions
    • Risk: Exposure to known security vulnerabilities in outdated protocols
    • Impact:
      • Increased risk of data interception and manipulation
      • Non-compliance with security standards and regulations
  8. Missing Certificate Transparency
    • Risk: Reduced ability to detect misissued certificates
    • Impact:
      • Potential for undetected phishing sites using valid certificates for your domain
      • Reduced trust from modern browsers that require CT compliance
  9. Wildcard Certificate Overuse
    • Risk: Broad impact if a single certificate is compromised
    • Impact:
      • Potential for widespread security issues across multiple subdomains
      • Increased difficulty in managing and revoking certificates granularly
  10. Incomplete Certificate Chains
    • Risk: Trust issues with certain clients or platforms
    • Impact:
      • Potential service disruptions for some users
      • Reduced security due to improper certificate validation
  11. Key Compromise
    • Risk: Unauthorized access to the private key associated with the certificate
    • Impact:
      • Potential for impersonation and data interception
      • Need for immediate certificate revocation and replacement
  12. Insufficient Key Size
    • Risk: Increased vulnerability to brute-force attacks
    • Impact:
      • Potential for future decryption of intercepted data as computational power increases
      • Non-compliance with current security best practices

Understanding these risks is crucial for prioritizing SSL certificate management and maintaining a robust security posture. Prompt attention to identified issues can prevent service disruptions, maintain user trust, and protect against potential security breaches.

Mitigation Plan for SSL Certificate Issues

Based on the SSL certificate issues identified during our asset scanning process, we recommend the following mitigation strategies to enhance your organization's security posture and maintain smooth operations.

  1. Implement Certificate Lifecycle Management
    • Deploy an automated certificate management system to track expiration dates.
    • Set up alerts for certificates nearing expiration (e.g., 30, 14, and 7 days before expiry).
    • Automate the renewal process where possible to prevent unexpected expirations.
  2. Standardize on Strong Cryptography
    • Use a minimum of 2048-bit RSA keys or 256-bit ECC keys for all certificates.
    • Employ SHA-256 or stronger for certificate signatures.
    • Phase out any remaining SHA-1 or MD5 based certificates immediately.
  3. Ensure Proper Hostname Matching
    • Conduct regular audits to ensure all certificates match the hostnames they're served from.
    • Implement a review process for new certificate requests to verify correct domain names.
    • Use Subject Alternative Name (SAN) certificates for multi-domain coverage instead of wildcards where possible.
  4. Eliminate Self-Signed Certificates
    • Replace all self-signed certificates on production and public-facing systems with CA-issued certificates.
    • If self-signed certificates are necessary for internal purposes, implement a proper internal CA infrastructure.
  5. Monitor Certificate Revocation
    • Implement automated checking of Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP).
    • Establish a process for immediate replacement of revoked certificates.
  6. Upgrade SSL/TLS Protocols
    • Disable SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1 on all servers.
    • Configure servers to use TLS 1.2 or TLS 1.3 exclusively.
    • Regularly check for and apply security updates to SSL/TLS libraries (e.g., OpenSSL).
  7. Ensure Certificate Transparency Compliance
    • Use only certificates that are logged in Certificate Transparency logs.
    • Implement CT monitoring to detect unauthorized certificate issuance for your domains.
  8. Limit and Secure Wildcard Certificates
    • Restrict the use of wildcard certificates to specific, necessary cases.
    • Implement extra security measures for wildcard certificate private keys, such as hardware security modules (HSMs).
    • Consider splitting wildcard certificates into multiple specific certificates where feasible.
  9. Verify Complete Certificate Chains
    • Ensure all intermediate certificates are properly installed on servers.
    • Regularly test certificate chain validity using online SSL checkers or internal tools.
  10. Enhance Private Key Security
    • Store private keys in hardware security modules (HSMs) where possible.
    • Implement strict access controls and logging for systems with access to private keys.
    • Establish a process for immediate certificate replacement if key compromise is suspected.
  11. Regular Security Assessments
    • Conduct periodic (e.g., quarterly) scans of all assets to identify SSL/TLS issues.
    • Perform annual penetration testing that includes assessment of SSL/TLS configurations.
  12. Establish a Certificate Policy
    • Develop and enforce an organizational policy for certificate issuance, use, and management.
    • Include guidelines for approved CAs, key lengths, and certificate types.
  13. Employee Training and Awareness
    • Provide training to IT staff on proper SSL/TLS configuration and certificate management.
    • Raise awareness among developers about the importance of proper certificate usage in applications.
  14. Incident Response Planning
    • Include SSL/TLS-related scenarios in your incident response plan.
    • Conduct drills to practice rapid response to certificate compromises or unexpected expirations.
  15. Vendor Management
    • Establish requirements for proper SSL/TLS usage in contracts with third-party service providers.
    • Regularly audit vendor compliance with these requirements.

By implementing these mitigation strategies, your organization can significantly reduce the risks associated with SSL certificate issues, enhance overall security, and ensure uninterrupted service for your users. Regular review and updating of these practices will help maintain a robust SSL/TLS security posture in the face of evolving threats and standards.

Post-Quantum Vulnerable

Documentation: Post-Quantum Vulnerable SSL and Recommended Countermeasures

Overview

The rise of quantum computing poses a direct threat to traditional cryptographic algorithms used in SSL/TLS, such as RSA, ECDSA, and Elliptic Curve Diffie-Hellman (ECDH). These algorithms rely on problems (like integer factorization and discrete logarithms) that quantum computers can solve efficiently using Shor’s algorithm, rendering current SSL/TLS protocols post-quantum vulnerable.

This document outlines how SSL/TLS can be vulnerable in a post-quantum context and provides recommendations for post-quantum secure alternatives.

⚠️ Post-Quantum Vulnerabilities in SSL/TLS

1. Key Exchange Vulnerabilities

Traditional key exchange mechanisms such as:

These are vulnerable because quantum computers can derive the private keys from intercepted public data using Shor’s algorithm.

2. Digital Signature Vulnerabilities

🔐 Modern Post-Quantum Safe Ciphers (Hybrid and Pure)

To mitigate quantum risks, TLS implementations must transition to quantum-resistant cryptographic algorithms. These can be:

Type Algorithm Description
Key Encapsulation Kyber (Kyber-512, Kyber-768, Kyber-1024) Lattice-based; standardized as ML-KEM
Signatures Dilithium (Dilithium2, Dilithium3, Dilithium5) Lattice-based digital signature
  Falcon Compact, lattice-based signature
  SPHINCS+ Hash-based signature; conservative fallback

As of today, post-quantum cryptography is often integrated through TLS hybrid key exchanges via extensions like [x25519+kyber512] or via Open Quantum Safe (OQS) libraries.

Example Hybrid Cipher Suites (using NIST PQC algorithms):

  1. TLS_AES_256_GCM_SHA384 + X25519+Kyber768

  2. TLS_CHACHA20_POLY1305_SHA256 + Kyber512

  3. TLS_AES_128_GCM_SHA256 + ECDHE + Kyber1024

⚠️ These are not yet formal cipher suite names; they represent the key exchange combinations used in hybrid TLS libraries like BoringSSL, OpenSSL with OQS, and AWS s2n-tls.

🧰 Implementation Options

Libraries supporting Post-Quantum TLS:

🔄 Migration Strategy

  1. Evaluate inventory of TLS endpoints

    • Identify services using RSA/ECDSA and vulnerable ciphers.

  2. Use hybrid schemes first

    • Interoperable with legacy clients while offering PQC protection.

  3. Enable PQC cipher suites in controlled environments

    • Internal APIs, backend services, etc.

  4. Monitor NIST and IETF standards

    • Stay aligned with official PQC cipher standardization efforts.

  5. Implement TLS 1.3

    • Required for most PQC-ready key exchange implementations.

🚫 Ciphers to Deprecate Immediately

Avoid these in future-proof systems:

These are based on RSA/ECDSA and vulnerable to quantum attacks.

NIST PQC Standardization Milestones

Year Milestone
2022 NIST announced finalists (Kyber, Dilithium, etc.)
2024 Final standards (ML-KEM for Kyber, ML-DSA for Dilithium)
2025 Adoption into commercial systems and TLS libraries

Summary