Re: Relayd TLS inspection and SNI
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" > To: misc@openbsd.org > Subject: Re: Relayd TLS inspection and SNI > On 2021-05-18, BS Daemon 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 [https://marc.info/?a=15813524301=1=2] Date: 2021-05-21 7:26:16[https://marc.info/?l=openbsd-misc=1=202105=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
Re: Relayd TLS inspection and SNI
On 2021-05-21, Martin wrote: > 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. This is about providing monitored/filtered internet access to systems that are particularly configured to use it. The way this works is that you install the MITM-signing certificate on the machines accessing the web via that proxy. Typically in that case browsers automatically disable certificate pinning if the cert is signed by a locally administered CA. > 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. There aren't many services which require TLSv1.3 with encrypted SNI yet, so the interception proxy can restrict to TLS 1.2 to bypass this.
Re: Relayd TLS inspection and SNI
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 ‐‐‐ Original Message ‐‐‐ On Friday, May 21, 2021 7:08 AM, Stuart Henderson wrote: > 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).
Re: Relayd TLS inspection and SNI
On 2021-05-18, BS Daemon 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).
Relayd TLS inspection and SNI
I am hoping that I'm just doing something wrong, but it appears
that while relayd supports some Server Name Identification (SNI)
functionality, it does not support SNI for it's man-in-the-middle
/ TLS inspection configuration. Years ago I used relayd to permit access
only to certain browsers
by User_Agent string and was hoping to do the same now. But with
SNI not working, and the amount of use of SNI in the world today,
this is no longer workerable. I peaked at the code, but don't have the
expertise to to make the
feature work. 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. As an example:
At the time of writing, BSDCan, a BSD conference in Canada, has a
web site with two names: www.bsdcan.org and www.bsdcan.ca. They
both are hosted at a single IP and Port. Each site uses it's own
server certificate. The default site as far as TLS is concerned is
www.bsdcan.ca, so unless one provides the SNI host name, one gets
the certificate for this server name. Interestingly, www.bsdcan.ca
redirects the clients to www.bsdcan.org. When a client goes to
www.bsdcan.org, but does not provide the SNI server name, one gets
the certificate for www.bsdcan.ca. The result is that if the client
does not have SNI abilities enabled, the browsers throws a warning
message.
Without relayd in the path:
# This will get certificate for bsdcan.ca:
libressl s_client -connect www.bsdcan.ca:443
# This will also get certificate for bsdcan.ca (no SNI in request):
libressl s_client -connect www.bsdcan.org:443
# This will get certificate for bsdcan.org
libressl s_client -servername www.bsdcan.org -connect www.bsdcan.org:443
# This will also get certificate for bsdcan.org (SNI requests this site)
libressl s_client -servername www.bsdcan.org -connect www.bsdcan.ca:443With
relayd in the path, as configured below,
# This will get certificate for bsdcan.ca
# (SNI requested, but relayd is not handling SNI for TLS inspection)
libressl s_client -servername www.bsdcan.org -connect www.bsdcan.org:443
relayd.conf:
log connection
http protocol httpfilter {
# Return HTTP/HTML error pages to the client
return error
match header log "User-Agent"
match url log
# Block disallowed sites
match request label "URL filtered!"
block request quick url "www.example.com/" value "*"
# Pass allowed browsers
match request label "User-Agent Good"
pass request quick header "User-Agent" \
value "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:*.0) Gecko/20100101
Firefox/*"
pass request quick header "User-Agent" \
value "Microsoft-CryptoAPI/10.0"
# Block all other browsers
match request label "Please try a different Browser"
block request quick header "User-Agent" \
value "*"
tls ca key "/etc/ssl/relayd/private/ca.key" password "PASSWORD"
tls ca cert "/etc/ssl/relayd/ca.crt"
}
relay httpproxy {
listen on 127.0.0.1 port 8080
protocol httpfilter
forward to destination
}
relay tlsinspect {
listen on 127.0.0.1 port 8443 tls
protocol httpfilter
forward with tls to destination
}
