A CONNECT request is an HTTP method used by a client to ask a proxy to open a TCP tunnel to a target host and port. It is most often used for HTTPS through an HTTP proxy, where the proxy forwards encrypted traffic after the tunnel is established and no longer reads the payload.
What a CONNECT request does in HTTP proxying
A CONNECT request is not a normal fetch of a web page. It asks a proxy to create a raw TCP tunnel, usually so a client can negotiate TLS with the destination host while the proxy only relays encrypted bytes. That separation between tunnel setup and encrypted payload handling is what makes CONNECT essential to HTTPS proxying.
Because the proxy stops inspecting application content after the tunnel is established, CONNECT changes the trust boundary. The proxy still sees the destination host and port, but it does not natively understand what travels inside the tunnel unless another control inspects the traffic elsewhere in the path.
Why CONNECT exists in the HTTP protocol
CONNECT was introduced to let HTTP proxies support protocols that need an end-to-end byte stream, especially HTTPS. Instead of trying to proxy the TLS session at the HTTP layer, the client asks for a tunnel to the target:port pair, and then performs the protocol handshake through that tunnel.
This design preserves confidentiality for the application traffic, but it also means the proxy is no longer a full application intermediary once tunneling starts. In practice, CONNECT is a transport-enabling method rather than a content-delivery method, so its security significance comes from the tunnel it creates, not from an HTTP response body.
Operational and security implications of tunnelling
CONNECT can be necessary for modern browsing and enterprise egress control, but it also creates a deliberate blind spot if organisations expect the proxy to inspect all traffic. If policy allows arbitrary target ports or arbitrary destinations, the tunnel can become a general-purpose relay for traffic that bypasses normal web controls.
That makes CONNECT an important control point for proxy policy, destination allowlisting, and logging. The method itself is legitimate, but the risk comes from what the tunnel permits, especially when users or software can reach internal or unexpected hosts through the proxy path.
How CONNECT is typically governed and validated
Practitioners usually treat CONNECT as an egress control problem as much as a protocol feature. The key question is not whether the proxy supports CONNECT, but whether it restricts which hosts and ports can be tunneled and whether the resulting connections are monitored in a way that matches the organisation’s security expectations.
For validation, teams should check proxy configuration, permitted destination ranges, DNS handling, and whether logs capture enough context to reconstruct tunnel creation. Where traffic inspection is needed, the proxy design usually has to be paired with TLS interception, endpoint telemetry, or other compensating controls rather than relying on HTTP-layer visibility alone.
Risk and Threat Considerations
CONNECT becomes risky when it is implemented or governed as a broad outbound tunnel rather than a tightly scoped proxy function. Attackers and malware can abuse an allowed tunnel to reach command-and-control infrastructure, exfiltrate data, or move traffic past web filtering that was only designed for plain HTTP semantics.
Failure mechanism: If the proxy accepts overly permissive CONNECT requests, the tunnel can carry any TCP-based protocol to any permitted destination, weakening filtering, inspection, and destination control.
Impact: That can hide malicious activity inside encrypted sessions, reduce detection fidelity, and create an egress path that bypasses security controls intended to constrain outbound communications.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | CONNECT tunnels traverse a network boundary and need controlled egress enforcement. |
| AU-2 — Event Logging | Proxy tunnel creation needs auditable records of who connected where and when. | |
| Recommendation — Restrict CONNECT tunneling to approved destinations and ports through boundary enforcement. Log CONNECT requests with destination, port, user context, and outcome. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Proxy configuration and egress control are network-infrastructure governance issues. |
| CIS-8 — Audit Log Management | Detection of suspicious tunneling depends on retained and reviewable proxy logs. | |
| Recommendation — Harden proxy policy and review allowed CONNECT destinations as part of network management. Centralize proxy logs and review CONNECT activity for unusual destinations or volume. | ||
| NIST CSF 2.0 | PR.PS-01 — Configuration Management | CONNECT risk is shaped by how proxy settings, allowlists, and defaults are configured. |
| DE.CM-09 — Network Monitoring | Monitoring proxy tunnel creation helps identify misuse or unexpected outbound paths. | |
| Recommendation — Configure proxy CONNECT rules narrowly and review them after changes. Monitor CONNECT traffic patterns for anomalies in destination, timing, and volume. | ||
Practitioner Guidance
What to watch for: Treat CONNECT as a policy enforcement point, not just a compatibility feature. Restrict destinations and ports to what the business actually needs, and make sure the proxy logs are useful enough to distinguish normal HTTPS proxying from unexpected tunnelling behaviour.
Practitioner takeaway: The protocol is benign by design, but the security outcome depends on how tightly the proxy governs tunnel creation and how much visibility remains after the tunnel opens.
Related resources from NHI Mgmt Group
- Why does OpenID Connect reduce friction in consumer and data subject request workflows?
- How do you patch or mitigate CVE-2024-21893 (Ivanti Connect Secure, Policy Secure, and Neurons Server-Side Request Forgery (SSRF))?
- Is CVE-2024-21893 (Ivanti Connect Secure, Policy Secure, and Neurons Server-Side Request Forgery (SSRF)) being exploited in the wild?
- Signed OpenID Connect Request
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org