Skip to content

Latest commit

 

History

History
56 lines (49 loc) · 4.63 KB

threat-modeling.md

File metadata and controls

56 lines (49 loc) · 4.63 KB

Threat Model Analysis for filosottile/mkcert

Threat: Root CA Private Key Compromise

  • Description: An attacker gains unauthorized access to the mkcert root CA private key. This could occur through:
    • Direct access to a developer's machine (physical theft, malware, remote access exploit).
    • Accidental exposure of the key (committing to a public repository, insecure storage).
    • Social engineering attacks targeting developers.
  • Impact: The attacker can issue trusted certificates for any domain, enabling widespread Man-in-the-Middle (MITM) attacks against any system or browser trusting the compromised root CA. This allows interception and modification of HTTPS traffic, potentially exposing sensitive data (credentials, personal information, etc.). The attacker could also impersonate legitimate services.
  • Affected mkcert Component: The mkcert root CA private key file (typically located in a directory determined by mkcert -CAROOT). This is the core secret generated and managed by mkcert.
  • Risk Severity: Critical
  • Mitigation Strategies:
    • Never commit the root CA private key to version control. Use .gitignore or similar mechanisms.
    • Restrict physical and remote access to developer machines. Enforce strong passwords, multi-factor authentication, and the principle of least privilege.
    • Regularly audit systems for unauthorized software or changes.
    • Consider using a dedicated, isolated machine for certificate generation (if feasible).
    • Use a separate mkcert root CA for each developer/team (if feasible).
    • Educate developers on the risks and the importance of protecting the root CA.
    • Consider using short-lived certificates and rotating the root CA periodically (adds complexity).

Threat: Accidental Exposure of Root CA

  • Description: The mkcert root CA private key is accidentally made public or accessible to unauthorized individuals. This often happens through:
    • Committing the file to a public or insufficiently secured source code repository (e.g., GitHub, GitLab).
    • Storing the file on an insecurely configured shared drive or cloud storage.
    • Sending the file via insecure channels (e.g., unencrypted email).
  • Impact: Similar to direct compromise, an attacker who obtains the exposed key can perform MITM attacks. The scope of the attack depends on where the root CA is trusted.
  • Affected mkcert Component: The mkcert root CA private key file.
  • Risk Severity: High
  • Mitigation Strategies:
    • Use .gitignore (or equivalent) to prevent committing the root CA directory. Be very specific.
    • Implement pre-commit hooks to scan for potential secrets before committing. Use tools like git-secrets or trufflehog.
    • Regularly audit repositories for accidentally committed secrets.
    • Educate developers on secure coding practices and the importance of not committing sensitive information.
    • Use secure file sharing and communication methods.

Threat: Compromised mkcert Binary

  • Description: An attacker replaces the legitimate mkcert binary with a malicious version. This could happen through:
    • A supply chain attack targeting the mkcert project itself (unlikely, but possible).
    • Compromising the developer's machine and replacing the binary directly.
    • Tricking the developer into downloading a malicious version from an unofficial source.
  • Impact: The malicious binary could:
    • Install a compromised root CA, allowing the attacker to perform MITM attacks.
    • Generate certificates that are backdoored or contain malicious code.
    • Steal existing certificates and private keys.
    • Exfiltrate sensitive information from the developer's machine.
  • Affected mkcert Component: The mkcert executable binary itself.
  • Risk Severity: High
  • Mitigation Strategies:
    • Download mkcert only from the official GitHub repository.
    • Verify the downloaded binary's checksum against the official release (currently a missing feature; request it from the maintainer). This is a crucial step to detect tampering.
    • Use a software composition analysis (SCA) tool to monitor for vulnerabilities (though mkcert has few dependencies).
    • Restrict write access to the directory where mkcert is installed.
    • Employ endpoint detection and response (EDR) solutions to monitor for suspicious binary behavior.