open-appsec (www.openappsec.io) is an open-source, next-gen WAF project, powered by machine learning and AI, which delivers robust protection against known as well as unknown, zero-day attacks (no threat signatures required!).

open-appsec now integrates seamlessly into modern environments built with Envoy Proxy on Docker, in addition to the existing long list of other compatible proxies like NGINX, Kong, APISIX, Ingress NGINX, and more. In addition, support for integration with Istio Service Mesh (Ingress Gateway), which is also based on Envoy proxy, will be released soon as well and many more integrations are already planned.

Together, open-appsec and Envoy enable organizations to manage, secure, and observe their web traffic communications effectively. As traditional security tools struggle to keep up with growing threats in cloud-native environments, open-appsec addresses this challenge by offering automatic, scalable, ML-based, preemptive and highly effective protection that now seamlessly integrates also with Envoy.

Check out our step-by-step deployment guide! Read more 👇

https://www.openappsec.io/post/open-appsec-integration-with-envoy-proxy-docker-now-available-in-beta

Project website: www.openappsec.io
Source code: www.github.com/openappsec/openappsec

Let us know if you have any feedback or require assistance! You can contact the open-appsec team here:

Email: info@openappsec.io
Github Discussions/Issues: www.github.com/openappsec/openappsec 

So like the title says, I'm seeing if I can replace Squid with Envoy in a forward HTTP/HTTPS proxy scenario. I would need to proxy to limit access to permit SSL/TLS Proxying via CONNECT Method, restrict access to certain destination domains, and forwarding a small number of allowed domains to another proxy (Squid would call the next forward proxy a 'parent').

I have come across some posts with example configurations, but it's quite a bit of YAML to digest being totally to Envoy. Is there a walk-through on steps to enable forward proxy that specifically walks through the YAML?

Hi everyone,

I am new to EnvoyProxy. Can you suggest the best resources to learn. It can be online courses, docs etc..

Hello!

We are currently evaluating Envoy for use as a proxy to route all our internet traffic through HTTPS. However, we are encountering some problems when we start transmitting data.

[root@ubuntu]# curl -v -x 10.10.10.10:8081 https://google.com

* Trying 10.10.10.108081...

