7 Ways To Deal With HTTPS traffic

HTTPS traffic. It's a bunch of encrypted zeroes and ones flying through our firewalls and web filters, and frankly many people haven't got much of an idea what it's doing or why it's there. There are business critical apps aplenty that require you to let this impenetrable traffic march on, but what can we do to gain a bit of visibility? In a rare moment of caffeine-induced lucidity, I lay out your options:

1. Do Nothing

This is one of my favourite options - complete inaction. Whilst it might seem like it is a safe bet, after a while things start to go wrong. Sometimes, I take this approach to household chores: it's liberating to not do the laundry for a while, but the day you run out of socks is a dark day indeed.
User Impact: *****
Blocking Efficacy: (that's no stars!)
Advice: Only if you like to have problems

2. Block it ALL!

Not a great idea this one. Might have worked in the deep and distant past, but today's Internet will have no truck with that. Back to doing laundry, it's the equivalent of putting up with prodigious and vile body odour because you can't be bothered to wash your smalls. Might have worked in 200BC, but in 2013 you will likely find it a social faux-pas. Apologies to any readers who were eating breakfast while reading that :)
User Impact: (that's no stars!)
Blocking Efficacy: *****
Advice: Don't do it!

3. Look for Reverse DNS

So I want to allow HTTPS traffic through, but I want to be selective. I know - I'll take the destination IP and do a reverse lookup on it, then I can use that to match... I'll be able to control everything. I don't have a sock analogy here - sorry folks (well I do, but it would be stretched thinner than even the most ardent fans of my blogging would take - an exercise for the reader to build their own!). Reverse DNS is basically pretty unreliable. It's OK for spotting some of the big stuff, so you might whitelist based on it, but conversely it's terrible as a whitelist because it is inclined to miss bits. Yes, more of the internet than ever has reverse lookup, but this still sucks.
User impact: *****
Blocking efficacy: **
Advice: Don't do it!

4. Use Plaintext header information to domain block

This is more like it. Anyone using a "traditional" proxy, where you set up the computer to use an HTTPS proxy, can already do this.

Modern SSL implementations are actually TLS implementations - SSL went out of fashion when flared trousers and wearing a baseball cap backwards were the hottest news. TLS is what we are really using when we refer to SSL. Anyhow, there's a cute little extension to TLS called SNI. This method won't work with really ancient browsers.

For those of you still awake, these methods let your web filter block accurately by destination domain. Not URL, domain. Just the first bit. Everything after the / is still mystery meat. This is a reasonable option for blacklist, and a great option if you're whitelisting.
User impact: *****
Blocking efficacy: ***
Advice: No brainer, get it turned on

5. Verify Certificates

You can, and should, check certificate validity on your web filter. It's that simple, really. There's a few gotchas - in that sites with self signed certificated will need explicitly allowing, but otherwise, this is a great idea. One of the main advantages to this method is the blocking of HTTPS proxy anonymizers, which rarely go to the financial trouble of a full, CA signed certificate.
User Impact: ****
Blocking Efficacy: *
Advice: Use in conjunction with another method, but do use it

6. Full Inspection

If you're really keen to protect against the threats of web-borne malware, and you want the best filtering, then this is the gold standard. A "Man in the Middle" decryption allows your filter to see the full URL and content, so you can do fine grained blocking, search term analysis and anti-malware scanning, among other things. Of course your users will see a certificate warning if you do this, as you'll be re-signing a certificate claiming to be facebook.com or whatever. The only way round this is to install your Certificate Authority (CA) on your users' systems. Don't install one that's not got your organisation name in it - some vendors just produce a "standard" CA, and this is really dangerous, allowing the vendor unfettered backdoor access to your clients' browsing. Full inspection can be tricky for BYOD as you have no easy way to push out the CA - so  bear that in mind when deciding how to filter.
User Impact: **
Blocking Efficacy: *****
Advice: Definitley use for machines you can push policy to, advise caution on BYOD

7. The NSA Option

If you are the US government, there's always the option of spending a whole heap of your billions of dollars in black budget breaking everyone's crypto. While this is highly effective, people will then tend to avoid you at social functions, and may talk about you behind your back. But at least you'll know what they are saying.
User Impact: CLASSIFIED
Blocking Efficacy: BLOCKED
Advice: Be afraid