Protocols and TLS
What Hugin can intercept — HTTP/1.1, HTTP/2, HTTP/3, and WebSocket — how its TLS works, and the per-target connection controls around them — protocol version, DNS, and upstream proxy.
Hugin is a full MITM proxy. It terminates TLS with a per-host certificate signed by its CA, captures the exchange, and forwards it upstream. Everything here is part of the Proxy (Community).
HTTP/1.1 and HTTP/2
Both are intercepted by default. The protocol is chosen by ALPN during the TLS
handshake. For HTTP/2, Hugin captures the pseudo-headers (:method, :scheme,
:authority, :path, :status) alongside the regular headers, so h2 flows are
fully inspectable — smuggling and desync tests work on HTTP/2 the same as HTTP/1.
Force a protocol version per host
ALPN picks the version by default, but a desync often only fires on one of them. A front-end that talks HTTP/2 to you and HTTP/1.1 to its back-end is the classic smuggling setup, and some bugs only surface once you pin the version yourself.
Override it per host pattern (wildcards like *.example.com work): force HTTP/1.1
to drive classic CL/TE smuggling on the downgraded leg, or force HTTP/2 to push an
h2-specific desync at a server that would otherwise negotiate down. Hugin uses the
version you forced even when the target advertised the other one.
Tune the HTTP/2 SETTINGS
The SETTINGS Hugin advertises on the HTTP/2 connections it opens to a target are yours to change: maximum concurrent streams (default 100), the initial flow-control window (default 65535 bytes), and the maximum frame size (default 16 KB, up to a ~16 MB ceiling). Shape the connection behind rapid-reset (CVE-2023-44487) and CONTINUATION-flood testing — push the frame size toward its ceiling, or move the stream and window limits, and watch how the target copes.
HTTP/3 (QUIC)
HTTP/3 is compiled in but off by default. Enable it in the config
([proxy] h3_enabled = true — see configuration).
It runs as a separate UDP listener (default UDP
port 443), and captured flows are tagged HTTP/3. 0-RTT early data is off by default;
when enabled, only idempotent methods (GET/HEAD/OPTIONS/TRACE) are accepted over
0-RTT and anything else gets a 421. WebTransport is refused, and WebSocket over
HTTP/3 is not implemented yet.
WebSocket
WebSocket upgrades are detected and every frame is captured in both directions — see WebSocket. WebSocket over HTTP/2 (RFC 8441 extended CONNECT) is supported as an opt-in for the WS client; over HTTP/3 it is not yet implemented.
Custom DNS
Hugin resolves every target hostname itself, so you decide what the name points at before a single packet leaves your machine.
Map a hostname to a fixed IP and skip resolution entirely. This is the origin-IP
bypass: once you have the real address behind a CDN or WAF, send www.target.com
to it directly. Hugin still puts the original hostname in the Host header and the
TLS SNI, so you reach the origin while the edge never sees the request. Wildcards
like *.target.com are supported.
Send lookups through a DNS server you pick instead of the system one. Rank several resolvers and allow- or deny-list the domains each may answer — resolve internal names through an internal resolver while everything else goes to a public one.
Match a hostname by exact name, wildcard, or regex and rewrite what it resolves to. Flip a name between an external and an internal address across runs for DNS-rebinding research.
DNS queries go out over plain UDP and TCP only. There is no DNS over HTTPS (DoH) or DNS over TLS (DoT).
Upstream proxy
Route Hugin's outbound traffic through another proxy — to change the IP you come out on, reach a network you only have a tunnel into, or chain Hugin behind another tool.
Hugin speaks HTTP, HTTPS, SOCKS4, and SOCKS5 upstream, with optional username and
password auth. Set one proxy for everything, or write per-host rules (wildcards, with
priority) so only the targets you choose take the detour and the rest go direct.
Presets cover the usual cases — Tor (SOCKS5 127.0.0.1:9050), Mullvad, and Burp
Suite (HTTP 127.0.0.1:8080). Run the built-in connection test to confirm the chain
works and see the egress IP you actually come out on.
TLS
Hugin negotiates TLS 1.2 and 1.3 only — 1.0 and 1.1 are rejected by design. By default the upstream connection presents a real Chrome TLS fingerprint (a Chrome ClientHello, JA3/JA4-matching, including the X25519MLKEM768 post-quantum group), so an intercepted target sees a believable client rather than a generic proxy. See fingerprinting for the full evasion picture.
Pin the TLS version for downgrade testing
Set the minimum and maximum TLS version Hugin will negotiate with the target. Both stay inside the 1.2–1.3 band — 1.0 and 1.1 remain off — but capping the maximum at 1.2 forces a 1.3-capable target back onto the older handshake, enough to check how it behaves there and whether a 1.2-only weakness is in reach.
Reach a mutual-TLS target
Some internal and admin apps demand a client certificate (mutual TLS, mTLS). Give Hugin a PKCS#12 / PFX client certificate per host pattern and it presents that certificate upstream, so you get through the mTLS gate and test the application behind it like any other target.
Present your own certificate per host
For each host it intercepts, Hugin mints a leaf certificate from its own CA. When the client pins a specific certificate and rejects everything else, that breaks. Supply your own certificate and key (PEM) for a host pattern and Hugin presents it instead of a freshly minted one, so interception keeps working against a client whose pinned certificate you control.