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

Caveat scriptor - the further perils of a social networker

Caveat scriptor! (Writer Beware!)

We mentioned a few times the problems that you might run into if you post something online without really thinking it through. It can go much further than a red face next time you see friends.

What’s bad for the individual can also be bad for the organisation too – vicarious liability (that we've mentioned many times) can mean that if an organisation can’t demonstrate that its’ trying to monitor and manage access it too can be considered liable for its employees actions. The real kicker here is that the organisation can’t even use the defense that it was unaware of the behavior, the law expects that sensible precautions will be taken.

The message was hammered home this week with the results of the Freedom of Information request to the Student Loan Company about misuse of social media. The response showed that there had been 4 cases (over 5 years) where disciplinary action had been taken. Although the details in the response are scant, there are indications that these individuals were using personal accounts.

Cue the debate about your right to say what you like and why should an employer be able to discipline (in these four cases – dismiss) you for what you say? It comes down to a question of whether you’re representing your employer – a question that was tested in the Adrian Smith case last year.

Essentially the test is this – would a reasonable person viewing your Blog / Wall / Tweets associate you with your employer. If they would then you suddenly need to be a lot more careful about what you say. Someone who finds your opinions objectionable may be also take action against your employer and it’s likely that they would then want to take action against you.

What’s the answer – keep your online work and your social life separate or be prepared to be squeaky clean if you don’t.

For the employers out there -  a strong Acceptable Usage Policy, combined with control of access to Social Media over your network, something that web filters are pretty good at, is a good start for a defense against vicarious liability.

Overall everyone must remember that once something is in print, be that electronic or hard copy it’s almost impossible to get back. As the Duke of Wellington said “Publish and be damned”