Not only is it not the default, but it's hard to keep enabled for a good chunk of users. If you try to go to an app page[1], for example, you will be informed that SSL cannot be used. To continue, you need to disable SSL not only on pages that app uses, but the entire site. It doesn't get re-enabled when you leave the app.
[1] I don't know that this is true for all app pages, but it's definitely true for at least one of the most popular apps on Facebook.
Not a FB app developer, but my naive experience is that not all apps are hosted on a domain with SSL available. If it's not on an SSL domain, it brings up a box asking you if it's ok to disable HTTPS.
About half the special offers / competitions run through Facebook seem to necessitate turning off SSL, which is a real shame. So far I've been leaving it on and giving my cash to other companies.
There are a lot of good things there but the author seems to be looking at it like "there's a bunch more headers on G+ ITS BETTER!"
Unfortunately it's not true. For instance, G+ does not use X-Content-Security-Policy (https://wiki.mozilla.org/Security/CSP/Specification) and uses X-XSS-Protection instead, which is a solution not exactly designed properly. (Noscript is a slightly better implementation, but since its client side, no dice)
You seem to be confused here. CSP and the XSS auditor are not mutually exclusive; you can certainly use both and one can cover areas missed by the other. Also, in terms of market share the XSS auditor is going to be supported by a bigger user base than CSP. It's also important to note that the XSS auditor is disabled on other Google sites primarily because it hasn't been tested for compatibility--not because it can be misused by an attacker.
As for CSP support in Chrome, it's currently available if you set a vendor-specific header. (That's the normal way to handle an experimental standard that's still in flux.) My personal opinion on CSP is that it's a bit of an overly complicated mess. We didn't plan to implement it in Chrome/WebKit until very recently, mainly because Mozilla got some major sites on board. In the end, we decided users would be better served by CSP (warts and all) than by any attempts at yet another standard.
Current versions of Chrome support CSP, but by using the X-WebKit-CSP header. Once they are happy with the implementation, they will use the correctly named header.
What's interesting to me is that even though G+ is a lot younger and has a much smaller feature set compared to Facebook, Google appear to be putting security in from the ground up. Facebook on the other hand are desperately lagging behind in this way.
That's the benefit of hindsight. Facebook was built as a startup and grew fast. G+ is being developed in a fully-fledged company with way more resource.
Agree, though that Fb could be working harder on this!
Google is wisely prioritizing eliminating as much of the downside as possible. They're also able to, since G+ has the staying power that FB may not have felt they had in their early days.
SCTP is at a different layer of the network stack -- it's a replacement for TCP, not for HTTP. As such, it's much more difficult to deploy, as it currently requires a kernel extension in most OSes, and can't traverse most firewalls.
"Unfortunately, not all of these headers are supported in all browsers, meaning any of you still using IE6 won’t be able to take advantage of these headers."
That would be a plausible explanation for the fact that they use a user-agent based whitelisting. If one's protections rely on client-side features, it's a bit more understandable (though I still find it a bit weak) to try to enforce use of a browser that implements them.
Not only that, Facebook serves it's JavaScript from a static content server that is not secured using SSL, or when it is, it's a bad certificate. Combined with Chrome's aggressive insecure script blocking, Facebook is a nightmare to use.
tl;dr: If you think you're secure because Facebook says HTTPS, you're completely wrong. If I'm on your network, I can inject javascript just as happily as if facebook were loading over http.
This has been reported and ignored, as one might guess.
Hey, I work on security at Facebook, and when you've turned on HTTPS mode you definitely should not be pulling javascript from anywhere over HTTP (and of course our CDNs should all have valid certificates!). You're correct that this breaks a lot of the security that HTTPS offers. Do you have an example packet capture or list of HTTP CDN URLs that were referenced when you were in HTTPS mode? Or of the domain with an invalid certificate? I'll try to get that fixed ASAP.
I'd also love to debug your report getting ignored - do you know where you submitted it? We take white hat reports pretty seriously and I know I've seen a number of them resolved in less than a day after being reported. Check out https://www.facebook.com/whitehat to report stuff in the future (we'll even pay a bounty of $500 for most properly-disclosed security bugs: https://www.facebook.com/whitehat/bounty/).
I'll take a capture next time and grab the <head> tag from the body. The biggest problem is that it's very sporadic. Some days it will work perfectly with no warnings and exceptions. Earlier today though, I got the "Security Warning" from Google and improper certificate (not even on the static assets) on a network that I trust to a high degree.
Cool, thanks for the follow-up. Was the "Security Warning" you're talking about from google.com, or from facebook.com? If facebook, do you know what the specific domain was that caused the error (and the reason for the error)?
Also, I'm curious where you reported this before? If there's an issue causing security bug reports to get dropped, that's something I want to fix ASAP. Thanks!
The security warning was the alarming red one generated by Chrome, but for the Facebook site and domain. I can't tell you if it was for the root domain or www, and I'm afraid I do not recall the error. I get a bit confused with Chrome (because it has various levels of warnings for various types of things (the page itself, scripts, stylesheets, etc) and it doesn't help that I'm on the dev channel, but sometimes I get the full blown red warning, sometimes I get the red X through the https in the url bar and sometimes I get "Insecure Script was Blocked" which occurs strangely, when I receive notifications.
I honestly don't remember where I reported this before, it was not at the link you've offered above. I've got that bookmarked now. Like I said, if I have someone to contact or the whitehat link you mentioned, I will be sure to get a more detailed list of what happens when it occurs again.
Are you sure this is still happening? I loaded a few pages, and every resource on those pages was served over HTTPS (and I got no errors, and I'm using Chrome). If you can either reproduce it still, or have any further information, I know a few people here who would like to hear about it.
Not only is it not the default, but it's hard to keep enabled for a good chunk of users. If you try to go to an app page[1], for example, you will be informed that SSL cannot be used. To continue, you need to disable SSL not only on pages that app uses, but the entire site. It doesn't get re-enabled when you leave the app.
[1] I don't know that this is true for all app pages, but it's definitely true for at least one of the most popular apps on Facebook.