Hi all,

I have an old Ubuntu Edgy (6.10) server that's currently acting as a transparent proxy with squid 2.6.STABLE9 and squidguard.

Everything is working great, except now that many sites are HTTPS, I am being requested to proxy and in some cases block these sites (such as Facebook, porn or proxy sites).

I discovered that our squid was not compiled with the HTTPS option back when it was installed, however I still have the source .tar.gz file that was originally used, and the option is available. I am just not sure where to begin. I have googled extensively over the past several days but I can only seem to find documentation on setting up a transparent HTTPS proxy (which seems to require a certificate), or a reverse proxy, which we do not need. In this case we control all the computers on our network, so a transparent proxy is not necessary. We would like to use domain (destination) based blocking via squidGuard (if possible) or squid ACLs, and do not need to inspect the contents of the packets, so I think we don't need a certificate/MITM. I guess in order to do this, squid should not be in transparent mode. That's about as far as I've been able to get with Google.

What I am not sure about are the exact steps needed to get the configuration I want.

1. If I recompile squid, do I have to uninstall the existing one first? If so, how? It was installed from source, not from a repository.

2. How do I change my IP Tables script so that squid is no longer transparent? Or if this is not necessary, what do I need to do to get HTTPS proxying working in transparent mode?

3. Once I have squid working with https, will squidGuard be able to filter domains/urls like it currently does?

Links to documentation or how-to's would be appreciated. I can't seem to find much for the old squid version I'm using.

Thanks for any insight!

Hi,

First of all, I suggest you to install a recent Linux distro, as Edgy has EOL'ed in 2008!!!
Same goes for your squid version

Regarding your questions:
1. When installing software from sources, you don't need to uninstall the previous version, as the new one will overwrite it.
FYI, you may try running "make uninstall" from inside the old sources directory and if it's available it will uninstall the previous version.

2. For HTTPS proxying you should take a look at the CONNECT method, if want to block certain https sites.

3. I'm not familiar with squidGuard, but I guess it will still work the same way.

As bathory rightly said, load a current version/distro of Linux as your first step. Running on an old OS is just going to build security issues in to your new system. If you load the current version of Ubuntu (18.04 LTS - Long-term support), you can install Squid through the online repositories. To address your questions:

1. Do NOT compile Squid from source; you're just going to give yourself headaches for no good reason, unless you absolutely *NEED* some obscure/bleeding-edge feature. And from what you've said, you don't.
2. There is documentation on how to do this: https://docs.diladele.com/tutorials/...ntu/index.html
3. Yes, Squidguard will still function, but you may have to disable transparent mode (unsure), but pfsense will work as well: https://openschoolsolutions.org/pfse...ps-squidguard/

Back up your current Squid configuration file (although it may not even work with the new version of Squid), *AFTER* you make careful notes about what it's doing. Given the age of your system, do a fresh load of current Ubuntu 18.04 LTS server, load squid, and perform the configuration. Trying to update something so old would be like putting a deadbolt lock on a screen-door....just not much point.

Thanks for the replies. I guess when posting about such an old system I should clarify that it's running on very old hardware from circa the same era (2006, I think). In addition, it uses ReiserFS (which was cutting-edge at the time!), so it's not as simple as upgrading; it would be a tear-down and rebuild, which unfortunately we do not have budget for at the moment. (This is for a not-for-profit). I have already asked (here and elsewhere) about upgrading it, and have been told that the process would be extensive and nearly useless unless we buy new hardware anyway.

So, I'm stuck with it for now.

I think my question 1 is answered. I guess I can recompile squid with the --with-ssl option - is that the only option that's needed for https to work? Do I need the open-ssl or something else too? I will backup my config file first.

For question 2 - I am coming to the conclusion that I can't do this with the transparent setting, because I require a certificate.
@TB0ne - I seem to be having the same issue you are - every single tutorial and how-to I have found is for how to get https to be filtered transparently, of course after the link usually says in capital letters how that's a bad idea and a man-in-the-middle attack on your users. From the tutorial you posted, which is for the Diladele web appliance -
I do not have a certificate, so I don't think I can do it transparently.

Since there are less than 20 workstations it is not a lot of work for me to not use a transparent setup, however I am coming up empty on that subject, even in the official squid documentation. Is doing it transparently really the only way?

This is my current IPTABLES setup with the transparent proxy we have now:
And squid.conf has:
I see from the documentation that I will need to change my squid.conf to something like:
So I should add a similar line to the IPTABLES as above to forward 443 to 3329?

Not at all. You can load current Ubuntu on that hardware with no problems. But plan on backing up all your files, and reformatting your drives. Past that, you should have to spend a grand total of $0.00.
Again, **DO NOT** compile squid from source. There is absolutely NO NEED to do so, when you can install it from the online repositories. If you do that, it'll stay up to date, rather than being in the state it's in now.
Those instructions are for setting it up on SEVERAL distros; CentOS, RHEL, **AND** Ubuntu. Those steps will work just fine, if you ignore the parts that are specific to their package. The second link I sent you has COMPLETE INSTRUCTIONS on setting up pfsense, squid, and squidguard, to do transparent HTTPS proxy.
Follow any of the many guides on how to set Squid up to do this. We can't tell you which ports to forward where, since we don't know how you have your network configured, or if you're going to take advantage of your downtime to reconfigure things. PfSense even has a complete, built image:
https://www.pfsense.org/download/

