Skip to content

Security: jerry7991/transproxy

Security

SECURITY.md

Security Policy

Supported Versions

Currently supported versions for security updates:

Version Supported
main

Reporting a Vulnerability

We take security seriously. If you discover a security vulnerability, please follow these steps:

🔒 For Security Issues

DO NOT create a public GitHub issue for security vulnerabilities.

Instead, please:

  1. Email: Send details to [security contact] (replace with actual email)
  2. Include:
    • Description of the vulnerability
    • Steps to reproduce
    • Potential impact
    • Suggested fix (if any)

⚡ For General Issues

For non-security issues, please use the GitHub issue tracker.

Security Considerations

Current Security Model

This transparent proxy operates with these security principles:

✅ What We Do Securely

  • No TLS MITM: HTTPS traffic is tunneled, not decrypted
  • SNI-only extraction: Only hostname extraction from TLS handshakes
  • Userspace operation: No kernel-level privileges required
  • Local-only: Designed for localhost/LAN operation

⚠️ Security Limitations

  • Plaintext HTTP: HTTP content is visible to the proxy
  • SNI logging: Destination hostnames are logged
  • pfctl rules: Require admin privileges to configure
  • DoS potential: No built-in rate limiting

Best Practices

For Users

  • Run proxy with minimal privileges
  • Monitor logs for suspicious activity
  • Use HTTPS whenever possible
  • Regularly update dependencies

For Developers

  • Validate all input data
  • Sanitize log output
  • Handle errors gracefully
  • Follow secure coding practices

Known Security Considerations

1. Information Disclosure

  • Risk: SNI hostnames visible in logs
  • Mitigation: Configure log rotation and access controls

2. Denial of Service

  • Risk: Memory exhaustion from large requests
  • Mitigation: Implement connection limits and timeouts

3. Privilege Escalation

  • Risk: pfctl rules require admin access
  • Mitigation: Use principle of least privilege

4. Man-in-the-Middle

  • Risk: HTTP traffic interception
  • Mitigation: This is intentional for filtering; use HTTPS for sensitive data

Reporting Timeline

We aim to:

  • Acknowledge reports within 48 hours
  • Provide initial assessment within 1 week
  • Release fixes for critical issues within 2 weeks
  • Coordinate disclosure responsibly

Responsible Disclosure

We follow responsible disclosure principles:

  • Work with researchers to understand issues
  • Provide credit for valid reports
  • Coordinate public disclosure timing
  • Focus on user safety first

Thank you for helping keep this project secure! 🔐

There aren’t any published security advisories