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 > > >