That would, by far, be the easiest way to go for you, if all this box is going to do is be a proxy server/filter/firewall.

Not wanting to step into the technicalities of recompiling squid, that kit is likely to be 32-bit which rules out (most) current Ubuntu, and the pfsense image. 32-bit support is fast disappearing all round.

You're right, it could be...didn't think of that. 2006 though....could go either way to 32 or 64.

They need to make room in the budget for it. When a system is essential, it needs to be current and safe to use otherwise it is a danger to all operations, non-profit or not. IT is the first thing people cut from budgets, then they end up in this situation. It isn't optional. It's necessary. The people up top need to understand that.

For a fresh install I'm fairly certain that even though 32 bit 18.04 media isn't available, 16.04 is and you can upgrade to 18.04 32 bit from it. Is one option to consider. Either way you need to update the OS before anything else. It isn't just dangerous to your organization, it is dangerous to the entire internet the way it sits now.

Another suggestion I have is if and or when you reinstall, CentOS would be the ideal choice. Better supported for a much longer period of time. Debian is another alternative. Ubuntu is fine but stick with the LTS releases, supported for 5 years at a time. Not the 6 month releases.

Thanks all for your comments. Yes, it is actually 64-bit. I am not saying I won't upgrade the system, as I understand it's badly needed - it's just not going to happen right now, so I hope to at least get squid working with HTTPS for the time being.

One comment about installing squid from a repository. I could be wrong on this, but at least in older versions of squid, SSL was not available in any repository, and the only way to get it at all was to compile it from source adding the --with-ssl option.

At the risk of sounding repetitive, this:
is where I'm having trouble and why I created this thread. I am having a very hard time finding anything on my old version and those that I do find talk about setting it up transparently, for which I need a mysterious certificate I do not have. Not to mention I am happy to do the installation non-transparently. I do find links, like the ones you mentioned for Diladele and PFSense, neither of which I have (my server is command-line only, no GUI even). I can't follow those because they contain instructions specific to their products. Like in the PFsense one, setting up squid and HTTPS filtering involves checking some boxes on their setup screen, whereas for me it's totally different. In the Diladele one, I am supposed to click a link in their interface to install a certificate so I can filter the HTTPS requests. Without being able to do those things, the instructions do not work.

All I need to do is configure IPtables and squid's config file. Either no-one ever does it this way because it's not possible, or I'm seriously overthinking it and it's so obvious that how-tos aren't necessary. Literally all I can find are people trying to figure out how to do it transparently with a MITM certificate.

I am thinking maybe I can do the HTTP transparently and the HTTPS by configuring the clients to use the squid proxy. Doing it that way, I believe I would only have to set IP tables to drop the SSL packets on port 443.

You are not going to have a pleasant experience. If you try to compile new squid/ssl on that old system, you're going to have to update many, MANY packages (probably from source, if you can even FIND them), before you could even compile. And then, you'll *STILL* have a system full of bugs/security holes that you CAN'T patch. Whereas backing up the system, and doing a format/reload would take probably less than two hours. Going your route is an exercise in futility.
You are wrong. HTTPS wasn't as big of a deal years ago, so it wasn't compiled in by default. It has been for some time now.
Sorry, wrong again; re-read those things. PfSense is an ENTIRE DISTRO...you load it, and it has all that you need on it. It is made to be loaded to turn your system into an appliance (like Untangle), to do a few specific things. And the 'mystery certificate'...again, did you read the PfSense docs??? It specifically says
You CREATE the certificate with a couple of mouse-clicks. It's self-signed...you create it yourself, or you can use one that you purchase..up to you.
The only way you can apply web filtering to HTTPS is to intercept it so you can examine it, period. Blocking is trivial. And the reason people KEEP looking (as you say, "Literally all I can find are people trying to figure out..."), is because you **CANNOT** use Squid to filter/proxy HTTPS, period. If it were as simple as what you're saying, people would just do it and not ask. Again, Squid's own documentation (https://wiki.squid-cache.org/Features/HTTPS) says:
A layer 7 filter does this; squid is not a layer 7 filter.

Again: PfSense does everything you need, out of the box, including updating your OS, and giving you the ability to transparently proxy http AND https. The PfSense guide that has complete step-by-step instructions on how to do this. Your system is far too old to be updated with the needed versions of the MANY libraries you'd need to compile current squid and security related things to do https without a LOT of work. Again: you have to spend ZERO DOLLARS ($0.00) to perform the upgrade on your existing hardware, and can be done in probably less than two hours, start to finish, if you load PfSense and follow the instructions. I understand your budget is tight, but if they can't afford $59 for a new hard drive, they have bigger problems than HTTPS proxying.

Something to look out for is that whatever SSL libraries you use to allow you to compile in support for "https" need to be very up-to-date or you may find they don't support TLS1.2 which you WILL need going forward.

1 members found this post helpful.

Okay, thanks for all of the info here. I will do more research on what you have said. Thanks

I think PFSense is not the right solution for us, because this server does a bit more than just act as a firewall/filter; it also manages print queues and shared drives, for example. I have been told more than once that nothing modern will run well on our hardware (IBM Server x3400, similar to https://www-01.ibm.com/common/ssi/cg...um=ENUS107-427 but with 2 GB of RAM).

However, I will test out some distros on LiveCD and see if I can't find something newer that will work.