Successful 200 NONE_NONE records produce false firewall blocked-domain warnings

[theletterf]

An Elastic Docs review exposed a recurring firewall warning for api.anthropic.com, even though the workflow already allowed the domain and the Claude requests completed successfully. The warning is visible in elastic/docs-content#8527 and came from run 36030637134.

What I found

The reusable Docs review workflow already includes api.anthropic.com in network.allowed. The run artifact also shows it in the effective firewall policy.

For each successful Claude CONNECT request, the Squid access log contains this pair:

... api.anthropic.com:443 ... CONNECT 200 NONE_NONE:HIER_NONE ...
... api.anthropic.com:443 ... CONNECT 200 TCP_TUNNEL:HIER_DIRECT ...

The firewall summary parser checks successful status codes before it checks the decision field. It therefore classifies both records as allowed.

The blocked-domain footer parser checks NONE_NONE before it checks successful status codes. It therefore classifies the first record as blocked and appends an incorrect allowlist recommendation to the generated review.

Expected behavior

A record with status 200, 206, or 304 must not produce a blocked-domain warning, including when the decision field is NONE_NONE.

Real blocks must continue to be reported:

• Status 403 or 407.
• Status 0 with NONE_NONE.
• TCP_DENIED without a successful status.

Proposed fix

Give successful status codes priority in isRequestBlocked, matching isRequestAllowed in the summary parser. Add a direct unit test and a log-level regression test for the observed two-record api.anthropic.com sequence.

I prepared a reference patch with that change and a patch changeset. Its focused test file passes all 37 tests. JavaScript formatting also passes. No live sandbox test was run. The complete local make agent-finish check stopped in the Go linter because the local Go 1.25 toolchain cannot process repository code that requires Go 1.27.

Related issue #58014 included the same false api.anthropic.com warning, but it covered broader audit problems and expired without isolating this parser-order defect.

The next step is to apply the focused parser change upstream and run the full repository CI suite.

[theletterf]

@pelikhan Updated to 0.89.21 today and it's a bit strange to get firewall warnings despite all else being OK.

[theletterf]

I traced this further while preparing the downstream mitigation in elastic/docs-actions.

The release boundary is between gh-aw v0.89.17 and v0.89.21. v0.89.17 bundles gh-aw-firewall v0.28.20, while v0.89.21 bundles v0.28.23. The v0.28.23 source includes the TLS SNI guard added by gh-aw-firewall#8878; the v0.28.20 source does not.

That matches the affected run. One successful Claude connection emits both CONNECT 200 NONE_NONE:HIER_NONE and CONNECT 200 TCP_TUNNEL:HIER_DIRECT. The current footer parser classifies the first line as blocked before it accounts for the successful status, so the workflow shows a false api.anthropic.com firewall warning even though the request completed. The concrete example is this run and this review.

I am recompiling our workflows with v0.89.17 as a downstream mitigation. This should avoid the newer proxy log pattern, but it does not fix the parser and I have not live-verified the rollback yet.

@pelikhan, could you confirm whether the extra NONE_NONE record is an expected result of the TLS SNI guard? The remaining upstream fix would be to make the footer parser ignore successful 200 records, or otherwise reconcile the paired proxy records before it reports a blocked domain.

[pelikhan]

@lpcox

[lpcox]

The SNI guard can produce two Squid records for a successful HTTPS request:

CONNECT 200 NONE_NONE:HIER_NONE
CONNECT 200 TCP_TUNNEL:HIER_DIRECT

The first record is an intermediate peek/handshake event, not a blocked request. AWF itself only reports TCP_DENIED entries as blocked, so the false warning is generated by gh-aw’s firewall_blocked_domains.cjs, which checks NONE_NONE before checking the HTTP status.

Recommended solution: fix the parser in gh-aw so successful status codes take precedence:

• Treat 200, 206, and 304 as allowed, regardless of the decision field.
• Continue reporting actual blocks with 403/407, TCP_DENIED, or status 0 plus NONE_NONE.
• Add a unit test for 200 NONE_NONE.
• Add a regression test covering the two-record api.anthropic.com sequence.

I do not recommend changing AWF to suppress all NONE_NONE records: status 0 NONE_NONE represents a genuine failed connection and should remain diagnosable. Reverting the SNI guard would also restore the domain-fronting bypass that the guard fixed.