Why encryption may be your worst enemy!

So many people advocate encryption as being the best way to secure data.

To quote from the book of Riley (Steve) "If confidentiality is your priority then go ahead and encrypt your data" (not quite a direct quote but you get the idea). For businesses your security policy SHOULD state how to protect sensitive data - certainly there are cases were encryption is the right thing to do. Just think about web traffic for a moment.....

IF you allow your users to establish outbound HTTPS (HTTP over an SSL transport) then you are relinquishing all possibility of inspecting said traffic for malicious content. Few organisations mandate that outbound HTTPS is disallowed as they allow employees to conduct personal activites such as banking and shopping. IMHO the important thing is for the business to conciously decided whether such activity SHOULD be allowed and ensure that policy and enforcement apply accordingly. You could for example block HTTPS to all but a handful of approved (by you) websites such as those required for your business - these may be those of suppliers partners or customers for example.

IF you allow HTTPS then IMHO ALL security devices are redundant with respect to such web traffic as they can only inspect the packet headers.

Yesterday I was asked to help a customer obtain Internet access from our office hot desk facility. I wonder how many of you are asked similar questions. My first thought was SHOULD THEY BE ALLOWED to connect to our network, WHAT IS THE POLICY for such activity? We use IPSec policies to segment the network traffic flow to/from machines and require that each machine identify itself via Kerberos Authentication. 3rd party machines could still sniff packets (as we use IPSec to authenticate only - no encryption) AND they could deny service to resources via packet storms.

Comments

• Anonymous
  September 29, 2005
  The comment has been removed
• Anonymous
  September 29, 2005
  Absolutely - I totally agree. You Must inspect the payload period otherwise you have a Universal firewall Bypass Port
• Anonymous
  October 05, 2005
  The comment has been removed
• Anonymous
  October 07, 2005
  Nick> Please explain more about your "wildcard certificate" idea as I can't see how your proposal would work. If an internal user wants to browse tohttps://theirbank.com then you'd need the private key associated with the SSL server cert held by theirbank to become MITM
• Anonymous
  October 07, 2005
  As a CA, you can issue domain wide certificates, eg *.microsoft.com would apply to www.microsoft.com, updates.microsoft.com etc
  
  So, you get everyone's browser in your organisation to trust your CA (push it out as a group policy etc). Then, issue a wildcard CA for .com, .org etc to your web proxy.
  
  When someone connects to https://theirbank.com, intercept it. You send to the user a .com wildcard certificate, and all is fine.
  
  SSL MITM like this only works because all the users trust a CA which is handing out overlapping certificates.
• Anonymous
  October 10, 2005
  Nick> Thanks for the detail. IF you can get the users to install your root cert then I can see how that would work. Unfortunately it is pretty easy to get them to do so ;-(
• Anonymous
  October 10, 2005
  I was suggesting the above be done by a company, who can push out their cert via company domain policies. In my experience, getting people to accept a single certificate for a session is easy (probably even for a bank in most cases). Getting them to install a new CA certificate isn't, because they activly have to click through, check trust boxes etc. (I don't know how easy it might be for malware to do it though) If you were an evil-doer, instead of having a blanket .com certificate, you'd simply issue yourself an appropriate certificate each time. So, the user connects to your web proxy with "CONNECT secure.mybank.com 443". Your evil web proxy fires off a new process, generates a certificate for secure.mybank.com, signed by its own CA. It then MITMs you. As a user, you get a popup saying there was a problem with the certificate, and you click through it.
• Anonymous
  October 11, 2005
  The comment has been removed