We have to keep in mind the tunnel_route use case which may use multiple match groups from various match groups within the sni:
https://docs.trafficserver.apache.org/en/latest/admin-guide/files/sni.yaml.en.html#examples -----<snip>------ sni: - fqdn: '*.foo.com' tunnel_route: '$1.myfoo' - fqdn: '*.bar.*.com' tunnel_route: '$2.some.$1.yahoo' -----<end snip>------ On Mon, Jun 19, 2023 at 12:08 AM James Peach <jpe...@apache.org> wrote: > IIUC, the regex is used to match a policy configuration based on the > requested hostname (either inbound or outbound). This means that the > matching doesn’t need to be constrained by wildcard certificate semantics. > > It’s not made explicit in the documentation, but it looks like the policy > match depends on the order of entries, so you’d have to make a linear scan > doing regex matches, which makes it more attractive to use regex matching > to reduce the size of the list. > > J > > > On 17 Jun 2023, at 2:43 am, Miles Libbey <mlib...@yahoo.com.INVALID> > wrote: > > > > The use case of a * in the middle of a hostname seems odd to me. TLS > Certificates usually follow DNS practices -- a wildcard would normally be > for subdomains -- *.mail.example.com, but not in the middle of a name -- > I don't think DNS (or most Certificate providers) has a concept that would > allow for country.*.mail.example.com). Similarly, I don't think 2 > wildcards are possible either -- *.*.mail.example.com. > > > > Was this to reduce the typing of a lot of certificates? Like you had a > bunch of certificates that matched a pattern like > country.state.service.example.com (us.ca.mail.example.com; > us.va.mail.example.com...) and wanted an way to reduce typing config? > > > > miles > > > > On Friday, June 16, 2023 at 08:10:27 AM PDT, SUSAN HINRICHS > <shinr...@ieee.org.invalid> wrote: > > > > > > I believe I was the one that brought in the pcre logic. As I recall we > > needed to support * within the name, e.g. bob.*.com. Using simple pcre > > seemed the most direct path to correctly support that use case. For > simple > > pcre's at the time the performance overhead did not seem that onerous. > > Perhaps things have changed in the last few years or my tests were > flawed. > > > > In any case, I am not aware of doing anything more complex than * as long > > as you allow for internal * as well. > > > > We could support classic only leading wildcard and also real pcre as I > > think Masakazu is suggesting. Then ATS can be smart enough to only do > the > > prcre if really necessary. > > > > On Wed, Jun 14, 2023 at 11:48 AM Masakazu Kitajo <mas...@apache.org> > wrote: > > > >>> 3. Allow `$N` (capturing) support in the tunnel_route field as is > >> > >> Does this mean we keep allowing "*.example.com" to be used for " > >> for.bar.example.com" ? And multiple wildcards as well? Just for > >> tunnel_route use case? If it's going to be an incompatible change > anyway, I > >> think we should provide a standard way that is restricted but safe and > >> enough for normal use cases. Also, it's currently not even a > >> backward match. "*.example.com" actually matches " > foo.example.com.evil.com > >> ". > >> I don't like current behavior at all. Too many bad surprises. > >> > >> I'm fine with having another way of matching if tunnel_route relies on > >> pattern matching with capturing, but I'd want to use real regex instead > of > >> the current tunnel_route specific pattern matching. It'd be a disaster > if > >> we introduced another key that interprets the pattern string in a > different > >> way. > >> > >> -- Masakazu > >> > >> > >> On Thu, Jun 8, 2023 at 5:33 PM Masaori Koshiba <masa...@apache.org> > wrote: > >> > >>> Hello, ATS Developers > >>> > >>> I'd like to hear your thoughts about the regex support in the fqdn > >>> field of sni.yaml. > >>> Recently, we have discussions across PRs (#9736 and #9767), and I have > >>> a question. > >>> > >>> # Short version > >>> > >>> Does anybody use complicated regex other than `*` in the fqdn filed of > >>> the sni.yaml? > >>> > >>> - e.g. > >>> ``` > >>> sni: > >>> fqdn: foo([0-9]+).example.com > >>> ``` > >>> > >>> # Long version > >>> > >>> Let's start with history, > >>> > >>> 1. v8.0.0 > >>> > >>> The fqdn field has wildcard support since the sni.yaml was introduced > >>> by v8.0.0. The doc clearly mentions this. > >>> > >>>> This configuration file accepts wildcard entries. To apply an SNI > based > >>> setting on all the server names > >>>> with a common upper level domain name, the user needs to enter the > fqdn > >>> in the configuration with > >>>> a *. followed by the common domain name. (*.yahoo.com for example). > >>> > https://docs.trafficserver.apache.org/admin-guide/files/sni.yaml.en.html > >>> > >>> 2. v9.0.0 > >>> > >>> PR#4630 replaced the implementation to use `pcre_regex`. This change > >>> is released by v9.0.0. It looks like the > >>> main motivation was cleanup and bugfix. But also preparing for full > >>> regex fqdn support in the future. > >>> > >>> 3. Now > >>> > >>> Craig found using `pcre_regex` has a big performance overhead. > >>> (PR#9736 is trying to fix it) > >>> We also noticed several issues. > >>> > >>> a). The current wildcard matching behavior is not following RFC6125 > >>> Section 6.4.3. Masakazu pointed out this on the PR#9767. > >>> > >>> b). The regex support has some restrictions. > >>> - e.g. dot `.` is replaced with `\.` automatically, so you can't > >>> specify dot as "any character" as usual. > >>> > >>> # Proposal > >>> > >>> It looks like allowing regex is making things complicated confusing > >>> people with wildcard support. > >>> I'd propose the below for v10.0.0. > >>> > >>> 1. Allow `*` in the fqdn field as is - e.g. `*.example.com` > >>> 2. Do NOT support regex in the fqdn field - e.g. `foo[0-9]+. > example.com` > >>> 3. Allow `$N` (capturing) support in the tunnel_route field as is > >>> > >>> Overall, it's almost roll back the behavior what we have with v8.x. > >>> Unfortunately, this will be an incompatible change with v9.x. > >>> So I'd back to my above question to see the impact. > >>> > >>> Does anybody has complicated regex in your deployment and will be > >>> affected by this change? > >>> > >>> # One more > >>> > >>> Finally, if somebody has real use case of complicated regex and needs > >>> full set of pcre regex, we need to > >>> have another discussion on how to realize it. > >>> > >>> An idea suggested by Masakazu on PR#9767 is adding another dedicated > >>> key. I think it's a good idea > >>> because it aligns with `remap` and `regex_map` in the remap.config and > >>> implementation will be much simpler. > >>> > >>> However, let's start from we really need full regex support in the > >>> sni.yaml or not. > >>> > >>> Thanks, > >>> Masaori > >>> > >> > > -- "Come to Me, all who are weary and heavy-laden, and I will give you rest. Take My yoke upon you and learn from Me, for I am gentle and humble in heart, and you will find rest for your souls. For My yoke is easy and My burden is light." ~ Matthew 11:28-30
