In light of the recent "FREAK" vulnerability, in which web servers and web browsers can be cajoled into using older, more vulnerable ciphers in encrypted communications, we would like to assure customers that the web server configuration on an up-to-date Smoothwall system is not vulnerable to this attack.
Similarly, if you are using "HTTPS Decrypt & Inspect" in Smoothwall, your clients' browsers will afforded some protection from attack, as their traffic will be re-encrypted by the web filter, which does not support downgrading to these "Export Grade" ciphers.
We all work in the internet security industry, and as such we're involved with a wide range of technologies, markets and people.
Our collective blog is a space for our insights, observations and interests...
(N.B. The opinions expressed here are those of the individual authors, and not those of Smoothwall ltd or Smoothwall inc.)
Showing posts with label ssl. Show all posts
Showing posts with label ssl. Show all posts
Thursday, March 5, 2015
Friday, August 22, 2014
Security: Hard to Get Right!
Couple of interesting articles doing the rounds this week, which are worthy of a quick comment!
Heartbleed: the bug that keeps on giving
Reports suggest that the Heartbleed vulnerability was involved in a breach of over 4 million records from a health provider in the US — we won't see many of these, as identifying the culprit as Heartbleed is really difficult in most cases. That instances like this are still cropping up reminds us of the need to ensure we're patched, and not just in the obvious places like a web server. This time it seems to have been SSL VPN at the heart of the issue, so to speak.
Passwords: why are we still so rubbish at this?
Apparently 51% of people share a password. This is properly daft. Really, crazier than a box of weasels. Even if you trust the other person, there's no telling what accidents might occur, or where they may re-use that password themselves. I always get gyp from my wife that I won't tell her my passwords, but I won't — and believe me, I do pretty much everything else she tells me!
EU "right to be forgotten" rule still here, still a waste of time?!
Internet numptys are still asking Google to remove them from searches in their droves. Happily the BBC is kind enough to reveal who they are by linking us to the relevant articles. When will people realise that once you publish something on the Internet, it is there forever. Unless it's that really useful document you bookmarked last week, which now 404s and was never in the Internet archive. Yes, that one.
Heartbleed: the bug that keeps on giving
Reports suggest that the Heartbleed vulnerability was involved in a breach of over 4 million records from a health provider in the US — we won't see many of these, as identifying the culprit as Heartbleed is really difficult in most cases. That instances like this are still cropping up reminds us of the need to ensure we're patched, and not just in the obvious places like a web server. This time it seems to have been SSL VPN at the heart of the issue, so to speak.
Passwords: why are we still so rubbish at this?
Apparently 51% of people share a password. This is properly daft. Really, crazier than a box of weasels. Even if you trust the other person, there's no telling what accidents might occur, or where they may re-use that password themselves. I always get gyp from my wife that I won't tell her my passwords, but I won't — and believe me, I do pretty much everything else she tells me!
EU "right to be forgotten" rule still here, still a waste of time?!
Internet numptys are still asking Google to remove them from searches in their droves. Happily the BBC is kind enough to reveal who they are by linking us to the relevant articles. When will people realise that once you publish something on the Internet, it is there forever. Unless it's that really useful document you bookmarked last week, which now 404s and was never in the Internet archive. Yes, that one.
Monday, November 19, 2012
Block or Unlock?
With facebook's announcement that they're slowly opting all their users into HTTPS, yet another large chunk of the web gets a welcome layer of encryption.
Welcome, of course, as it helps protect users' highly personal data - often all to recoverable by network sniffing tools, and decreases the possibility of cookie hijack. It's by no means perfect, but it's a great addition.
On the other hand, this SSLization of the web universe does pose a threat in businesses and schools alike - with more traffic going over HTTPS, the requirement for web filtering to intercept and decrypt this traffic rises. In many instances, the stark choice is to either block a site completely, or perform an intrusive "Man in the Middle" inspection. These issues are always going to be most keenly felt on BYOD devices where the MitM decryption would be both more intrusive technically, and socially - hey, it's my device, my traffic, keep out!
There are no silver bullets here. Sure, we can identify most HTTPS traffic's ultimate destination (it's facebook, it's google), but many organisations need a finer level of policy of they are to allow these sites - forcing safesearch is an important one for Schools, or for businesses, maybe a restriction on facebook posts.
The creeping tide of HTTPS is not going away - the only thing keeping more large sites from going fully SSL is the cost/speed tradeoff (encryption on that scale can be computationally expensive), but the need for web filtering for an ever more varied set of organisations has yet to wane either.
This is going to be a long and interesting ride... and I would welcome any comments from our readers on what they are doing to work around these problems, or what they think would be the ideal scenario.
Welcome, of course, as it helps protect users' highly personal data - often all to recoverable by network sniffing tools, and decreases the possibility of cookie hijack. It's by no means perfect, but it's a great addition.
On the other hand, this SSLization of the web universe does pose a threat in businesses and schools alike - with more traffic going over HTTPS, the requirement for web filtering to intercept and decrypt this traffic rises. In many instances, the stark choice is to either block a site completely, or perform an intrusive "Man in the Middle" inspection. These issues are always going to be most keenly felt on BYOD devices where the MitM decryption would be both more intrusive technically, and socially - hey, it's my device, my traffic, keep out!
There are no silver bullets here. Sure, we can identify most HTTPS traffic's ultimate destination (it's facebook, it's google), but many organisations need a finer level of policy of they are to allow these sites - forcing safesearch is an important one for Schools, or for businesses, maybe a restriction on facebook posts.
The creeping tide of HTTPS is not going away - the only thing keeping more large sites from going fully SSL is the cost/speed tradeoff (encryption on that scale can be computationally expensive), but the need for web filtering for an ever more varied set of organisations has yet to wane either.
This is going to be a long and interesting ride... and I would welcome any comments from our readers on what they are doing to work around these problems, or what they think would be the ideal scenario.
Subscribe to:
Posts (Atom)