Does anyone have a working Squid peek-n-splice (with optional splicing with SNI lookup, preferably) config I can test with? I'm having trouble finding clear examples, and stage2 bumping is prompting certificate errors.
Thanks in advance, fbscarel On Tue, Mar 10, 2015 at 5:00 PM, Felipe Scarel <fbsca...@gmail.com> wrote: > On Mon, Mar 9, 2015 at 12:03 PM, Stuart Henderson <s...@spacehopper.org> > wrote: > > On 2015-03-06, Felipe Scarel <fbsca...@gmail.com> wrote: > >> Hello all, > >> > >> I'm currently using relayd as a forward proxy, selectively blocking > >> HTTP and HTTPS requests while doing MitM inspection (as per > >> http://www.reykfloeter.com/post/41814177050/relayd-ssl-interception). > >> > >> To allow certain domains to go through the SSL proxy, a simple 'pass > >> quick url file' is sufficient, and works. However, this option does > >> not prevent the MitM operation from relayd; the request is simply > >> allowed through, and the original certificate is still 'patched' by > >> the local CA. The configuration is shown below: > >> > >> http protocol httpsfilter { > >> tcp { nodelay, sack, socket buffer 65536, backlog 1024 } > >> return error > >> > >> match header set "Keep-Alive" value "$TIMEOUT" > >> match header set "Connecton" value "close" > >> > >> pass quick url file "/etc/relayd.d/custom_whitelist" > >> block url file "/etc/relayd.d/custom_blacklist" > >> include "/etc/relayd.d/auto_blacklist" > >> > >> ssl ca key "/etc/ssl/private/ca.key" password "password" > >> ssl ca cert "/etc/ssl/ca.crt" > >> } > >> > >> relay httpsproxy { > >> listen on 127.0.0.1 port 8443 ssl > >> protocol httpsfilter > >> forward with ssl to destination > >> } > >> > >> This is a problem for a few sites (especially banking websites) that > >> absolutely demand that the original certificate is not tampered in any > >> way. I'm currently solving the problem with pf passthrough rules > >> (allowing traffic directly to destination on a per-IP basis), which is > >> far from an ideal solution as covered previously in > >> > http://openbsd.7691.n7.nabble.com/DNS-lookups-for-hostnames-in-PF-tables-td69546.html > >> (scenarios like round robin DNS, CDNs providing content for multiple > >> organizations, etc.) > >> > >> So, my question is: Is there a way to completely bypass SSL > >> interception for a given URL file? > >> > >> Thanks in advance, > >> fbscarel > >> > >> > > > > relayd doesn't have much information available at the point where it > > decides whether to pick up the request. Specifically it just has IP > > addresses. It can't tell the URL or even the domain name of the request > > to be able to identify the destination. > > > > The domain name *is* available before a full SSL negotiation, at least > > for connections from non-ancient browsers, but it requires opening at > > least the client-side of the connection, and reading the name from the > > ClientHello (this is the first packet sent by the client; server name is > > provided unencrypted by SNI). > > > > It is technically possible to use this information as part of a decision > > process, but it's much more complicated - you first need to identify > > whether interception is wanted, and then either replay the ClientHello > > (and afterwards forward packets directly to the server), or do the > > cert generation/MITM as usual. > > > > relayd doesn't support this yet. > > > > Recent versions of Squid (3.5.x) do; feature is called "peek and > > splice", but I haven't tested it with OpenBSD yet. (Squid's normal > > SSL interception does work, at least in OpenBSD -current). Even then, > > the most you will be able to do is look at the domain name; the URL > > is not available until *after* the SSL handshake, at which point it > > is too late to make the decision whether to spoof the cert or not. > > > > The domain name would do, I'll try testing with Squid. > Thanks for the input, Stuart.
