On 2016-06-14, Ted Wynnychenko <ted....@comcast.net> wrote: >>From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of > Stuart Henderson >>Sent: Tuesday, June 14, 2016 12:31 PM >> >>On 2016-06-14, Ted Wynnychenko <ted....@comcast.net> wrote: >>> This really isn't a big deal; but as more sites have started using https, >>> and > as >>> tools such as relayd and squid (and others?) have developed ways to "inject" >>> https certificates on the fly, I am wondering if there is a way to create > https >>> certificates based solely on the requested URL in a connection attempt using > an >>> internal CA to avoid the certificate errors with blocked HTTPS connections? >> >>How are you identifying connections to block? > > I block connections based on a list from malwaredomains.com. A script runs > nightly that downloads the list/changes, creates zone files, and reloads > unbound/nsd. The "blocked" zone files point those domains at an internal > (10.0.x.x) IP address.
OK, so in that case you don't need anything special to grab the hostname from SNI. I think you should be able to run an https server at the address you're giving in the "blocked" zone, and have relayd intercept traffic for that address (use PF to divert traffic to it, use "ca key XX" in relayd.conf as described in the relayd.conf(5) bit talking about "TLS inspection mode", and I think you need to have relayd lookup the original destination address, i.e. your 10.0.x.x address, via "forward with tls to" for this to work). Alternatively sslsplit (in packages) should also be able to do something similar, in this case you can do it without PF divert, just have it listen on the 10.0.x.x address port 443, and send all connections to an http daemon running on localhost. Alternatively you should be able to do this with squid ACLs but that would be more appropriate for a setup where squid sees all traffic and does ACL lookups (i.e. without the DNS trick) rather than just receiving the banned traffic. .. > From my looking, it appears that a certificate is only accepted by browsers > with > "one level" of domain wildcard present; so I am not sure how to get a > certificate with a common name of * to be accepted for any/every domain. Exactly. Wildcards cover one level only. You can do *.example.com but if you want to cover host.subdomain.example.com your certificate also needs to contain *.subdomain.example.com.
