Sorry to dredge this back up from a month ago, but I wanted to get some
clarification.
If I wanted to have a gateway that accepts https connections from clients
and then proxies them over to https servers am I just out of luck? Is it
that it cannot be done at all, or just that it cannot be done with relayd
and there is some other tool I should look at.
I'd like to look at making an open version of an Application Layer Firewall
(as required by the PCI DSS). Ideally, I would be able to have clients
connect to port 443 on the OpenBSD gateway and the OpenBSD gateway would
decrypt the traffic, reassemble it, run it through snort, and maybe check
the headers for some expected values. Then if everything is good, open a
connection to the server and pass the traffic on. Can it be done on
OpenBSD? Where do I need to look to learn more? I've poured over the
documentation for relayd and pf, but I'm not seeing the ability to do what
I'm talking about here.
It probably sounds like Man in the Middle mode described below. You're
right, dealing with bad certificates would be a pain in the butt. Maybe we
could require the firewall admin to provide the certificate that is expected
from the server. So whether it is bad or not, it has to match what the
firewall was expecting or the host is considered down and taken out of
rotation.
Kevin
On Mon, Feb 9, 2009 at 4:15 PM, Stuart Henderson <s...@spacehopper.org>wrote:
> On 2009-02-09, kevin thompson <kevin.david.thomp...@gmail.com> wrote:
> > Is there something in my configuration file that I need to specify to
> ensure
> > that https requests are sent to the servers? I've looked at a few
> examples
> > online and I haven't seen anything that fits the bill. Here is my
> > relayd.conf file
>
> basically it looks like you want to decrypt, adjust the headers,
> and then re-encrypt to the server.
>
> relayd doesn't have this feature (mitm mode? :-)
>
> it could probably be added as an option to "forward to" for a
> relay, but this would bring some questions about how to handle
> invalid certificates at the backend server, etc... (and without
> safe ways to handle that, you might as well keep the cleartext
> to the backend).
>
> with what's currently available in relayd, you would have to
> use a plain TCP relay for HTTPS.
>
> > table <ssl_server> { www.mnsu.edu, secure.mnsu.edu }
> > web_port="80"
> > ssl_port="443"
> > bge0_ip="134.29.32.88"
> >
> > interval 10
> > timeout 200
> > prefork 5
> > log updates
> >
> > http protocol "httpfilter" {
> > # TCP Performance options
> > tcp { nodelay, sack, socket buffer 65536, backlog 100 }
> >
> > # Return HTTP/HTML error pages
> > return error
> >
> > # allow logging of remote client ips to internal web servers
> > header append "$REMOTE_ADDR" to "X-Forwarded-For"
> >
> > # Set keep alive timeout to global timeout
> > header change "Keep-Alive" to "$TIMEOUT"
> >
> > # Close connection upon receipt
> > header change "Connection" to "close"
> >
> > # Anonymize webservers name/type
> > response header change "Server" to "Something"
> >
> > # SSL options
> > ssl { sslv3, tlsv1, ciphers "HIGH:!ADH", no sslv2 }
> > }
> >
> > relay web_proxy {
> > listen on $bge0_ip port $ssl_port ssl
> > protocol "httpfilter"
> > forward to <ssl_server> port $ssl_port mode loadbalance check https
> "/"
> > code 200
> > }
