Perhaps I will try squid or HaProxy. I was unaware I could filter by User_Agent in squid. It may be appropriate to update the relevant documentation if the support is not possible: *** relayd.conf.8.orig Fri May 21 13:19:06 2021 --- relayd.conf.8 Fri May 21 13:23:09 2021 *************** *** 500,506 **** filter TLS connections as a man-in-the-middle. This combined mode is also called "TLS inspection". The configuration requires additional X.509 certificate settings; see the ca key description ! in the PROTOCOLS section for more details. When configured for "TLS inspection" mode, relayd(8) will listen for incoming connections which have been diverted to the local socket by PF. --- 500,510 ---- filter TLS connections as a man-in-the-middle. This combined mode is also called "TLS inspection". The configuration requires additional X.509 certificate settings; see the ca key description ! in the PROTOCOLS section for more details. Note that this feature ! currently does not support Server Name Identification (SNI) making ! it inappropriate for use as a general Internet TLS Inspection ! gateway. ! When configured for "TLS inspection" mode, relayd(8) will listen for incoming connections which have been diverted to the local socket by PF. TLS Inspection (Man in the Middle) may be ancient, and certificate pinning may make it less useful some places, but there is still enough demand that many Internet security gateway vendors support it, even with TLS1.3.*, which I understand was one of the things which slowed its standardization. Work has been done to deprecate TLS1.0 and TLS1.1 for some time. I'm guessing it will be at least a few years before TLS1.2 is deprecated or obsoleted (not used by clients), not months. **
For my purpose, I can probably work around pinning issues and TLS1.3 certificate encryption by bypassing relayd based on IP as opposed to certificate content, or perhaps by restricting to TLS1.2. I don't think relayd TLS Intercept can make decisions based on the certificate anyway, at least I didn't notice reference in the documentation. * https://www.zscaler.com/blogs/product-insights/tls-13-busting-myths-and-debunking-fear-uncertainty-doubt * https://docs.paloaltonetworks.com/pan-os/10-0/pan-os-admin/decryption/decryption-concepts/tlsv13-ssl-decryption-support.html ** https://datatracker.ietf.org/doc/rfc8996/ ** https://www.ssllabs.com/ssl-pulse/ as of today, 46.4% of surveyed sites support TLSv1.0 and 54.1% of surveyed sites support TLSv1.2 as their best protocol. Thanks! > Sent: Friday, May 21, 2021 at 3:08 AM > From: "Stuart Henderson" <s...@spacehopper.org> > To: misc@openbsd.org > Subject: Re: Relayd TLS inspection and SNI > On 2021-05-18, BS Daemon <b...@post.com> wrote: >> I like using the base OpenBSD utilities, and was >> wondering if I'm doing something wrong, if relayd could be made to >> support SNI for man-in-the-middle, or if there is an alternative >> tool for doing this which would work. > > I can't help with relayd, but this does work with squid (and you can > filter on user-agent in ACLs). From: Martin <martingot () protonmail ! com>[https://marc.info/?a=158135243000001&r=1&w=2] Date: 2021-05-21 7:26:16[https://marc.info/?l=openbsd-misc&r=1&b=202105&w=2] > Hi, > > MITM is an ancient attack technique and it is not a good idea because it > breaks \ > original cert chain. So client (application) will see that cert is different > on its \ > end. Most people and apps reject connection to a resource with fake cert > which you're \ > going to send to them. > But you can use Squid for MITM as Stuart recommended, from my side > HaProxy/Nginx can \ > help you too to do this. For SNI Snort/Suricata can be useful but for TLS up > to v1.2 \ > only. > > Sniffing the traffic that way is a bad idea, most of services uses TLSv1.3 > with \ > encrypted SNI. So your work will disappear in months. > > Martin
