Inspecting traffic tunnelled over HTTP CONNECT

[Craig Radcliffe]

I posted this query previously on the envoy-dev Slack channel, but it may have not hit the right audience there.

We have a use case in which we’d like to inspect traffic that is tunnelled over an HTTP CONNECT connection. Specifically, we’d like to be able to interrupt the connection if the tunnelled application layer properties (e.g. application protocol or application metadata) violate some defined policy.

I was looking at the incoming HTTP CONNECT PR and I was wondering if anyone had given any thought to the above use case. The WebSocket implementation seems to be able to accomplish this with the upgrade config’s “filters” list, but I haven’t been able to find any details on how this will/would be implemented for HTTP CONNECT.

If there aren’t any current plans to implement support for inspecting the tunnelled traffic and this is something that makes sense for an upstream submission, we have some development time to contribute to the effort.

[Matt Klein]

+ @Alyssa Wilk 

The way Alyssa is implementing CONNECT should be amenable to standard HTTP filters and upgrade filters running before/during the CONNECT but I will defer to her for more details.

--
You received this message because you are subscribed to the Google Groups "envoy-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to envoy-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/envoy-dev/99ff78a4-675a-4d58-9b74-0515815fec8b%40googlegroups.com.

[Alyssa (Rzeszutek) Wilk]

Yep - you can do a custom filter chain for CONNECT / upgrade requests, so you can have a data inspection filter which only applies to CONNECT.

AFIK there are not yet filters looking at payload  (i.e. no websocket parsing filters) but I think it would be a fine addition.

cheers,

Alyssa

[Craig Radcliffe]

Thank you both for your responses.

Has there been any thought given to whether it would be possible to inspect HTTP that is being sent over a tunnel like CONNECT or websocket without creating another subsystem that duplicates the HTTP Connection Manager functionality? Ideally, we could create a data inspection filter that would somehow feed back into HCM but I can't see an obvious way to accomplish that -- I'm sure it might run contrary to some system assumptions.

Thanks,

Craig.

--

Craig Radcliffe
Software Engineer  | Symantec SWG
Broadcom
office: 519.888.5115
209 Frobisher Drive  | Waterloo, Ontario N2V 2G4
craig.r...@broadcom.com   | broadcom.com

[Alyssa (Rzeszutek) Wilk]

Huh.  Well the HCM mainly takes data via onData, so you could presumably create an HCM and pass the data off.  You'd have to have a custom filter chain which allowed both the inspection and passed the data back, and it wouldn't work for encrypted payload and would be dicey for HTTP/2, where you'd have to clone all the data and swallow the HCM output instead.  If you just want to inspect HTTP/1.1 headers you might just want to have a filter which used Envoy's http/1.1 codec to parse the headers out.  

[Matt Klein]

Yeah per Alyssa I think it wouldn't be "that bad" to run an HCM within the filter to do the inspection. Sounds like an interesting project. :)

[Kannan Varadhan]

Hi folks:

I have a slightly different use case for this type of inspection as well.  I am wondering if there is a way for me to engage as well?

For us, we want to inspect the traffic and use headers in the tunnelled connection to make routing decisios.

If a route is not found here, pend the connectin and use a different service to push/install a route and resume the session.

Is there a way for us to connect and help?

THanks,

Kannan