The others are mostly porn sites, link shorteners, non-english or others people normally wouldn't have an account/put private data on. These are the sites I feel have the most significance on the list, sorry if I missed any.
We fixed it earlier today. Interesting wrinkle was that our SSL cert provider's web site was also vulnerable. We had to wait for them to update before reissuing the SSL certs.
This is the problem with a monoculture in security libraries. Back when the gnutls vulnerability came up earlier this year, some people seriously stated that we should only have one tls library and that would ensure the security of it.
Find a vulnerability in a browser, and a minority subset of all users get effected. Find a issue with openssl, and key to the kingdom is there.
Security by obscurity is also, arguably, a good thing by your logic.
Seeing as someone didn't get it... Security by diversity is secure in the same way something is secure by obscurity. In other words, its not, its just harder to find the insecurity.
Security by diversity means that any extreme rare vulnerability will only hit a few individuals. The trade is that there will be more unique vulnerabilities found.
In risk management, having risk spread out is general a favored tactic. Same is true in biology. The chance that remote memory access vulnerability is so rare, that 200 libraries (if equally used) would lower the effected number of people with a factor of almost 200.
I'm not exactly disagreeing with you here. I just dont understand how that is different from obscuring your attack surface making you less likely to be targeted by some sort of mass generic attack vector.
Nobody argues security through obscurity doesn't work in some form, we argue that it doesn't make you secure as a matter of fact. Much like using some obscure SSL implementation. It sure does have the net effect of making you less likely to fall victim but that isn't security that is obscurity.
It's not about "obscure SSL implementations", it's "alternative implementations", and letting different projects theoretically play off each others strengths and mitigating consumer risk similar to investing in an index or mutual fund rather than all-in with any single entity.
Also, there's nothing wrong with security through obscurity, but please don't let that be your only security.
As someone else has already pointed out that could be better classified as risk management than the way I originally put it.
The problem with security through obscurity is that it is not security. Kind of what people mean when they bring it up.. At least in my circles anyway.
It is fine to have security through obscurity but you can't, much like the alternative implementation scenario claim it makes you more secure as a result. Its exactly like when apple claimed they were more secure and couldnt get viruses like their PC counterparts.
That is what I was trying to bring to the conversation when I made my first post. I get the feeling were starting to move off topic / split hairs over words now so I'm going to leave it at that I dont think I can explain myself any further.
> The problem with security through obscurity is that it is not security.
I'm sure we'd like each other if we sat down over coffee, and would find more in common than, not, but I have to politely disagree with you here. It does offer a degree of security, and I can give you a challenge that is measurably testable:
Move your sshd from 22 -> (eg) 222, and watch the hack attempts disappear.
Now, in the context of "remote logins", moving telnet from 23 -> 223 offers a _degree_ of security from a casual person connecting to port 23 and trying their luck, but we all know that telnet is a poor remote access tool these days. Switching from telnet to ssh is security by technology (encryption, mechanism (ie: keys vs passwords)). Moving sshd from port 22 -> 223 keeps that many more people from knocking on the door, no matter what other security is setup. "Security by Obscurity" adds to "Proper" security.
Surely we're both on the same page that, given better options, security solely through obscurity is stupid.
Risk management and security is two sides of the same coin.
Lets make an analogy of an investor. If person invest in a single company and it goes bankrupt, the investors might loose his roof over his head and the food on the table. This in turn effects his personal security.
In order to mitigate this risk, he uses risk management to diversify his risks. He might not be able to spend the same amount of time per investment and this increasing the general risk, but high risk events like bankruptcy is spread out and is unlikely to cause a large impact.
It's harder to get a generic exploit that will give you access to a lot of targets. But I'd argue that finding an exploit for a particular target would be easier.
If each of those where equally used, and same with different key handling system, security by diversity would help. For example, the gnutls vulnerability only effected x509 resolving of the certificate chain, so those handful of people who use the pgp model were not effected.
Sadly, even if those options are available, gnutls is not common on the web, and https with pgp is even less common. Worse, some propose that we should use such options less in favor of one and only one library in the name of security.
This will be similar to the trendnet webcam "/anony/mjpg.cgi" ordeal. To this day there are still many webcams on the internet that can be viewed by anyone and the owners of the webcam have no idea whatsoever.
We're going to have fallout from this for at least the rest of this year and well into the next.
I'm sure all the serious sites will be updated soon. But what I'm more worried about is all those routers. My home router has an admin interface that's served over SSL. I'm not so confident in that manufacturers will push out updates for those routers quickly, or that people will update them at all.
Hah, I'd be glad if my router used SSL. If anyone wants to fire up binwalk and run it over a few router firmwares, it'd make for an interesting blog post.
The largest Australian bank (commbank) was reporting as vulnerable on filippo.io/Heartbleed/ for some hours after the vulnerability became known. GE Money Australia haven't fixed their vulnerability yet either.
When I look up my site on alexa, the traffic stats are pretty close to what my analytics are telling me. So, they seem to be reasonably useful, if nothing else in a relative form.
If someone builds this, please do not make the client actively poll the sites visited. Doing so seems likely, IMHO, to land you or even your users in jail for Computer Fraud and Abuse violations (e.g. someone visiting healthcare.gov).
Right but exploiting Heartbleed to dump memory of the target webserver is most likely "unauthorized use of a computer system" and thus in violation of the CFAA.
Can't you just check if heartbeat is enabled and poll what version of library is used? If no, could you check by setting the payload size lower than the payload? That way you know the site is vulnerable without receiving anything you shouldn't have received.
I'm hoping to find a list of largish sites that were vulnerable to this bug just prior to the recent disclosure, so that I can know how to prioritize my password changing. (These forced password rotations are happening quite a lot these days.)
I've been looking everywhere for an answer but this may just be right place to ask.
What can a user or a client do to protect itself?
Sites can patch things up (some sooner and some later). But meanwhile, what measures should the client take while waiting for the sites to be patched up?
So only a little over 12% is still vulnerable (and possibly ~30% not using OpenSSL). And that number is still shrinking quickly.
For example: Netflix, Yahoo, NASA and OKCupid have updated in the mean time.
1.) If it was made in the US, probably not. Reading the memory of a webserver would be pretty easy for a lawyer to argue is "unauthorized use of a computer system." That is the basic definition presented in the Computer Fraud and Abuse Act.
2.) I don't know enough to be able to argue one way or another on this point. However, if you download the list or disseminate the list you are likely increasing your possible exposure.
Many servers will still be vulnerable, so now you have 2 problems.
Zawinski meme aside, perhaps it would make sense to do it on a server-by-server basis when the machines are verified patched. (Though, even then, how do you know they aren't passing information back to an Internet-exposed-but-unpatched database server?)
If you logged in (as in, typed your username and password) in to the site during the time the exploit has been disclosed and the site has been vulnerable, I would change your password.
Otherwise, insist that the site owners invalidate all existing sessions.
yahoo.com indiegogo.com metacafe.com mybet.com nascar.com okcupid.com pch.com paypal-community.com browserstack.com creditkarma.com nasa.gov twitpic.com
The others are mostly porn sites, link shorteners, non-english or others people normally wouldn't have an account/put private data on. These are the sites I feel have the most significance on the list, sorry if I missed any.