Results 1 to 7 of 7

Thread: Is squid hierarchy and ssl secure?

  1. #1
    Join Date
    Jun 2008
    Posts
    232

    Default Is squid hierarchy and ssl secure?

    Hey all

    In an attempt to circumvent a (probably poorly configured and) not-so-transparent transparent proxy that has appeared upstream, I have elected to extend my existing squid cache to include my own parent cache out on the Internet.

    My browsing chain now looks like so:
    me -> local child squid -> some internet -> parent squid -> more internet -> web site

    I initially configured my child squid to prefer parent, but this still resulted in gateway timeouts for requests that went direct, so I opted to force everything through the parent, ssl connections included. Surprisingly (or not), my internet browsing performance has actually improved, even though I've added an additional layer between me and my destination web sites. Go figure...

    This raises a couple of security concerns though.

    Firstly, if I connect https, and I get my little padlock in my browser, my data is still encrypted end-to-end right? Even though it's going through a couple proxies en-route, right?

    Secondly, apart from someone sniffing the unencrypted packets entering and exiting my parent squid, am I opening myself and others in the 'me' category to any inherent security flaws with such a setup?

    I considered ssl'ing all the traffic between child and parent squids, but my reading and research on configuring ssl->ssl cache_peers led me to deduce that even if I succeeded, doing so would cause problems with normal ssl connections. And then I figured, what's the point anyway? The packets coming out of the parent squid have to be unencrypted to make sense when submitted to the destination anyway. So all the ssl'ing in the world between proxies will be negated by simply watching what comes out the parent.

    Not that I could get my local squid past a 'FATAL: Bungled squid.conf' on any ssl related option that I handed to the cache_peer directive either.

    Appreciate the community's thoughts on this.

    Chris
    Last edited by chriss; 10-21-2009 at 06:21 PM. Reason: BOFH #452: Somebody ran the operating system through a spelling checker.

  2. #2
    Join Date
    Jul 2007
    Location
    127.0.0.1
    Posts
    392

    Default

    Your https connections are not traveling through the proxies if they're setup as "Transparent" proxies. In order for squid to cache data over https, they'd have to perform a 'man in the middle' attack to decrypt the data, cache it, then re-encrypt for delivery to the client.

    Anyway, if you perform a packet capture for tcp:443, you'll notice the content is coming from the remote destination rather than your remote/upstream proxy.

    For validation, see:
    SquidFaq/InterceptionProxy - Squid Web Proxy Wiki

    -edit-
    Couldn't help myself (I <3 deb)
    http://lists.debian.org/debian-user/.../msg01434.html
    Last edited by GuyPatterson; 10-22-2009 at 01:30 AM.

  3. #3
    Join Date
    Jun 2008
    Posts
    232

    Default

    Maybe a bit of misunderstanding here. In my setup, the proxies are not configured to be transparent. The browsers in the "me" category must be configured with the proxy and port in order to see the internet. Port 80 is blocked by default at the default gateway.

    Other than that, everything else you're saying is consistent with how I always understood proxies and ssl to work, in that ssl goes direct and isn't proxied, yet my squid logs are showing me different (or I'm not interpreting them correctly, also a possibility).

    Here are some logs from the child cache:
    Code:
    1256187473.155  27814 [clientip] TCP_MISS/000 21039 CONNECT [dest hostname]:443 - DEFAULT_PARENT/[parent hostname] -
    1256187473.335  21096 [clientip] TCP_MISS/000 40648 CONNECT [dest hostname]:443 - DEFAULT_PARENT/[parent hostname] -
    1256187473.759  17347 [clientip] TCP_MISS/000 2427 CONNECT [dest hostname]:443 - DEFAULT_PARENT/[parent hostname] -
    1256187473.847  17425 [clientip] TCP_MISS/000 2427 CONNECT [dest hostname]:443 - DEFAULT_PARENT/[parent hostname] -
    1256187474.431  17991 [clientip] TCP_MISS/000 2427 CONNECT [dest hostname]:443 - DEFAULT_PARENT/[parent hostname] -
    And some from the parent cache:
    Code:
    1256187569.361  24837 [child ip] TCP_MISS/200 20728 CONNECT [dest hostname]:443 - DIRECT/[dest ip] -
    1256187569.541  20201 [child ip] TCP_MISS/200 40337 CONNECT [dest hostname]:443 - DIRECT/[dest ip] -
    1256187569.965  16211 [child ip] TCP_MISS/200 2116 CONNECT [dest hostname]:443 - DIRECT/[dest ip] -
    1256187570.049  16255 [child ip] TCP_MISS/200 2116 CONNECT [dest hostname]:443 - DIRECT/[dest ip] -
    1256187570.637  16188 [child ip] TCP_MISS/200 2116 CONNECT [dest hostname]:443 - DIRECT/[dest ip] -
    Now the http protocol says the following about the CONNECT method:
    Quote Originally Posted by rfc2616
    9.9 CONNECT

    This specification reserves the method name CONNECT for use with a proxy that can dynamically switch to being a tunnel (e.g. SSL tunneling [44]).
    So it looks like it's just passing the traffic along (not caching anything), which is pretty much what I hope to be happening, but I haven't got to the packet sniffing level yet to confirm this.

    I guess that's my only option if I want to be sure.

  4. #4
    Join Date
    Jul 2007
    Location
    127.0.0.1
    Posts
    392

    Default

    Quote Originally Posted by chriss View Post
    I guess that's my only option if I want to be sure.
    Agreed. If you can run tcp dump on the "parent squid", fire up gmail over https, start a chat, and ...
    Code:
    tcpdump -lnni eth0 -w dump -s 0 port 443 and host 254.254.254.254
    Replace "eth0" and 254.254.254.254 with the appropriate values. You'll know right away if the connection is traveling securely through the parent squid.

    Guy

  5. #5
    Join Date
    Jun 2008
    Posts
    232

    Default

    Quote Originally Posted by GuyPatterson View Post
    Agreed. If you can run tcp dump on the "parent squid", fire up gmail over https, start a chat, and ...
    So I did some packet inspection of the https traffic and it looks good. Nothing visible apart from the destination FQDN that appeared in a couple of packets.

    To confirm, I repeated the exercise, but checking http traffic to the same destination instead and of course it was all highly visible.

    So that answers my first question.

    Any other security considerations I should be concerned with? I realise that if the box is compromised, then it's game over, but is there anything else I'm missing here. Just seems too easy is all...

  6. #6
    Join Date
    Jul 2007
    Location
    127.0.0.1
    Posts
    392

    Default

    Aside from being compromised (which you already mentioned), my only concern would come from anyone else with access to the squid proxies. However, I don't trust anyone so that may not apply to your situation If you're really paranoid, you may want to consider implementing a virtual private network for an added layer of encapsulation. Remember, security is a myth; hackers are real. Other then that, you probably have very little to worry about. Sounds like you did a good job.

    So - what are you going to do about DNS traffic? If your intention is to keep a nosy ISP on a need to know basis, tunneling DNS queries is definitely an area worth looking into.

  7. #7
    Join Date
    Jun 2008
    Posts
    232

    Default

    Quote Originally Posted by GuyPatterson View Post
    However, I don't trust anyone so that may not apply to your situation
    We're singing from the sane hymn sheet here.
    Quote Originally Posted by GuyPatterson View Post
    If you're really paranoid, you may want to consider implementing a virtual private network for an added layer of encapsulation.
    I'd considered that, but pretty much discarded it for two reasons. It would only apply to clear text traffic in transit between proxies, but the text would be released in clear text once it exited the parent anyway. The only traffic I really care about protecting is the https traffic and the perceived overhead of encapsulating that within another layer of security didn't seem efficient, nor effective.
    Quote Originally Posted by GuyPatterson View Post
    Remember, security is a myth; hackers are real. Other then that, you probably have very little to worry about. Sounds like you did a good job.

    Quote Originally Posted by GuyPatterson View Post
    So - what are you going to do about DNS traffic? If your intention is to keep a nosy ISP on a need to know basis, tunneling DNS queries is definitely an area worth looking into.
    I don't really think the ISP's intentions stem from a snooping standpoint, but probably more from a misguided attempt to save bandwidth if anything. I say 'misguided' because my own experience with attempts at caching to save bandwidth in recent years is that it's a waste of time, what with the vast majority of content being dynamic these days. Even supposedly static content like mp3's avi's etc. are still wrapped in dynamically generated urls or hidden within php frontends. Different story ten years ago when everyone was still publishing static html content. Could be wrong, but that's been my experience.

    So I don't think I need to be too concerned about hiding my activities. I don't think that's what they're after, and even if they were, I don't have anything to hide anyway.

    I still have to contact my ISP and raise my concerns regarding the problems this daft box is causing though, so I'll be sure to find out their intentions when I get around to doing that. I suspect it's just a case of a misconfiguration somewhere, but my faith in them finding it quickly enough for my liking is low. Hence, I had to first implement my technical 'improvements' so I can still enjoy myself while they work out the problem.

    Thanks for the input as well. It's much appreciated by me and I feel it's always useful to share these issues out in the open and leave footprints for google to track and others to find...

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •