Skip to content

Latest commit

 

History

History
145 lines (108 loc) · 8.82 KB

File metadata and controls

145 lines (108 loc) · 8.82 KB

Mitigation Strategies Analysis for letsencrypt/boulder

  • Description:

    1. Identify Usage Patterns: Analyze expected legitimate usage. Determine the expected number of new accounts, authorizations, and certificates per unit of time.
    2. Configure rate-limits.json: Modify the config/rate-limits.json file within the Boulder installation.
    3. Set Account Limits: Define limits for newAccount in rate-limits.json, specifying the maximum number of new accounts per IP and per time interval. Example: {"key": "newAccount:ip:<IP>", "limit": 5, "window": "1h"}.
    4. Set Authorization Limits: Define limits for newAuthz in rate-limits.json, specifying limits per account and per IP. Example: {"key": "newAuthz:account:<ACCOUNT_ID>", "limit": 10, "window": "1h"}.
    5. Set Certificate Limits: Define limits for newOrder and finalizeOrder in rate-limits.json. Consider limits per account, per domain, and per IP. Example: {"key": "newOrder:account:<ACCOUNT_ID>:domain:<DOMAIN>", "limit": 2, "window": "24h"}.
    6. Set Pending Authorization Limits: Use authz limits in rate-limits.json to control pending authorizations.
    7. Set Failed Validation Limits: Use a combination of newAuthz limits and potentially custom logic within Boulder (requiring code modification) to limit failed validation attempts. This might involve modifying database interactions.
    8. Test Thoroughly: Test with legitimate and simulated abusive traffic.
    9. Monitor and Adjust: Continuously monitor rate limit logs (Boulder provides these) and adjust the limits in rate-limits.json as needed.
  • Threats Mitigated:

    • Denial of Service (DoS) via Excessive Requests (High Severity):
    • Brute-Force Attacks on Challenges (High Severity):
    • Account Enumeration (Medium Severity):
    • Resource Exhaustion (Medium Severity):
  • Impact:

    • DoS via Excessive Requests: Significantly reduced.
    • Brute-Force Attacks: Significantly reduced.
    • Account Enumeration: Reduced.
    • Resource Exhaustion: Reduced.
  • Currently Implemented:

    • Basic rate limits are configured in config/rate-limits.json.
  • Missing Implementation:

    • Fine-grained limits per domain.
    • Automated adjustment of rate limits.
    • Specific limits on failed validation attempts (beyond basic newAuthz limits) likely require code modifications within Boulder.
  • Description:

    1. Identify Required Challenge Types: Determine which ACME challenge types are necessary.
    2. Disable Unnecessary Challenges: In config/boulder.json, set the enabled flag to false for any unneeded challenge types.
    3. Configure Challenge Timeouts: In config/boulder.json, configure short, reasonable timeouts for challenges (e.g., dns01ChallengeTimeout, http01ChallengeTimeout).
    4. Test Thoroughly: Test each enabled challenge type; ensure disabled types are rejected.
  • Threats Mitigated:

    • Challenge Spoofing (High Severity):
    • Man-in-the-Middle (MITM) Attacks (High Severity): (Mitigated indirectly by reducing the attack surface)
    • DNS Hijacking (High Severity): (Mitigated indirectly by reducing the attack surface)
  • Impact:

    • Challenge Spoofing: Significantly reduced.
    • MITM Attacks: Reduced (indirectly).
    • DNS Hijacking: Reduced (indirectly).
  • Currently Implemented:

    • Only DNS-01 challenges are enabled in config/boulder.json.
  • Missing Implementation:

    • Comprehensive testing of all challenge timeout configurations.
  • Description:

    1. Configure Boulder: In config/boulder.json, ensure CAA checking is enabled (caaEnforcementEnabled: true).
    2. Test CAA Enforcement: Attempt to issue certificates for domains with and without appropriate CAA records.
    3. Monitor CAA-Related Logs: Review Boulder's logs for CAA-related errors.
  • Threats Mitigated:

    • Unauthorized Certificate Issuance (High Severity):
  • Impact:

    • Unauthorized Certificate Issuance: Significantly reduced.
  • Currently Implemented:

    • CAA enforcement is enabled in config/boulder.json.
  • Missing Implementation:

    • Comprehensive testing of CAA enforcement.
    • Automated monitoring of CAA-related logs (this might require custom scripting or SIEM integration, but the log generation is Boulder's responsibility).
  • Description:

    1. Establish a Schedule: Define a regular schedule for checking for Boulder updates.
    2. Monitor Boulder Releases: Actively monitor the Boulder GitHub repository (https://github.com/letsencrypt/boulder) for new releases and security advisories.
    3. Review Changelogs: Carefully review the changelogs for new releases to identify security-related fixes.
    4. Update Boulder: Update the Boulder installation to the latest stable release, following the official upgrade instructions.
    5. Test After Updates: Thoroughly test the Boulder instance after updating to ensure that the updates haven't introduced any regressions.
    6. Dependency Audits (within Boulder's context): While managing dependencies is a broader DevOps task, reviewing the impact of dependency vulnerabilities on Boulder's code is a Boulder-specific concern. This involves understanding how Boulder uses its dependencies.
  • Threats Mitigated:

    • Exploitation of Known Vulnerabilities in Boulder (High Severity):
    • Exploitation of Known Vulnerabilities in Dependencies (High Severity): (Indirectly, by understanding how Boulder uses those dependencies)
  • Impact:

    • Exploitation of Known Vulnerabilities: Significantly reduced.
  • Currently Implemented:

    • Ad-hoc updates are performed when critical vulnerabilities are announced.
  • Missing Implementation:

    • A formal schedule for checking for Boulder updates.
    • A documented process for reviewing changelogs and assessing the impact of updates.
  • Description:

    1. Enable Verbose Logging: Configure Boulder (via its configuration files) to log all relevant events, including successful and failed operations, errors, and warnings. Ensure sufficient detail is captured.
    2. Structured Logging: Configure Boulder to use structured logging (e.g., JSON format) if possible. This makes logs easier to parse.
    3. Review Log Configuration: Examine Boulder's logging configuration to ensure all relevant events are being logged. This may involve understanding Boulder's internal logging mechanisms.
  • Threats Mitigated:

    • Undetected Attacks (High Severity):
    • Difficult Incident Response (High Severity):
    • Lack of Visibility (Medium Severity):
  • Impact:

    • Undetected Attacks: Reduced (by providing the data for detection).
    • Difficult Incident Response: Improved (by providing the data for investigation).
    • Lack of Visibility: Improved (by providing detailed logs).
  • Currently Implemented:

    • Basic logging is enabled.
  • Missing Implementation:

    • Structured logging may not be fully utilized.
    • A thorough review of the logging configuration to ensure all relevant events are captured may be needed.
  • Description:

    1. Configure Boulder: Modify Boulder's configuration (config/boulder.json) to use the HSM for key storage and cryptographic operations. This involves specifying the PKCS#11 library path and slot/token information.
    2. Test HSM Integration: Thoroughly test Boulder with the HSM.
  • Threats Mitigated:

    • Private Key Compromise (Critical Severity):
  • Impact:

    • Private Key Compromise: Significantly reduced.
  • Currently Implemented:

    • Not implemented.
  • Missing Implementation:

    • All Boulder-specific configuration for HSM integration is missing.