according to a new network world article, gpcode is back... for those that don't remember it's a piece of malware whose payload encrypts your data and holds it for ransom... you have to either pay the bad guys to get the decryption key or you have to hope that the av vendors figure out how to crack it (and probably pay them for their product so you can use it to decrypt your data)...
this is all misdirected effort, though... for all intents and purposes this is a data corrupting payload - the fact that the transformation it performs on your data is reversible is a red herring meant to make people spin their wheels and eventually capitulate and give the bad guys what they want while distracting you from the fact that a data encryptor is no harder to recover from than a data destroyer...
you're prepared for drive failures, right? you have a plan for when something comes along and hoses your data irrecoverably, right? of course you do, they're called backups... those same backups work equally well against maliciously encrypted data as they do against maliciously or accidentally destroyed data so the question i have for those who are concerned about this new version of gpcode is "what's the big deal?"...
and for those working on a way to crack this thing my question is "why bother?"... for all you know the malware writers screwed up their crypto code again but this time in such a way that the data actually is unrecoverable... and if they didn't screw it up then you'll pile huge amounts of effort into cracking the key and either fail or succeed and force the malware writer to take the rather trivial step of creating a new key and releasing a new version of the malware... why bother making the distinction between this and a true data loss event for the user? if the user has backups they're fine and if they don't then this is the kind of event that they actually need in order to learn how important good backups really are... yes it would suck to be them but this is the real world and the real world has consequences that they need to know about rather than be sheltered from... consequences are what help us learn...
*non-update* (since i found out before i managed to post this article): apparently the folks at kaspersky are trying to organize a combined effort to crack the key... there's still nothing to convince me this isn't a waste of time but i should at least acknowledge the difference in opinion... then again, i suppose businesses have a tough time trying to get away with tough love, so i suppose it does make business sense for them to try and coddle their customers in this way...
Showing posts with label encryption. Show all posts
Showing posts with label encryption. Show all posts
Saturday, June 07, 2008
Monday, March 26, 2007
SSL: hot or not?
peter lindstrom made a post today about SSL that seems to have inspired a lot of discussion among other security bloggers...
one of the main contentious points made was that SSL prevents packet sniffing from being successful but since packet sniffing has never been a threat for websites there's little value there... here i would say peter is seeing the world through SSL coloured glasses in that he sees what the world looks like with SSL but not what it would look like without SSL... lori macvittie correctly points out that in the wireless world packet sniffing is a big deal however she underestimates it's significance to the wired world... dave goldsmith and tyler reguly both seem to recognize that in the wired world the absence of SSL would mean you have to trust every machine your traffic flows through, thereby creating a lot of potential for your confidential network traffic to be viewed by nefarious individuals, but apparently nobody questions the wire itself... the fact is that, other than SSL, there are basically no logical or physical controls either in the cloud (in the case of wireless) or on the wires coming out of peoples houses/businesses... without SSL these would undoubtedly be low hanging fruit...
i'm not going to go point by point as others have, instead i'm going to turn things around and look it from a different angle... the question that needs to be asked, that i think peter was trying to get at, is 'has SSL failed to protect our information (or at least the subset of which that travels across the internet to various websites)?'... the answer is yes it has, but not for the reasons peter seems to think... the reality is that SSL wasn't supposed to protect our information, that was never it's job, SSL provides a secure channel for communication between point A and point B... it has the potential to protect against one kind of attack, not all possible attacks - as peter points out there are other ways to compromise the data but that has nothing to do with SSL or it's ability to do it's job... SSL is part of the puzzle, not the entire thing, and that is why it has failed to protect our information in transit...
there are 2 main avenues of attack that SSL is powerless to prevent: compromise of the end-points and impersonation of the end-points... if the client-side end-point (ex. your computer) becomes compromised (ex. perhaps by malware) then the data that is being sent over an SSL channel can be captured before it gets encrypted and sent to a malicious 3rd party... if the server-side end-point (ex. the website) becomes compromised (ex. again perhaps by malware, or perhaps by some malicious or neglectful person who works for the company that runs the website) then that same data that was sent over an SSL channel can be captured after it's been decrypted at the other end... this is a hard problem, one that a lot of research has gone into over the years and even after all that time there still isn't a perfect answer - and there may never be one... at any rate, preventing the entities at either end of the secure channel from doing bad things with the data is outside the purview of SSL...
likewise, preventing entities that are trying to communicate from establishing a secure channel with the wrong entity (as in a man in the middle attack) is also outside the purview of SSL... SSL makes sure the data is encrypted when it leaves your computer and decrypted when it gets to it's destination... your browser makes sure that destination is who they claim to be (checks the site's certificate) and warns you before establishing the SSL session if that doesn't seem to be the case... what nobody checks is whether the 'who' that that destination claims to be is the same as the 'who' you were trying to communicate with... just because i am who i say i am doesn't mean that i am who you were intending to contact or that i am trustworthy in any way - the fact that extended validation certificates exist at all underscores how meaningless regular certificates have become due to them being handed out too freely... EV certs aren't really going to solve this problem, by the way - as i've written before people just don't notice when things are missing, they don't verify that the cert is the right one for the site they intended to visit, and the computer can't really do that verification for the user (at least not in general)... there has to be some way for the points at either end of a secure channel to authenticate themselves to each other or else you can't know that the channel that SSL is securing is the entire channel involved in the communication... this is also a hard problem to solve, but it's a little better defined than compromised end-points...
so is SSL useless because it doesn't solve these parts of the problem? no, we're definitely better off with SSL than without - but at the same time there's still a lot of the puzzle left to be solved so the information we're sending across the internet is not yet secure...
one of the main contentious points made was that SSL prevents packet sniffing from being successful but since packet sniffing has never been a threat for websites there's little value there... here i would say peter is seeing the world through SSL coloured glasses in that he sees what the world looks like with SSL but not what it would look like without SSL... lori macvittie correctly points out that in the wireless world packet sniffing is a big deal however she underestimates it's significance to the wired world... dave goldsmith and tyler reguly both seem to recognize that in the wired world the absence of SSL would mean you have to trust every machine your traffic flows through, thereby creating a lot of potential for your confidential network traffic to be viewed by nefarious individuals, but apparently nobody questions the wire itself... the fact is that, other than SSL, there are basically no logical or physical controls either in the cloud (in the case of wireless) or on the wires coming out of peoples houses/businesses... without SSL these would undoubtedly be low hanging fruit...
i'm not going to go point by point as others have, instead i'm going to turn things around and look it from a different angle... the question that needs to be asked, that i think peter was trying to get at, is 'has SSL failed to protect our information (or at least the subset of which that travels across the internet to various websites)?'... the answer is yes it has, but not for the reasons peter seems to think... the reality is that SSL wasn't supposed to protect our information, that was never it's job, SSL provides a secure channel for communication between point A and point B... it has the potential to protect against one kind of attack, not all possible attacks - as peter points out there are other ways to compromise the data but that has nothing to do with SSL or it's ability to do it's job... SSL is part of the puzzle, not the entire thing, and that is why it has failed to protect our information in transit...
there are 2 main avenues of attack that SSL is powerless to prevent: compromise of the end-points and impersonation of the end-points... if the client-side end-point (ex. your computer) becomes compromised (ex. perhaps by malware) then the data that is being sent over an SSL channel can be captured before it gets encrypted and sent to a malicious 3rd party... if the server-side end-point (ex. the website) becomes compromised (ex. again perhaps by malware, or perhaps by some malicious or neglectful person who works for the company that runs the website) then that same data that was sent over an SSL channel can be captured after it's been decrypted at the other end... this is a hard problem, one that a lot of research has gone into over the years and even after all that time there still isn't a perfect answer - and there may never be one... at any rate, preventing the entities at either end of the secure channel from doing bad things with the data is outside the purview of SSL...
likewise, preventing entities that are trying to communicate from establishing a secure channel with the wrong entity (as in a man in the middle attack) is also outside the purview of SSL... SSL makes sure the data is encrypted when it leaves your computer and decrypted when it gets to it's destination... your browser makes sure that destination is who they claim to be (checks the site's certificate) and warns you before establishing the SSL session if that doesn't seem to be the case... what nobody checks is whether the 'who' that that destination claims to be is the same as the 'who' you were trying to communicate with... just because i am who i say i am doesn't mean that i am who you were intending to contact or that i am trustworthy in any way - the fact that extended validation certificates exist at all underscores how meaningless regular certificates have become due to them being handed out too freely... EV certs aren't really going to solve this problem, by the way - as i've written before people just don't notice when things are missing, they don't verify that the cert is the right one for the site they intended to visit, and the computer can't really do that verification for the user (at least not in general)... there has to be some way for the points at either end of a secure channel to authenticate themselves to each other or else you can't know that the channel that SSL is securing is the entire channel involved in the communication... this is also a hard problem to solve, but it's a little better defined than compromised end-points...
so is SSL useless because it doesn't solve these parts of the problem? no, we're definitely better off with SSL than without - but at the same time there's still a lot of the puzzle left to be solved so the information we're sending across the internet is not yet secure...
Subscribe to:
Posts (Atom)