Jump to content

Massive Security Bug In OpenSSL


sunrat
 Share

Recommended Posts

BTW the RCMP have nailed the perpetrator of the Heartbleed affair at Canada Revenue. 19 year old script kiddie, computer science student at University of Western Ontario. Did not cover his tracks very well. :oops:

His dad is a computer science prof so the kid should have known better, or at least how to cover his tracks better. :rolleyes:

Link to comment
Share on other sites

Alas, since there is no way to tell when a site is attacked (to my knowledge it leaves no traces), we have no way to know whether a site we've visited/registered for has been compromised or not.

 

Adam

Link to comment
Share on other sites

I have not had any of the web sites I frequent contact me suggesting I change my password.

 

I've gotten two so far. One from an online store, and the other from an app developer. I'd think I would get more.

 

Adam

Link to comment
Share on other sites

I heard something somewhere that one of the BSDs was going to tear the code down and sift through the code with a fine tooth comb.

 

I can't look it up here in class, since our internet access is heaviliy filtered.

Link to comment
Share on other sites

Seems to me that the initial 'rush of panic' has been overtaken by admins realizing that wait-a-sec , that version range of OpenSSL is not in operation or that the firewall is taking care of protecting the site. If you look at what it took for the Moscow group to break into the CloudFlare server to get the keys , one finds the CloudFlare firewall was not setup to detect repeated knocking and that it took the Moscow over 9 hours with optimal setups for getting the keys.

So, not that the code goof isn't/wasn't a problem, just the real world facts are such that a lot less people were effected.

 

btw: i keep reading that a Heartbleed siphoning can not be detected, it seems to me the logs can be checked to see if there dozens of attempts to connect to within a minute. Why a firewall setup would allow for that to begin with is another question :)

Link to comment
Share on other sites

Good point. I think it was meant to be said that the server would not have any logs of the "intrusion" but mentioned nothing about firewalls. The attacker would need to send malformed UDP packets to the server. As far as I know, TLS over UDP is not something that is widely used, so the firewall could be easily set to block UDP TLS packets.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...