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.
