[squid-users] regex for normal websites

[ngtech1ltd at gmail.com]

Hey Robert,
 
The docs at http://www.squid-cache.org/Doc/config/acl/  states:
 
        acl aclname ssl::server_name_regex [-i] \.foo\.com ...
          # regex matches server name obtained from various sources [fast]
 
Which and I do not know exactly what it means but it will not work with a helper in most cases.
I have found the in the git the next sources:
https://github.com/squid-cache/squid/blob/bf95c10aa95bf8e56d9d8d1545cb5a3aafab0d2c/doc/release-notes/release-3.5.sgml#L414
 
                New types ssl::server_name  and ssl::server_name_regex
                   to match server name from various sources (CONNECT authority name,
                   TLS SNI domain, or X.509 certificate Subject Name).
 
Which means that there is a set of checks which the acl does and not just a domain name.
It’s also even possible that the domain name is not know in the CONNECT state of the connection.
If I remember correctly there is a possibility for browsers to use the same exact connection for multiple domains but
I have not seen this yet in production.
With Squid once you bump the connection to HTTP/1.x you can make 100% sure the features of the Host header request.
 
At Servername.cc ie:
https://github.com/squid-cache/squid/blob/aee3523a768aff4d1e6c1195c4a401b4ef5688a0/src/acl/ServerName.cc#L81 
 
There is a specific logic of what is done and what is matched but I am not sure what would be used in the case of:
*.adobe.com
 
Certificate SAN.
 
Specifically This part of the Common Names ie SAN:
https://github.com/squid-cache/squid/blob/aee3523a768aff4d1e6c1195c4a401b4ef5688a0/src/acl/ServerName.cc#L105
 
which to my understanding points to:
https://github.com/squid-cache/squid/blob/d146da3bfe7083381ae7ab38640cbfd0d2542374/src/ssl/support.cc#L195
 
doesn’t make any sense to me.( didn’t tried that much to understand)
 
If someone might be able to make sense of things in a synchronic fashion it would help.
(I do not see any debugs usage there or any helping comment )
 
Thanks,
Eliezer
 
----
Eliezer Croitoru
NgTech, Tech Support
Mobile: +972-5-28704261
Email: ngtech1ltd at gmail.com <mailto:ngtech1ltd at gmail.com> 
Web: https://ngtech.co.il/
My-Tube: https://tube.ngtech.co.il/
 
From: squid-users <squid-users-bounces at lists.squid-cache.org> On Behalf Of robert k Wild
Sent: Wednesday, 27 July 2022 13:52
To: Squid Users <squid-users at lists.squid-cache.org>
Subject: Re: [squid-users] regex for normal websites
 
that's the weird thing, when i try this in  "ssl::server_name_regex"
.adobe.com <http://adobe.com> 
 
it doesnt work
 
you mean escape ie the \ character
 
 
 
 
 
On Wed, 27 Jul 2022 at 11:05, Matus UHLAR - fantomas <uhlar at fantomas.sk <mailto:uhlar at fantomas.sk> > wrote:
On 27.07.22 10:54, robert k Wild wrote:
>think i got it right but just want to double check with you guys
>
>so in my "ssl::server_name" i had
>.adobe.com <http://adobe.com> 
>
>that worked but i want to mix normal website and regex websites together so
>i just have one list for all

didn't the above work?  AFAIK it should, IIRC domain matching in squid 
matches "domain.com <http://domain.com> " if you check for ".domain.com <http://domain.com> ".

>i now have this for "ssl::server_name_regex"
>^.*adobe.com <http://adobe.com> $
>
>it works, so im guessing its right

the dot should be escaped


-- 
Matus UHLAR - fantomas, uhlar at fantomas.sk <mailto:uhlar at fantomas.sk>  ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
BSE = Mad Cow Desease ... BSA = Mad Software Producents Desease
_______________________________________________
squid-users mailing list
squid-users at lists.squid-cache.org <mailto:squid-users at lists.squid-cache.org> 
http://lists.squid-cache.org/listinfo/squid-users


 
-- 
Regards, 

Robert K Wild.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20220728/f082e747/attachment-0001.htm>