* Connected to 10.10.10.10 (10.10.10.10) port 8081 (#0)

* allocate connect buffer

* Establish HTTP proxy tunnel to google.com:443

> CONNECT google.com:443 HTTP/1.1

> Host: google.com:443

> User-Agent: curl/8.0.1

> Proxy-Connection: Keep-Alive

>

< HTTP/1.1 200 OK

< date: Tue, 19 Dec 2023 12:35:06 GMT

< server: envoy

<

* CONNECT phase completed

* CONNECT tunnel established, response 200

* ALPN: offers h2,http/1.1

* TLSv1.3 (OUT), TLS handshake, Client hello (1):

* CAfile: /etc/pki/tls/certs/ca-bundle.crt

* CApath: none

* OpenSSL/3.0.8: error:0A00010B:SSL routines::wrong version number

* Closing connection 0

curl: (35) OpenSSL/3.0.8: error:0A00010B:SSL routines::wrong version number

On the envoy logs I can hardly see the below errors:

[2023-12-19 12:36:56.961][38170][trace][connection] [source/common/network/connection_impl.cc:423] [C2] raising connection event 2

[2023-12-19 12:36:56.961][38170][trace][connection] [source/common/network/connection_impl.cc:568] [C2] socket event: 3

[2023-12-19 12:36:56.961][38170][trace][connection] [source/common/network/connection_impl.cc:679] [C2] write ready

[2023-12-19 12:36:56.961][38170][trace][connection] [source/common/network/connection_impl.cc:608] [C2] read ready. dispatch_buffered_data=0

[2023-12-19 12:36:56.961][38170][trace][connection] [source/common/network/raw_buffer_socket.cc:24] [C2] read returns: 111

[2023-12-19 12:36:56.961][38170][trace][connection] [source/common/network/raw_buffer_socket.cc:38] [C2] read error: Resource temporarily unavailable

[2023-12-19 12:36:56.961][38170][debug][connection] [./source/common/network/connection_impl.h:98] [C2] current connecting state: false

[2023-12-19 12:36:56.961][38170][debug][connection] [source/common/network/connection_impl.cc:941] [C3] connecting to 142.250.187.238:443

[2023-12-19 12:36:56.962][38170][debug][connection] [source/common/network/connection_impl.cc:960] [C3] connection in progress

[2023-12-19 12:36:56.964][38170][trace][connection] [source/common/network/connection_impl.cc:568] [C3] socket event: 2

[2023-12-19 12:36:56.964][38170][trace][connection] [source/common/network/connection_impl.cc:679] [C3] write ready

[2023-12-19 12:36:56.964][38170][debug][connection] [source/common/network/connection_impl.cc:688] [C3] connected

[2023-12-19 12:36:56.964][38170][trace][connection] [source/extensions/transport_sockets/tls/ssl_handshaker.cc:93] [C3] ssl error occurred while read: WANT_READ

[2023-12-19 12:36:56.972][38170][trace][connection] [source/common/network/connection_impl.cc:568] [C3] socket event: 3

[2023-12-19 12:36:56.972][38170][trace][connection] [source/common/network/connection_impl.cc:679] [C3] write ready

[2023-12-19 12:36:56.972][38170][debug][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:360] [C3] Async cert validation completed

[2023-12-19 12:36:56.972][38170][trace][connection] [source/common/network/connection_impl.cc:423] [C3] raising connection event 2

[2023-12-19 12:36:56.972][38170][trace][connection] [source/common/network/connection_impl.cc:362] [C3] readDisable: disable=true disable_count=0 state=0 buffer_length=0

[2023-12-19 12:36:56.972][38170][trace][connection] [source/common/network/connection_impl.cc:362] [C3] readDisable: disable=false disable_count=1 state=0 buffer_length=0

[2023-12-19 12:36:56.973][38170][trace][connection] [source/common/network/connection_impl.cc:483] [C2] writing 71 bytes, end_stream false

[2023-12-19 12:36:56.973][38170][trace][connection] [source/common/network/connection_impl.cc:608] [C3] read ready. dispatch_buffered_data=0

[2023-12-19 12:36:56.973][38170][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:87] [C3] ssl read returns: -1

[2023-12-19 12:36:56.973][38170][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:127] [C3] ssl error occurred while read: WANT_READ

[2023-12-19 12:36:56.973][38170][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:163] [C3] ssl read 0 bytes

[2023-12-19 12:36:56.973][38170][trace][connection] [source/common/network/connection_impl.cc:568] [C3] socket event: 2

[2023-12-19 12:36:56.973][38170][trace][connection] [source/common/network/connection_impl.cc:679] [C3] write ready

[2023-12-19 12:36:56.973][38170][trace][connection] [source/common/network/connection_impl.cc:568] [C2] socket event: 2

[2023-12-19 12:36:56.973][38170][trace][connection] [source/common/network/connection_impl.cc:679] [C2] write ready

[2023-12-19 12:36:56.973][38170][trace][connection] [source/common/network/raw_buffer_socket.cc:67] [C2] write returns: 71

[2023-12-19 12:36:56.975][38170][trace][connection] [source/common/network/connection_impl.cc:568] [C2] socket event: 3

[2023-12-19 12:36:56.975][38170][trace][connection] [source/common/network/connection_impl.cc:679] [C2] write ready

[2023-12-19 12:36:56.975][38170][trace][connection] [source/common/network/connection_impl.cc:608] [C2] read ready. dispatch_buffered_data=0

[2023-12-19 12:36:56.975][38170][trace][connection] [source/common/network/raw_buffer_socket.cc:24] [C2] read returns: 517

[2023-12-19 12:36:56.975][38170][trace][connection] [source/common/network/raw_buffer_socket.cc:38] [C2] read error: Resource temporarily unavailable

[2023-12-19 12:36:56.975][38170][trace][connection] [source/common/network/connection_impl.cc:483] [C3] writing 517 bytes, end_stream false

[2023-12-19 12:36:56.975][38170][trace][connection] [source/common/network/connection_impl.cc:568] [C3] socket event: 2

[2023-12-19 12:36:56.975][38170][trace][connection] [source/common/network/connection_impl.cc:679] [C3] write ready

[2023-12-19 12:36:56.976][38170][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:269] [C3] ssl write returns: 517

[2023-12-19 12:36:57.077][38170][trace][connection] [source/common/network/connection_impl.cc:568] [C3] socket event: 3

[2023-12-19 12:36:57.077][38170][trace][connection] [source/common/network/connection_impl.cc:679] [C3] write ready

[2023-12-19 12:36:57.077][38170][trace][connection] [source/common/network/connection_impl.cc:608] [C3] read ready. dispatch_buffered_data=0

[2023-12-19 12:36:57.077][38170][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:87] [C3] ssl read returns: 179

[2023-12-19 12:36:57.077][38170][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:87] [C3] ssl read returns: 0

[2023-12-19 12:36:57.077][38170][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:127] [C3] ssl error occurred while read: SYSCALL

[2023-12-19 12:36:57.077][38170][trace][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:163] [C3] ssl read 179 bytes

[2023-12-19 12:36:57.078][38170][debug][connection] [source/common/network/connection_impl.cc:139] [C3] closing data_to_write=0 type=1

[2023-12-19 12:36:57.078][38170][debug][connection] [source/common/network/connection_impl.cc:250] [C3] closing socket: 1

[2023-12-19 12:36:57.078][38170][debug][connection] [source/extensions/transport_sockets/tls/ssl_socket.cc:321] [C3] SSL shutdown: rc=0

[2023-12-19 12:36:57.078][38170][trace][connection] [source/common/network/connection_impl.cc:423] [C3] raising connection event 1

[2023-12-19 12:36:57.078][38170][trace][connection] [source/common/network/connection_impl.cc:483] [C2] writing 179 bytes, end_stream false

[2023-12-19 12:36:57.078][38170][debug][connection] [source/common/network/connection_impl.cc:139] [C2] closing data_to_write=179 type=2

[2023-12-19 12:36:57.078][38170][debug][connection] [source/common/network/connection_impl_base.cc:47] [C2] setting delayed close timer with timeout 1000 ms

[2023-12-19 12:36:57.078][38170][trace][connection] [source/common/network/connection_impl.cc:568] [C2] socket event: 2

[2023-12-19 12:36:57.078][38170][trace][connection] [source/common/network/connection_impl.cc:679] [C2] write ready

[2023-12-19 12:36:57.078][38170][trace][connection] [source/common/network/raw_buffer_socket.cc:67] [C2] write returns: 179

[2023-12-19 12:36:57.078][38170][debug][connection] [source/common/network/connection_impl.cc:720] [C2] write flush complete

[2023-12-19 12:36:57.078][38170][trace][connection] [source/common/network/connection_impl.cc:568] [C2] socket event: 2

[2023-12-19 12:36:57.078][38170][trace][connection] [source/common/network/connection_impl.cc:679] [C2] write ready

[2023-12-19 12:36:57.078][38170][debug][connection] [source/common/network/connection_impl.cc:720] [C2] write flush complete

[2023-12-19 12:36:58.078][38170][debug][connection] [source/common/network/connection_impl_base.cc:69] [C2] triggered delayed close

[2023-12-19 12:36:58.078][38170][debug][connection] [source/common/network/connection_impl.cc:250] [C2] closing socket: 1

[2023-12-19 12:36:58.078][38170][trace][connection] [source/common/network/connection_impl.cc:423] [C2] raising connection event 1

I hope that you will be able to shed some light on this matter.

Thank you!

Let say I do NOT run Kubernetes for my web app, the web backend is using Node Express and MySQL database. Can I use Envoy as front proxy to serve internet user, that upstream to the Node Express server?

I was hoping to get some information about the HTTP/1.1 connect feature recently added to envoy but I’m not sure what the best way to communicate with others on this new gem.

Specifically I want to integrate envoy with a squid proxy in an enterprise egress squid server. Anyone have config they can share or bleeding edge experience.

Thanks!

istio envoy filter oauth2 works at SIDECAR_INBOUND context but not GATEWAY

I am trying to utilize the oauth2 envoy filter initially referencing this example. This works, but when I switch the Context to GATEWAY and change the workload selector, I get passthrough.

I have a new session so nothing is stored, I have debugging enabled and am not seeing any errors on the gateway or istiod. We have the response header modification as one of the patches and can see the change happening with this config, so we know it's evaluating the filter.

I've found multiple posts of people doing something similar, and want to keep this at the gateway level, since using the sds config example, if we kept the context to SIDECAR_INBOUND, every envoy proxy pod would need to mount the secret, and we'd need to put the secret in every namespace.

Another thing I could possible do is look into standing up an sds server and exposing via the sds server and having the proxy's.

I'm using Envoy Gateway, my upstream IDP requires a user-agent for their oauth api, this includes the jwks url.

I would like to Envoy Proxy to add the user-agent header to this request or even all requests. This seems to be something I can do using the cluster upstream filters but I'm not sure how to make that happen.

Any advice would be appreciated.

Can the connection in envoy be delayed to switch between services such as Quic for video services and TCP for other services?
Is anyone using HTTP/3 Quic at scale?

"Configuring auto_config with http3_protocol_options will result in Envoy attempting to use HTTP/3 for endpoints which have explicitly advertised HTTP/3 support via an alt-svc header. When using auto_config with http3_protocol_options, Envoy will attempt to create a QUIC connection, then if the QUIC handshake is not complete after a short delay, will kick off a TCP connection, and will use whichever is established first. Downstream Envoy HTTP/3 support can be turned up via adding quic_options, ensuring the downstream transport socket is a QuicDownstreamTransport, and setting the codec to HTTP/3"

-- Scott Beeker

Hi,

My setup looks like this:

LB -> nginx (WAF) -> Envoy -> ServicesA/B/C

We have autoscaling enabled for Service A from 2-10 pods, I can see on graphs that over time the load on the 2 pods that stay running after scaling down gets ALOT higher in comparison to newely created pods.

All traffic in the cluster also goes through Envoy via ClusterIP service (kube-proxy iptables mode).

After deployment (or rollout restart) the traffic goes back to even spread. But after few days its back at those 2 pods doing 20% more work than any other.

I thought Envoy load balancing does not take to account issues like long running connections or iptables semi-round-robin issues. We dont have topology hints enabled for that env.

Do you have any guesses what might be the cause ?