On 25/05/2014 8:07 p.m., John Gardner wrote:
> Hi everyone,
>
> I’d like some advice regarding the using SSL Bump functionality with
> Squid, and ask some questions regarding whether I correctly understand
> what SSL Bump is designed to do. First, however, I’d like describe
> what I’m looking to do so you have some background.
>
<snip>
> Now, at the moment, this functionality is covered by a Microsoft TMG
> instance which uses what they call 'SSL Bridging'. For a number of
> reasons, we now want to upgrade the Squid Reverse Proxy to 3.4 and
> decommission the Microsoft TMG server, so my first question is this;
> Does the SSL Bump functionality in Squid 3.4 replicate the SSL
> Bridging process i.e. The client sends an encrypted request, Squid
> then decrypts the request (A), encrypts it again (B), and forwards it
> to the Web Server. The Web server returns the encrypted object to the
> Squid server, decrypts the object (B), encrypts it again (A), and
> sends it to the client. This is shown below;
> +------------------+
> | |
> | |
> Browser ----- HTTPS (SSL) Connection -----------+ +--------- HTTPS
> (SSL) Connection ----- Web Server
> | | | |
> | A B |
> | |
> +------------------+
> Squid Reverse Proxy
>
> Firstly, I'd just like to confirm that the functionality in SSL Bump
> works as above and then I can decide how to go forward.
No it does not. SSL-bump is the process of forging the certificate.
What you have described about is regular HTTPS.
> I am aware of
> the ethical considerations of using this method and that effectively
> it is just a 'managed' man-in-the-middle attack, but I can't really
> think of any other way to get this to work without it.
A reverse-proxy run as part of the website itself has no forging, MITM,
egal or ethical problems.
* Clients make regular HTTPS connections directy to the CDN /
reverse-proxy.
* The proxy makes regular HTTPS connections to the origin/master server.
What you need to do is add the "ssl" option to your cache_peer line in
squid.conf. <http://www.squid-cache.org/Doc/config/cache_peer/>
Amos
Received on Mon May 26 2014 - 06:42:05 MDT
This archive was generated by hypermail 2.2.0 : Mon May 26 2014 - 12:00:06 MDT