On Mon, Mar 9, 2015 at 12:03 PM, Stuart Henderson <[email protected]> wrote: > On 2015-03-06, Felipe Scarel <[email protected]> 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.
