# The gateway held, but the answer leaked

The egress gateway is the piece that makes remote browsing safe to offer: a
loopback proxy that Chromium is launched against with no direct fallback, which
resolves every hostname itself, checks every address the lookup returns, and
dials only a numeric address it already approved. If it has a hole, a stranger
reaches your private network through your own browser.

So before merging it I had an independent pass try to break it, with one
instruction: find a byte that reaches an unapproved socket.

It could not. Not through DNS rebinding on a new connection — the gateway
re-resolves and re-classifies each time, and answering `8.8.8.8` first and
`127.0.0.1` second gets the second connection refused with no dial. Not through
the 26 request-parsing tricks it tried: bare-LF request smuggling, duplicate
`Host`, obs-fold continuations, `Content-Length` fighting `Transfer-Encoding`,
`http://example.com@169.254.169.254/`, a CR buried in a header value. Not
through the authentication path, which is checked before resolution on every
route and has no second-request branch to skip. Not through the resolver, which
denies a whole answer set if any member is private. The property the module
exists for held.

What it found instead was on the way back.

## The response was never ours to relay

The gateway serves exactly one request per connection. After that it stops
reading, and the connection is finished — from its point of view.

It never told the client that. The upstream response went through a raw byte
pump: read bytes, write bytes, no parsing, no rewriting. So when a hostile
origin answered

```
HTTP/1.1 200 OK
Content-Length: 0
Connection: keep-alive

HTTP/1.1 200 OK
Content-Length: 8

smuggled
```

both responses reached the client, and the client had been told the proxy socket
was reusable. Chromium pools plain-HTTP proxy sockets by *proxy server*, not by
origin. A second response sitting in the receive buffer of a socket the client
believes it can reuse for a different origin is the shape of a
response-smuggling bug.

The documentation, meanwhile, said the gateway "forces `Connection: close`." It
did — on the request going *upstream*. Nobody had asked what the client saw.

The fix is to rewrite the response head as well: drop `Connection`,
`Keep-Alive`, `Proxy-Connection`, append `Connection: close`, then pump the
body. Now the one-request-per-connection rule is visible to the client instead
of being merely true inside the gateway.

## Two more, both from trusting a number a stranger chose

`Content-Length` sized a `readexactly()`. One connection declaring 64 MiB grew
resident memory by 227 MB before a byte moved; the connection cap multiplies
that. The transfer limit was there — 128 MiB — but a limit on total bytes
transferred is not a limit on bytes held at once. Streaming in chunks makes the
declaration irrelevant to memory.

And admission counted connections before reading any of them. Four TCP
connections that sent *nothing* — no credential, no request — filled a
four-connection gateway and made an authenticated `CONNECT` return
`429 Too Many Requests`, for the full header timeout, renewably. The credential
was checked carefully and then handed a queue that anyone could fill. Pending
sockets now have their own budget and only convert to a served slot once the
credential is proven.

## The test that would have passed on the bug

One more thing worth recording. There is a test named
`test_numeric_dialer_never_calls_getaddrinfo` — the anti-TOCTOU property, the
single most important thing this module does. The reviewer replaced the entire
body of `dial_numeric` with the bug it names, resolving by name instead of
dialing a pinned address.

All 37 tests still passed.

The test feeds an already-numeric string, and asyncio short-circuits numeric
strings before it reaches the patched resolver. The property is genuinely
enforced — by a different function, checked by a different test — but the test
that reads like the guard is not the guard. That is worse than no test, because
the name tells the next reader the question has been answered.

Nothing in the suite asserted anything about the response the client receives,
either, beyond its status line. Which is exactly why the smuggling window was
invisible: the tests watched everything going out and nothing coming back.