Inspecting TLS/SSL passing in/out of a network without specialised device?

Question

At the moment I'm managing a small home office setup - a few PCs and a soft open source x86 *nix based router. I'd like to move traffic scanning / inspection onto an edge device.

The motive is to increase the barrier for undetected malware and suspect traffic, have the main traffic scan separated from any end-user devices, and increase certainty by scanning at the LAN gateway.

At present they use consumer antivirus which effectively scans SSL by creating a fake CA on the PCs. It's a decent brand AV and works but has issues. If it's not too hard they'd like the reassurance that it's approached as an enterprise issue using 'proper' means (their term) rather than PC-based consumer software.

It's clear that malware is increasingly moving to encrypted traffic which - if not scanned - can be indistinguishable from normal https traffic. I can't filter based on endpoint (acceptable endpoints too wide to whitelist, and even 'good' sites can inadvertently host malware) and you don't get much other solid data for encrypted traffic on usual ports.

There's trust and good dialog with the people using it (3 partners, no employees), and they all want this as well as well, so no ethics/consent/privacy issues arise internally. The traffic is low enough (web/email) not to need a high-volume or specialised UTM.

The practical issue in ssl scanning is that SSL is precisely designed to detect and prevent MITM (which is what this is), and therefore scanning needs to rewrite packets with its own CA. That's a pretty bad idea and "breaks" the cert chain so it's best not to... except the only alternative seems to be no scanning at all of any SSL/https which is seen as more risky and potentially worse. Like democracy, it's the worst solution except all the others ;-) For example, as the browser or local device wouldn't be able to verify cert chains, the edge device would have to do this for them, and block or warn if not correct. But in theory if the external cert chain was reliably checked before discarding, then MITM inspection at or next to the gateway could be a safer bet than not scanning SSL at all.

I've looked around and this does indeed seem to be "out there" and used in the enterprise, but usually as a standalone device.

Is there a recognised way to do it without a specialised device?

Update 1:

They are older people, who didn't grow up with computers and still despite their efforts prone to clicking first and worrying after, or the alternative of phoning every time they are in doubt. As with other SMB they also use their work PCs for shopping/browsing/social etc, which adds to the risk - and they know it. SSL scan has caught quite a few things that apparently weren't blocked by the PC based blacklist setup, including apparently legit sites or "nobody knows how". Probably quite sensibly they want to have more comfort going forward even if blacklists would catch "most" things. I think this might be their best way, if I can work out whether it's feasible and how I might do it. If the main objection is "not worth the hassle" then I'd still like to research it so they can think about cost/benefit. But so far all I can find is high-end devices, I can't find if software/FOSS solutions exist for this function, even though one would expect them to. But I haven't been able to find any if so, hence the question.

Answer 1

Yes, they exist. For example, we deploy Watchguard firewalls and the T-series is a very affordable device targeted at a small office (search Google/Bing for model WGT10031-US to get an idea of pricing, I don't want this to seem like a sales pitch). All models have an HTTPS proxy that is capable of SSL/TLS inspection (termed deep packet inspection or content inspection in their docs) Here's the datasheet: http://www.watchguard.com/docs/datasheet/wg_firebox-t10-t30-t50_ds.pdf

And documentation link for the specific feature (sorry for the ugly URL): http://www.watchguard.com/help/docs/fireware/11/en-US/index.html#en-US/proxies/https/https_proxy_contentinspection_c.html%3FTocPath%3DProxy%2520Settings%7CAbout%2520the%2520HTTPS-Proxy%7C_____2

For a software solution you could look at something like Untangle NG Firewall (http://www.untangle.com/untangle-ng-firewall/).

Those are a few examples. I am not aware of any FOSS solutions but that's not an area of expertise for me so I wouldn't doubt that they exist.

Some things to keep in mind if you deploy a solution like this:

• Your endpoints will all need to trust whatever CA certificate is being used to re-sign the certificates that are being sent over HTTPS.
• Some applications will ship with their own certificates and will break with SSL inspection (common culprits are banking applications and remote meeting applications) so you'll need to exclude their traffic.
• Firefox ships with its own copy of certificates for popular sites so even if the device trusts the CA you'll still get certificate warnings in Firefox for many sites without additional configuration.
• In general, set expectations that there will be some initials pains and keep good communication with your users and plan to spend some time troubleshooting broken sites and applications. I would recommend deploying the device/software that you choose first and work out any hiccups with that and treat the content inspection implementation as a separate phase. You don't want to have to troubleshoot multiple modules and proxy rules all at the same time.

Answer 2

You're talking about doing something to TLS that it was entirely designed to prevent. I think you understand that.

Moving beyond that I think you are trying to solve the following problem:

How do I protect users hat are essentially, actively attempting to get infected/compromised?

If everyone at the office is unwilling to comply with IT policies like "don't click that .exe in your email" or "don't watch porn on your company PC" the only safe thing to do is to treat the entire environment as hostile. You have a people problem here and are trying to solve it with technology. It seems you or the company are unwilling to do something more sane like address the personnel issues so..

You work in a hostile IT environment. You need to block everything. If users are concerned about security but unwilling to do their part lock them down to the following as a base:

1. Prevent LAN machines from talking to each other. Clearly the internal network is no more trustworthy than the external
2. Only allow users to communicate with a trusted DNS server. One that you control. One with a black list.
3. Only allow user to communicate out to the world on ports 80 and 443. They lose a ton of functionality but this should mitigate a good portion of malware
4. Only open additional "world" ports on specific destinations.

We generally don't give shopping advice here, but I think you have mostly answered your own question: If you want to do fancy Intrusion Detection within an encrypted protocol like TLS you are probably going to have spend several dollars.

Realistically, the best thing you can do for yourself and that company is to implement Good Cold Backups that can be used WHEN (not if) a compromise occurs