Mitigation Strategy: Strict Rate Limiting Configuration (Boulder-Specific)
-
Description:
- Identify Usage Patterns: Analyze expected legitimate usage. Determine the expected number of new accounts, authorizations, and certificates per unit of time.
- Configure
rate-limits.json
: Modify theconfig/rate-limits.json
file within the Boulder installation. - Set Account Limits: Define limits for
newAccount
inrate-limits.json
, specifying the maximum number of new accounts per IP and per time interval. Example:{"key": "newAccount:ip:<IP>", "limit": 5, "window": "1h"}
. - Set Authorization Limits: Define limits for
newAuthz
inrate-limits.json
, specifying limits per account and per IP. Example:{"key": "newAuthz:account:<ACCOUNT_ID>", "limit": 10, "window": "1h"}
. - Set Certificate Limits: Define limits for
newOrder
andfinalizeOrder
inrate-limits.json
. Consider limits per account, per domain, and per IP. Example:{"key": "newOrder:account:<ACCOUNT_ID>:domain:<DOMAIN>", "limit": 2, "window": "24h"}
. - Set Pending Authorization Limits: Use
authz
limits inrate-limits.json
to control pending authorizations. - 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. - Test Thoroughly: Test with legitimate and simulated abusive traffic.
- 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
.
- Basic rate limits are configured in
-
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.
Mitigation Strategy: Strict Validation Configuration (Boulder-Specific)
-
Description:
- Identify Required Challenge Types: Determine which ACME challenge types are necessary.
- Disable Unnecessary Challenges: In
config/boulder.json
, set theenabled
flag tofalse
for any unneeded challenge types. - Configure Challenge Timeouts: In
config/boulder.json
, configure short, reasonable timeouts for challenges (e.g.,dns01ChallengeTimeout
,http01ChallengeTimeout
). - 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
.
- Only DNS-01 challenges are enabled in
-
Missing Implementation:
- Comprehensive testing of all challenge timeout configurations.
Mitigation Strategy: CAA Enforcement (Boulder-Specific)
-
Description:
- Configure Boulder: In
config/boulder.json
, ensure CAA checking is enabled (caaEnforcementEnabled: true
). - Test CAA Enforcement: Attempt to issue certificates for domains with and without appropriate CAA records.
- Monitor CAA-Related Logs: Review Boulder's logs for CAA-related errors.
- Configure Boulder: In
-
Threats Mitigated:
- Unauthorized Certificate Issuance (High Severity):
-
Impact:
- Unauthorized Certificate Issuance: Significantly reduced.
-
Currently Implemented:
- CAA enforcement is enabled in
config/boulder.json
.
- CAA enforcement is enabled in
-
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).
Mitigation Strategy: Boulder Code and Dependency Updates
-
Description:
- Establish a Schedule: Define a regular schedule for checking for Boulder updates.
- Monitor Boulder Releases: Actively monitor the Boulder GitHub repository (https://github.com/letsencrypt/boulder) for new releases and security advisories.
- Review Changelogs: Carefully review the changelogs for new releases to identify security-related fixes.
- Update Boulder: Update the Boulder installation to the latest stable release, following the official upgrade instructions.
- Test After Updates: Thoroughly test the Boulder instance after updating to ensure that the updates haven't introduced any regressions.
- 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.
Mitigation Strategy: Detailed Logging and Auditing (Boulder's Logging Configuration)
-
Description:
- 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.
- Structured Logging: Configure Boulder to use structured logging (e.g., JSON format) if possible. This makes logs easier to parse.
- 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.
Mitigation Strategy: Hardware Security Module (HSM) Integration (Boulder Configuration)
-
Description:
- 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. - Test HSM Integration: Thoroughly test Boulder with the HSM.
- Configure Boulder: Modify Boulder's configuration (
-
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.