Redirect all outbound port 443 to local Squid proxy port 3128

  • I have a wonderfully working transparent Squid proxy working on pfSense 2.0.2. All outbound port 80 is cached and filtered through squidGuard. Awesome.

    However, lots of warez sites are now serving over SSL, and I've noticed in my access logs that people have used that to get around the filter.

    I set my machine's Firefox SSL proxy to <my-proxys-ip>:3128, and it looks like squidGuard catches the blocked domain, even though it's SSL (port 443). squidGuard's logs confirm this.

    Great! Now, I just want to add outbound 443 to my transparent proxy, so all outbound SSL connections to backlisted domains are also blocked, network-wide.

    I've looked high and low and I can't figure out how to create a rule like this.

    Note: I'm NOT "intercepting" or "sniffing" SSL, I'm just looking to block connections to blacklisted domains.

    Thank you!</my-proxys-ip>

  • So, after grinding away at this for a long time, it seems what I want isn't as easy as it might sound.

    As far as I know, blocking SSL domains works when the client has a proxy explicitly enabled because it uses the HTTP CONNECT method instead of a direct TLS handshake. It's during this CONNECT step that squidGuard can block the domain.

    However, when transparently proxying, no such CONNECT occurs and the client effectively detects a man-in-the-middle attack and freaks out. This is obviously part of the design of TLS, and to my knowledge there is no simple workaround.

    However, this makes absolutely no sense to me, and I'm hoping someone can clarify.

    During the TLS handshake, the client sends the server a ClientHello. Since this handshake process happens in order to create an encrypted session, this packet must be sent in the clear. In order for the ClientHello to reach the server, it must have some kind of destination data, presumably a URL or domain somewhere in the packet header.

    My question is: why the hell can't a transparent SSL proxy simply sniff and deny this ClientHello (and the subsequent TLS session) when it is destined for a blocked domain? Since SSL/TLS happens somewhere between layers 4-7, how is it not possible to block traffic at layer 3, before it becomes encrypted?

    Thank you in advance for clarification!

Log in to reply