Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I suspect it's not plain old sniffing. He might give fake DNS records to point to his own phishing site (facebook clone). It's trivial to re-post the credentials to the real facebook check the password and then actually log them in. curl can be used to do this, as I am sure many others.

Edit: SSL does not have to be used on the clone. Most people will not notice/care.



You can't spoof a certificate with DNS. Even if you spoofed a DNS response and made facebook.com point to 192.168.1.2 then the server at 192.168.1.2 (which could be yours) would still need a valid certificate for facebook.com.

The only way to have done this is by having the user click "continue" or "ignore" or something on an ssl error page. I know from experience that a company full of programmers will happily do that. Only a few percent would go "wait a minute, this is Facebook. That certificate should be valid." Some people here might reply "no way", but HN generally contains the one percent.

Edit: This is almost correct. You can actually prevent being redirected from http to https when typing in "facebook.com" without https:// in front. My bad.

Still though, the attentive user would notice the missing padlock. I check it 3/4 times, and 4/4 times when using a public network. I also refrain from using http sites where I log in (some forums I visit do that). But again, probably less than one percent of the tech people do that.


If you don't type the https url, you start by visiting the http website. Normally the http version will redirect to https, but a man in the middle can easily prevent this.


> If you don't type the https url, you start by visiting the http website. Normally the http version will redirect to https, but a man in the middle can easily prevent this.

This is not entirely correct. HSTS[0] was designed to protect against such attacks.

It's true, however, that not every browser out there supports it yet, and you must visit the website at least once without MITM for the server to successfully communicate HSTS header. (In Chrome certain domains are included in built-in list[1], though.)

[0] https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_s...

[1] https://src.chromium.org/viewvc/chrome/trunk/src/net/http/tr...


https://hstspreload.appspot.com/ says they don't use HSTS as a preload. They should...


Facebook seems to be doing some client sniffing to decide whether to set the headers..

In my browser (FF nightly), I see the HSTS header, with the value: "max-age=15552000; preload"

If I do a request with curl, no header... (which is probably what this app sees).

I don't have a clue why they are doing that, though. Not that curl would do something with the HSTS header anyway, but still...


Facebook has HSTS preload on www.facebook.com, but not on the redirect from facebook.com->www.facebook.com. I suppose they have their reasons


Google.com also doesn't seem to have it.


Google only uses a certificate pin and doesn't force SSL. Sadly.


Yes! I just thought of this and was going to edit it in, but you are quicker. Many websites still don't use HSTS, and in any case this article is from a few months ago (I remember reading it) and HSTS is pretty new.


Perhaps you haven't seen the certificate errors for quite a while, but they are now quite forceful about you not clicking OK. The Ok is hidden.


SSL Strip does works here


also, most people are not savvy enough to check the ssl credentials or to even see that they are not on a ssl enabled site. even if the phishing attack was slow, people have lower expectations for speed in a coffee shop.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: