Skip to content

Latest commit

 

History

History
88 lines (69 loc) · 5.86 KB

mitigations.md

File metadata and controls

88 lines (69 loc) · 5.86 KB

Mitigation Strategies Analysis for filosottile/mkcert

Mitigation Strategy: Protect the Root CA Private Key (CAROOT)

  • Description:

    1. Identify CAROOT: Run mkcert -CAROOT in your terminal to determine the location of the CAROOT directory. This directory is created by mkcert and contains the critical root CA private key and certificate.
    2. Restrict File Permissions: Use your operating system's file permission system (e.g., chmod on Linux/macOS, file properties on Windows) to restrict access to the CAROOT directory immediately after running mkcert -install. Only the user who ran mkcert -install (and potentially other administrators who need to generate certificates) should have read/write access. Example (Linux/macOS): 
      chmod 700 $(mkcert -CAROOT)  # Only the owner has read/write/execute
    3. Individual mkcert Installations (Shared Environments): If using a shared development environment, strongly encourage (or enforce) each developer to run their own mkcert installation. Each developer should:
      • Run mkcert -install under their own user account.
      • Be responsible for protecting their own CAROOT directory. This isolates compromises.
    4. Root CA Rotation: Periodically create a new root CA using mkcert:
      • Backup (Optional): Securely back up the old CAROOT directory if you need to retain old certificates.
      • Delete: Delete the entire existing CAROOT directory.
      • Reinstall: Run mkcert -install to generate a new root CA and install it.
      • Regenerate: Use the new root CA to regenerate all necessary development certificates.
      • Communicate: Inform the team about the new root CA (if using a shared environment). They may need to re-trust the new CA.

  • Threats Mitigated:

    • Threat: Root CA Private Key Compromise.
      • Severity: Critical.
    • Threat: Unauthorized Certificate Issuance.
      • Severity: High.

  • Impact:

    • Root CA Private Key Compromise: Risk reduced from Critical to Low (if all steps are followed).
    • Unauthorized Certificate Issuance: Risk reduced from High to Low.

  • Currently Implemented:

    • File Permissions: Implemented on the development server using chmod 700.
    • Individual Installations: Not implemented.
    • Root CA Rotation: Not implemented.

  • Missing Implementation:

    • Individual Installations: All developers share the same mkcert installation on the development server.
    • Root CA Rotation: No formal process or schedule for root CA rotation is in place.

Mitigation Strategy: Limit Trust Store Installation

  • Description:

    1. Understand Installation: Before running mkcert -install, be aware of which trust stores (system, browser, specific applications) mkcert will modify. This behavior can vary slightly depending on the operating system and mkcert version.
    2. Selective Installation (Recommended): Instead of using mkcert -install for all developers, provide instructions for manually trusting the root CA only in the specific browsers or applications where it's absolutely necessary for development. This avoids system-wide trust. The manual trust process is not directly part of mkcert, but it's a crucial mitigation related to how mkcert's output is used.
    3. Uninstall Instructions: Provide clear instructions on how to remove the CA generated by mkcert.

  • Threats Mitigated:

    • Threat: Widespread Trust of Development CA.
      • Severity: High.
    • Threat: Unintentional Trust of Malicious Certificates.
      • Severity: Medium.

  • Impact:

    • Widespread Trust of Development CA: Risk reduced from High to Medium (or Low, with very limited installation).
    • Unintentional Trust of Malicious Certificates: Risk reduced from Medium to Low.

  • Currently Implemented:

    • Selective Installation: Partially implemented. Some developers use mkcert -install, others manually trust.
    • Uninstall Instructions: Not implemented.

  • Missing Implementation:

    • Selective Installation: Need to standardize on manual trust and provide clear instructions.
    • Uninstall Instructions: No documentation exists for uninstalling the root CA.

Mitigation Strategy: Use Distinct Naming with mkcert

  • Description:

    1. Consistent Prefixing: When generating certificates with mkcert, always use a clear and consistent prefix (or other distinguishing characteristic) in the hostname. This makes it visually obvious that the certificate is for development. Examples: 
      mkcert dev-api.example.com
mkcert local-myproject.test
mkcert john-dev.example.org
    2. Avoid Production-Like Names: Never use hostnames that resemble your production domains without a clear development-related prefix. For example, avoid using mkcert api.example.com if api.example.com is your production API endpoint.

  • Threats Mitigated:

    • Threat: Accidental Deployment of Development Certificates to Production.
      • Severity: Medium.

  • Impact:

    • Accidental Deployment of Development Certificates to Production: Risk reduced from Medium to Low (especially when combined with other mitigations like deployment pipeline checks).

  • Currently Implemented:

    • Naming Conventions: Partially implemented. Some developers use prefixes, others don't.

  • Missing Implementation:

    • Naming Conventions: Need to enforce a consistent naming convention across the team.