Search squid archive

Re: Reverse Proxy and SSL Bump: Advice and Questions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux