GoTLS Proxy is a hardened TLS reverse proxy designed for browser trust scoring, bot mitigation, and traffic filtering.
It performs deep TLS and HTTP inspection, integrates a real browser renderer (Puppeteer) for behavioral validation, and routes traffic based on a stateless trust scoring system.
The system is built with security-first principles:
- Dedicated non-root service user
- Strict filesystem permissions
- Loopback-isolated internal services
- Systemd hardening
The project evolved through multiple iterations.
This diagram illustrates the original trust-flow architecture developed during the first implementation.
After implementing production deployment, Redis-backed IP banning, automated TLS certificate synchronization, Linux service hardening, and observability, the architecture evolved into the following production-ready design.
Client
β
TLS Edge (GoTLS Proxy :443)
β
Stateless Trust Engine
β
Node Renderer (127.0.0.1:9222)
β
Internal Renderer Backend (127.0.0.1:4444)
β
Main Backend (127.0.0.1:4443)
- JA3-based TLS fingerprint extraction
- ALPN + cipher behavior validation
- Early handshake filtering (pre-HTTP)
Each request is evaluated independently using:
- TLS fingerprint consistency (JA3)
- User-Agent validation
- Header structure & coherence
- Request behavior patterns (per-request only)
No session tracking (yet) β fully stateless design.
-
Headless Chromium via Puppeteer
-
Executes JavaScript
-
Generates real browser signals:
- navigator properties
- canvas interaction
- timing behavior
Used to:
- Verify suspicious clients
- Boost trust scoring confidence
- Trusted traffic β forwarded to backend
- Untrusted traffic β rejected (403 Forbidden)
Supports:
- Header forwarding
- Real client IP visibility
- Debug inspection via temporary backend
A built-in testing backend provides:
- Request headers
- Cookies
- Client IP
- Method + path
Used to:
- Validate proxy routing
- Debug trust decisions
- Confirm no 502 errors
GoTLS runs as a non-root service user (SERVICE_USER).
Production TLS certificates are stored in:
/etc/gotls-proxy/certs/
Files:
fullchain.pemprivkey.pem
GoTLS reads certificates from its own certificate directory rather than directly from the Let's Encrypt directory.
Certificate synchronization is fully automated through the Certbot deploy hook located at:
/etc/letsencrypt/renewal-hooks/deploy/reload_gotls_proxy.sh
During each successful renewal:
- Renewed certificates are copied into the GoTLS certificate directory.
- Ownership and permissions are applied for the
SERVICE_USERservice user. - The GoTLS service is restarted so the new certificate is served immediately.
- Certbot (webroot mode)
- Automatic certificate renewal
- Deploy hook automatically synchronizes renewed certificates
- GoTLS service automatically restarts after certificate synchronization
After each successful Let's Encrypt renewal, the deploy hook:
- Copies the renewed certificate into
/etc/gotls-proxy/certs/ - Applies secure ownership and permissions for the
SERVICE_USERservice user - Restarts the GoTLS service so the latest certificate is served immediately
This allows GoTLS to run as a non-root service while always serving the latest TLS certificate without manual intervention.
-
Structured logs via journald
-
Application log:
- /var/log/gotls-proxy/gotls.log
-
Trust scoring output:
- client IP
- score
- decision (allowed / filtered)
-
Rate-limit events
-
Renderer failures
-
Proxy decisions
Shows all production services running successfully.
Demonstrates successful TLS handshake and certificate verification.
Illustrates observable TLS handshake failures.
Shows trust threshold enforcement.
Demonstrates Prometheus metrics exposure.
Illustrates successful request routing.
A short walkthrough demonstrating:
- system startup
- TLS validation
- trust scoring
- metrics
- backend routing
- observability
Video:
Complete engineering walkthrough covering:
- architecture
- Linux deployment
- renderer integration
- metrics
- debugging
- observability
- production design decisions
Video:
Detailed engineering documentation is available under:
- docs/architecture/
- docs/testing/
- docs/security/
- docs/deployment/
- docs/reports/
These documents describe architecture evolution, testing methodology, deployment procedures, security decisions, and project reports.
/opt/gotls-proxy/
βββ main.go
βββ verify_challenge.go
βββ go.mod
βββ botpage.html
βββ README.md
βββ .env
βββ .env.example
βββ .gitignore
βββ config.example.json
β
βββ node_renderer/
β βββ package.json
β βββ renderer.js
β
βββ backend/
β βββ renderer_page.html
β
βββ internal_renderer_backend/
β βββ main.go
β
βββ temp_backend/
β βββ server.go
β
βββ scripts/
β βββ install_deps.sh
β βββ build_and_install.sh
β
βββ systemd/
β βββ gotls-proxy.service.example
β βββ node-renderer.service.example
β βββ internal-renderer-backend.service.example
/etc/gotls-proxy/
βββ config.json
βββ certs/
βββ fullchain.pem
βββ privkey.pem
/etc/systemd/system/
βββ gotls-proxy.service
βββ node-renderer.service
βββ internal-renderer-backend.service
/etc/letsencrypt/renewal-hooks/deploy/
βββ reload_gotls_proxy.sh
/etc/logrotate.d/
βββ gotls-proxy
/etc/prometheus/rules/
βββ gotls.rules.yml
/var/lib/gotls-proxy/
βββ acme-challenges/
/var/log/gotls-proxy/
βββ gotls.log
gotls-proxyβ TLS edge + trust enginenode-rendererβ Puppeteer browser engineinternal-renderer-backendβ renderer-only backend
- No root runtime
- Loopback-only internal services
- Strict filesystem permissions
-
Dedicated non-login service account (SERVICE_USER)
-
Non-root execution model
-
Loopback-isolated internal services
-
systemd hardening:
- ProtectHome=true
- PrivateTmp=true
- NoNewPrivileges=true
-
Strict filesystem permissions:
- configs β 750
- runtime directories β 700
-
Redis trust persistence
-
UFW firewall protection
-
Automated TLS certificate deployment
Clients exceeding configured trust or abuse thresholds are automatically placed into temporary Redis-backed IP bans.
Current behavior:
- Automatic ban creation
- Configurable TTL (automatic expiration)
- Trust threshold enforcement
- Redis persistence during active bans
redis-cli KEYS "banned:*"
redis-cli TTL banned:<ip>Ubuntu UFW protects the host using a default-deny inbound policy.
Only the following inbound services are permitted:
- SSH (22/TCP)
- HTTP (80/TCP)
- HTTPS (443/TCP)
All other inbound ports remain blocked unless explicitly allowed.
Certificates are issued using:
certbot certonly --webroot \
-w /var/lib/gotls-proxy/acme-challenges \
-d northgateworkspace.com
Auto-reload handled via deploy hook:
/etc/letsencrypt/renewal-hooks/deploy/reload_gotls_proxy.sh
sudo systemctl status gotls-proxy node-renderer internal-renderer-backend --no-pager
openssl x509 -in /etc/letsencrypt/live/northgateworkspace.com/fullchain.pem -noout -dates
curl -vk https://northgateworkspace.com 2>&1 | grep "expire date"
curl -k https://northgateworkspace.com/
curl http://127.0.0.1:9222/health
curl http://127.0.0.1:9100/metrics | grep gotls_requests_total
redis-cli KEYS "banned:*"
redis-cli TTL banned:<ip>
journalctl -u gotls-proxy --since today | grep '"trusted client allowed"'
journalctl -u gotls-proxy --since today | grep '"blocked by trust threshold"'
journalctl -u gotls-proxy --since today | grep "TLS handshake error"
journalctl -u gotls-proxy -f
journalctl -u node-renderer -f
journalctl -u internal-renderer-backend -f
- TLS reverse proxy routing
- Stateless trust scoring
- Browser-based verification (Puppeteer)
- Debug backend inspection
β TLS fingerprint filtering (JA3/JA4)
β Stateless trust engine
β Redis-backed IP banning
β Reverse proxy routing
β Browser-based verification (Puppeteer)
β Automated TLS certificate synchronization
β Metrics and observability endpoints
β Linux service hardening
β Non-root service execution
β UFW host firewall integration
β Production systemd deployment
- No session tracking (stateless only)
- No cookie continuity scoring
- No advanced HTTP WAF rule engine (basic request filtering only)
- OAuth 2.0 authentication
- OpenID Connect (OIDC)
- JWT access tokens
- Refresh token rotation
- Role-Based Access Control (RBAC)
- Secure session management
- OWASP Top 10 protections
- OWASP API Security Top 10 protections
- API Gateway integration
- Cookie continuity scoring
- Trust persistence engine
- Redis session tracking
- Browser behavior reuse analysis
- Fingerprint history tracking
- IP reputation persistence
- Trust accumulation logic
- Challenge-solving memory
- Behavioral timing analysis
- Advanced anomaly detection
- SOCKS5 outbound proxy support
- Proxy authentication
- Proxy health monitoring
- Automatic proxy failover
- Exit IP reputation tracking
- Outbound routing policies
- Dynamic UFW rule management
- Automatic IP blocking
- Automatic IP unblocking
- Redis-to-UFW synchronization
- Firewall rule synchronization
- Firewall event logging
- Application-driven firewall decisions
- SQL Injection detection
- Cross-Site Scripting detection
- Path Traversal detection
- Remote/Local File Inclusion detection
- Command Injection detection
- Server-Side Request Forgery detection
- Malicious file upload detection
- HTTP request normalization
- Header validation
- Request body inspection
- Rule-based attack signatures
- Custom rule engine
- Threat intelligence integration
- PostgreSQL integration
- Persistent trust database
- Reputation storage
- Audit logging
- Vulnerability management workflow
- Incident response procedures
- Enhanced monitoring and alerting
- Grafana monitoring dashboards
- Docker containerization
- CI/CD pipelines
- AWS deployment
- Infrastructure as Code
- Deployment automation
- Secure Business Platform integration
- Identity-aware reverse proxy
- OAuth/OIDC trust propagation
- JWT validation support
- Business application request protection
- API trust enforcement
- Authenticated session inspection
- Audit event forwarding
This project demonstrates:
- Real-world edge security engineering
- TLS fingerprinting and traffic filtering
- Reverse proxy architecture design
- Browser-based verification techniques
- Secure Linux service isolation
- Production observability and metrics
- Infrastructure hardening practices
- Practical bot mitigation techniques
This system was built iteratively with a strong focus on:
- Security correctness
- Operational observability
- Production-grade deployment practices
- Clean architectural separation
- Incremental capability evolution
Each component can be tested independently, making the system highly maintainable, extensible, and suitable for further engineering phases including:
- Docker deployment
- CI/CD integration
- Stateful trust persistence
- Full HTTP WAF capabilities
Copyright Β© 2026 Alexander Egbuna.
This repository is provided for portfolio and evaluation purposes only.
Permission is granted to view, clone, and execute the project for educational and evaluation purposes.
Modification, redistribution, commercialization, or incorporation into other projects is prohibited without prior written authorization from the author.












