Envoy: Clarification of wildcards in sniDomains of filterChainMatch

[vadimeisenbergibm]

According to https://github.com/envoyproxy/envoy/blob/a22159aa1274f63b1b83e56ccc4482e0a01a6d80/source/common/ssl/context_manager_impl.cc#L116

the wildcard is allowed before the first dot, it means that www.example.com will be matched by an SNI domain *.example.com, but not by *.com or *. Maybe this fact should be stressed in the documentation https://www.envoyproxy.io/docs/envoy/latest/api-v2/api/v2/listener/listener.proto#listener-filterchainmatch .

[mattklein123]

@vadimeisenbergibm perhaps you could submit a documentation improvement PR?

[vadimeisenbergibm]

@mattklein123 Will do.

[PiotrSikora]

@rshriram thinks this is too strict for SNI-routing.

Any objections for relaxing this restriction and matching all subdomains (i.e. foo.bar.example.com would also match *.example.com, whereas currently it doesn't)?

cc @ggreenway @mattklein123 @vadimeisenbergibm

[mattklein123]

@PiotrSikora I actually had the same Q but I forgot to ask it. I would be in favor of that change.

[rshriram]

To add more context, when you are doing SNI passthrough, hopping from one to another, the semantics of SNI wildcards are very different from that of standard HTTP (where *.com subsumes *.example.com in the virtual host match). So, folks who are trying to setup a chain of envoys for forwarding SNI connections would find this behavior a bit too strict and cumbersome to deal with. It also complicates management plane config generation..

[ggreenway]

I don't have any objection. So I assume with this change, for foo.bar.baz.example.com, we'll now do a lookup for foo.bar.baz.example.com, .bar.baz.example.com, .baz.example.com, .example.com, and .com, in that order?

[PiotrSikora]

@ggreenway correct.

[rshriram]

I would suggest using the same implementation from here (https://github.com/envoyproxy/envoy/blob/master/source/common/router/config_impl.cc#L767-L785), so that http virtual hosts and sni match in same manner.

[vadimeisenbergibm]

Note that the logic in https://github.com/envoyproxy/envoy/blob/master/source/common/router/config_impl.cc#L767-L785 does not take dots in the account, it just performs a prefix comparison. So *example.com will match both baz.example.com and myexample.com. It could be a security concern, when someone configures *mycompanydomain.com to expect to match finance.mycompany.com and accounts.mycompany.com, but it will also match someothercompanymycompany.com.

[PiotrSikora]

@vadimeisenbergibm yeah, I'm not going to use that.

[vadimeisenbergibm]

So maybe the logic at https://github.com/envoyproxy/envoy/blob/master/source/common/router/config_impl.cc#L767-L785 should be changed to, to have the same code and the same semantics, as Shriram proposed.

[rshriram]

The logic there applies for virtual hosts (the piece that matches HTTP Authority header. When things reach this stage, I don't think the security concern you outlined is valid in this stage. Proxies allow a full gamut of regexes in the virtual host match.