[KLUG Members] passing https through a "firewall"

[Phillip Hofmeister]

On Thu, 22 Jul 2004 at 02:46:03PM -0400, Rusty Yonkers wrote:
> I have a system at one client that I manage that I have setup a box
> to limit the access to the Internet.  I am using DansGuardian and
> Squid for this.  The regular web traffic I am doing a redirect on to
> the port for DansGuardian which then goes to Squid.  This is working
> just fine.  
> 
> The problem that I am having is that anything that is https is not
> going through the box.  I am not doing any other filtering or
> redirecting.  I have the network routing on the linux computer setup
> to allow routing.  The linux box that is between the workstations and
> the Internet is the default gateway for all the computers.  I had it
> working at one time but had rebuilt the box after a pretty serious
> meltdown and I guess I forgot something that I had setup last time.  
> 
> I am at a bit of a loss on this one.

I am pretty sure what you are seeking to do is not possible because of
the nature of HTTPS.  HTTPS is DESIGNED so what you are trying to do is
not possible.

>From what I understand: you are trying to intercept an HTTPS GET
request, and process it using squid, and then return the results to the
client.

HTTPS works like this:

1. Client Connects

2. Server sends public key and SSL Certificate

3. Client checks to make sure the key is signed by a trusted CA to
validate the key really belongs to that server.  If it is not signed by
a trusted CA or something is wrong with the signature (expired, doesn't
match the key, etc.) then the client prompts the user if they want to
accept the certificate and continue the communication.

4. Upon accepting the public key and certificate the client generates a
random session key (usually 40-128 bit), encrypts it with the server's
public key, and sends the now encrypted public session key to the
server.

5. After the two finish negotiating SSL (the above process) the client
submits its request including: the URL it is seeking, the hostname (HOST
header) it is connecting to, any POST data, any cookies, etc.  The
request is sent to the server using the negotiated session key.

6. The server processes the request and sends a response and returns the
results to the client, encrypting it with the negotiated session key
before transmission.

Unless you add a trusted CA key of your own on every desktop, there is
no way for you to accomplish what you are trying because:

A) If the proxy server DOES step in the certificate it presents to the
client will not be valid.
B ) Once the encrypted session has started you will need A LOT of
computing power and a few dozen years to break the encryption so you can
record the transaction.

I hope my lengthy explanation on SSL/HTTPS has helped you in some way.

Take care,

-- 
Phillip Hofmeister