Twitter Joins the HTTPS By Default Party 95
wiredmikey writes "Following a trend in allowing users to automatically utilize the secure HTTPS protocol when accessing Web based services, Twitter announced this week that it has added the option for users to force HTTPS connections by default when accessing Twitter.com.
The reasons to utilize HTTPS when accessing any personal accounts aren't new, but an easy to use extension for FireFox called 'FireSheep,' released in October 2010, spiked concern, as it enables HTTP session hijacking for the masses."
Good (Score:4, Informative)
I''d like to see all community sites do that.
I got an addon that tries to force SSL where available, and it's surprising so many sites that doesn't have SSL enabled at all.
Re: (Score:3)
Simple tools like FireSheep are an awesome way to force websites to up their game on the encryption front and improve their security.
I guess the addon you mention is EFF's "https-everywhere [eff.org]". Notice that the list of https sites the addon supports is growing pretty large. They will soon have to add the option "exclude these sites" rather than try and provide a massive list of included sites.
Re: (Score:2)
Yesterday my host provider (a big one) failed (again!) to renew the shared server host certificate so I couldn't access their Cpanel via HTTPS, so had to open a ticket.
That happened in 2008, 2009, 2010, and now, so I'm expecting the same situation by march 2012, 2013, etc...
BTW, they sell me a signed certificate for my domain. Alas, they don't track its expiration (nor me, of course!) so by some time in the year I'll have to open a ticket asking them to renew it (no big deal since I'm not doing e-business o
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Otherwise: why should I bother interacting with your site in a less passive manner than simple browsing, if you can't be bothered to enable SSL? Enabling SSL is not difficult, does not generally cause a massive amount of extra load on modern systems (if your site is relatively dynamic then your scripting language and database will be much much m
Re: (Score:2)
I got an addon that tries to force SSL where available, and it's surprising so many sites that doesn't have SSL enabled at all.
Well, SSL is not free in any sense. There's some amount of overhead simply in the encryption, of course. If you're running multiple sites from one machine (read: any shared hosting plan), you need a dedicated IP per SSL site* which costs extra. Then there's the cost of the certificate itself**, and the initial process of setting it up. And once you have the technical side of things configured, you still need to make sure that ALL resources on the page are coming in over https as well, which is easier said t
What's the penalty for HTTPS? (Score:4, Interesting)
Back some years ago, there was talk about dedicated SSL hardware. What's the performance penalty for HTTPS anymore?
Say you're a small startup running your "the next Twitter" app on a Xen or OpenVZ VPS instance.
What's the hit for HTTPS?
Any thoughts on HTTPS only for the login page, or for all pages?
Re:What's the penalty for HTTPS? (Score:5, Informative)
Any thoughts on HTTPS only for the login page, or for all pages?
You can just steal the session cookie after login, so just doing the login page is almost useless. It prevents the attacker from learning the password and re-entering the system, but a) he can change the password and b) there is no reason he wouldn't get the job done within one session.
Re:What's the penalty for HTTPS? (Score:4, Informative)
Re: (Score:2)
Re: (Score:1)
Re: (Score:1)
True for the sessionjacking.
Thinking out loud: I'd think a way to prevent password changes would be to require you to enter the old password in order to change the password, like passwd does.
Re: (Score:1)
Re: (Score:2)
And that's what FireSheep does. If it can't steal login credentials, it steals session cookies (which will be sent in the clear). Most sites already do the whole
Re: (Score:2)
All that is just polishing the turds. Or at least reinventing a mediocre replacement for a proper wheel.
Just use HTTPS for everything. One certificate per year is certainly cheaper than one person-day for IT staff trying to implement a workaround. Buy cert (or get a StartSSL free one), install cert, behold a safe website.
With governments, companies, data miners growing greedier every day, plaintext is going the way of the dodo. Only a few bearded Internet founders still believe in the good of mankind to sen
Re:What's the penalty for HTTPS? (Score:4, Informative)
SSL performance for high bandwith applications (Score:2)
There's still a performance hit for SSL. Solutions for that include load balancers with dedicated hardware SSL support.
Back when Usenet providers starting offering full SSL transfers, I remember reading that one of the reasons they were charging more for it (at the time) was because SSL transfers saw a 400% increase in required CPU power on the back end.
Nowadays though, SSL seems to come by default in most offerings I've seen.
Re: (Score:2)
400%? That doesn't sound right. Maybe we've improved our algorithms significantly since then, but I tend to hear anywhere from "rounding error" (probably hardware support) to 30-40% increase.
Re: (Score:2)
Damn, I had mod points last week.. That serverfault link was very informative but what I expected.. If you have a large site you are really going to want to have SSL accelerated load balancers in front of your web servers... The load is substantial.
Re: (Score:1)
All pages. When you log in to begin with, if the login page is HTTPS then your username and password are encrypted. This is good, because it means nobody else can snoop your password and log in as you later. You are then sent back a cookie. Later, when you want to prove that you are logged in, you just send the cookie along with the HTTP request. Of course, if all the other pages are not encrypted, then the cookie is sent in the clear, which al
Re: (Score:1)
Compaqt, because of HTTP of session hijacking works over unsecured wireless connections, it's important to use SSL beyond just the login. So even during the login process when the password is submitted, once a session is established, the session can be hijacked.
Re: (Score:3)
Pretty much the only real penalty for https is browser shittiness. If your identity isn't certified by a recognized CA, all the major browsers incorrectly treat your site, relative to http, as having a higher (rather than lower) risk of .. something .. so they try to scare the user with vague error messages that, even if the messages were appropriate, mislead the user rather than inform. So the penalty is that you have to pay someone to sign you.
As for the computations, it's 2011 so CPU is so close to "
Re: (Score:1)
> Encryption is free.
You're concentrating on the client aspects of SSL, not the server-side.
Take a low-ball estimate of "page size" at 300 kB; all elements of the page have to be encrypted.
Take a low-ball estimate of 10,000 SSL page requests per second per server.
Each server has to encrypt at 3 GB / second just to handle static page requests, let alone dynamic calls to DBs and CMS.
Back to the maths for you!
Re: (Score:2)
Wait a minute, 10k requests per second per server? Highly unlikely. Ever look at those "0.09 seconds" things you get on Google? They used to be all over the place, and I don't think I've ever seen one below 10ms, certainly never below 1ms. You're asking for 100 microseconds to process a page in. On a 3GHz processor, that's 30,000 cycles. If the page is 300kb, you have roughly 1/10th of a cycle to process each byte, which is flat impossible.
But, we know they process more than a byte at a time. A 64-bit machi
Re: (Score:2)
I wrote a long post and then realized it was tl;dr. So, I'd instead just like to point out certificates work on a network of trust. If you present a certificate that no one else trusts, why should I? The browser behavior is absolutely the right one. "This guy is presenting a certificate he signed himself. No one I trust trusts him. What should I do?"
Re:What's the penalty for HTTPS? (Score:4, Insightful)
Speaking as someone in exactly the situation you describe -- running our current site on a small single-core VPS, over HTTP we can serve ~400 static files per second, limited by bandwidth. Using HTTPS, we can serve 10 static files per second, limited by CPU speed. For dynamic pages, the limits are more like 50/sec (limited by CPU) and 5/sec (limited by CPU -- page load times go up a lot as the database and processing are competing with the encryption)
Current plan to deal with this, because we want to be HTTPS by default, is to offload static files to an HTTPS-enabled CDN, and have a front-end reverse proxy or several dedicated to SSL processing -- unless anyone has any better ideas?
Re: (Score:2)
Wow, a 10:1 ratio, much more than the 2:1 (with caching) using a simple ab test from the serverfault link.
Reading the responses above, I'm thinking that a happy medium is:
-HTTPS for login for free users. Has the risk of sessionjacking
-Ask for old password before changing password or major actions like "delete all"
-HTTPS by default or by option for paid users.
Re: (Score:2)
Maybe you could use a trick with the domain or path when setting the session cookie so that static files don't get it. Then serve static files over HTTP and only the actual pages over HTTPS.
Re: (Score:2)
Re: (Score:1)
Additionally, you need one IP address per https website you want to host. This isn't an issue with IPv6 (Yay IPv6) or when using a webserver/client that can use Host headers before the SSL transaction (which all older b
Re: (Score:2)
[...] the software isn't wide spread enough to reliably host multiple SSL websites on a single IP with vhosts. [...]
I may be mistaken, but did not Apache introduce this feature in version 2? I have used SSL with name based vhosts quite heavily for years.
Re: (Score:1)
Re: (Score:2)
Additionally, you need one IP address per https website you want to host. This isn't an issue with IPv6 (Yay IPv6) or when using a webserver/client that can use Host headers before the SSL transaction (which all older browsers do NOT support). The main problem is that not everyone has a metric 'shitton' of IPv4 addresses and the software isn't wide spread enough to reliably host multiple SSL websites on a single IP with vhosts.
Browsers that don't support SNI:
In short, you're safe to use it these days unless you're hosting a legacy app on an internal business server or massive shopping site trying to catch every last Christmas shopper--in either case, IPs are probably the least of your worries.
Re: (Score:2)
argh, less-than signs. That should be:
There was other commentary on there, but it wasn't important.
Re: (Score:1)
Re: (Score:2)
Well that's news to me. I'd be surprised if any other than IE worked that way, as far as I know there's no mandatory system implementation of HTTP--I know you don't have full access to the IP stack, but that's as far as it goes (I think). Anyway, I'll have to test that out sometime when I have time (unless some enterprising slashdotter tests it out for us), but thanks for the info.
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
If you want dedicated SSL hardware, just set up a reverse proxy running on a Geode CPU. They can push 200Mbps of AES-128 despite being ancient. Newer Intel stuff has encryption-specific instructions built in so you might not even need a separate box.
HTTPS by default? Not exactly, Misleading headline (Score:2, Informative)
Users are required to change this setting themselves, nothing default about it. It's simply an added option
Now Gmail, this is HTTPS by default..
also I read mobile.twitter.com will not even switch to HTTPS? wut.
Smarten up slashdot and editors
Re: (Score:3)
You're right -- It's not SET to default, but users can set the service to use HTTPS by default.The actual title of the article is "Twitter Enables Option for HTTPS by Default" - Though I agree that the /. could have been more clear.
Re: (Score:1)
To be fair Gmail started off by giving this as an option, then transitioned to enabling it by default.
Baby steps my friend, baby steps. Allowing the option is actually a really good way to get a good test of the system, you can see exactly how many people enabled it, had difficulties, then disabled it. As long as that number is nearly zero, compared to the number that switched it on and left it, you have some data supporting the move to ssl by default.
I think this is the proper way of handling this.
Re: (Score:2)
i searched for "slashdot" in comments. only came up in the middle of the page. i guess geeks must suck at security :)
also, regarding slashdot and https - they probably lack the technical competency to set it up.
YEAH. hope to see https next week, thanks.
Bad idea! (Score:1)
Re:Bad idea! (Score:4, Insightful)
Tell that to the people in Libya, China, North Korea (do they have internet?) and other places around the world where the government isn't so easy on people who oppose the regime.
Re: (Score:2)
North Korea (do they have internet?)
Most of them are lucky to have electricity, let alone internet.
http://www.atr.org/userfiles/korea-by-night.jpg [atr.org]
Re: (Score:1)
Re: (Score:2)
I work with independent journalists in this and other at-risk countries, and consult with those seeking to protect activists. While you are perhaps right that the threat is, at heart, one of human rights, protecting those attempting to change or document that situation is also important. And lack of on-the-wire encryption also presents an almost constant temptation to even other countries supposedly better protected by the rule of law. The pervasive data-mining conducted by AT&T on behalf of the NSA is
Re: (Score:2)
Free speech without anonymity isn't free speech. It's an invitation for thugs.
HTTPS does cache (Score:2)
A big problem I see with this is 1) Twitter isn't carrying important personal data, 2) in fact, quite the opposite, except for login credentials to sign in, and that's always been HTTPS anyway, 3) HTTPS does not cache. We should be encouraging sites to be more cachable and more ISPs to adopt proxies like Squid, not cripple their ability to reduce traffic leaving/entering the network.
HTTPS does cache pages at the browser, it is only middle tier browsers like squid that cannot cache the pages. Of course if you have an interactive site then these will disable caching anyway, you don't want everyone to see your session.
Re: (Score:1)
Re: (Score:3)
It is completely up to the site serving the resources. A quick look unsurprisingly shows twitter not being stupid about it and setting the correct headers to get the browser to cache resources served over HTTPS for as long as the browser can. Here are the response headers from getting their logo over HTTPS:
Date Wed, 16 Mar 2011 14:52:00 GMT
Content-Length 1159
Content-Type image/png
Etag "c53472495d431cceef1c715732db12c9"
Expires Wed, 18 May 2033 03:33:20 GMT
Last-Modified Tue, 15 Mar 2011 21:2
Re: (Score:3)
You can steal the session cookie from someone using twitter using an unsecured network (such as a public wifi) - and then spam the crap out of his feed, or change some settings or something.
I'm pretty sure the ability to spoof someone else's twitter to say whatever you want is considered - "Important Personal Data".
Login Credentials aren't needed if you're nicking the cookie - see also : "Firesheep" which is script-kiddie friendly.
Re: (Score:1)
You can steal the session cookie from someone using twitter using an unsecured network (such as a public wifi) - and then spam the crap out of his feed, or change some settings or something.
Boo hoo. It's Twitter. Who gives a shit? Until you can post more than 140 characters, unless you and your audience speak Korean, Japanese, Cherokee or some other language that uses ideograms or a syllabary instead of an alphabet, it's next to impossible to express a cogent thought on a level higher than "I'm hungry" on Twitter.
Re: (Score:2)
A short tweet like "We are attacking the Death Star tomorrow morning" is probably enough for the other side to set up a serious trap.
Re: (Score:2)
A large number of journalists and activists end up communicating with sources and each other using direct messaging on Twitter, so there is private information passing around. There's also the question of using login credentials to take over and fake messages. Also, there's the question of correlating Twitter identities with individuals (though I can think of a few strategies for attackers to do that even with https enabled).
Re: (Score:2)
> We should be encouraging sites to be more cachable and more ISPs to adopt proxies like Squid
You have, quite literally, no idea what you are talking about. The German university and research backbone DFN is staffed with incredibly bright minds and has been pushing technology on quite a few frontiers.
They gave up proxying in the 90ies.
Why?
* It's cheaper to just add more bandwidth
* In any network of non-trivial size, there are a lot of possible routes traffic can go and you need to account for this and ch
Good start, but install HTTPS everywhere (Score:5, Interesting)
I don't like keeping track of what sites I can and can't use HTTPS on, so I installed HTTPS Everywhere [eff.org] on my browsers and get HTTPS access to a bunch of sites by default.
BTW, when do we get HTTPS access to /.?
Re:Good start, but install HTTPS everywhere (Score:5, Funny)
When someone hacks CmdrTaco's account and posts something embarrassing using his name. I mean embarrassing enough we can tell it wasn't him, of course.
This may be difficult, to be honest.
Re:Good start, but install HTTPS everywhere (Score:4, Informative)
Slashdot has HTTPS access if you are a paying subscriber.
Re: (Score:2)
Seems a little disingenuous for slashdot to be posting this story when https is not available for all slashdot users. The danger is no less or different from the other sites being slammed. Pot, meet kettle.
Re: (Score:1)
It is built in to Firefox 4 (Score:4, Informative)
Re: (Score:3)
From what I am understanding of the article its there to stop:
http://www.example..../ [www.example....]
[redirect to]
https://..../ [....]
Which could be grounds for a Man In The Middle Attack. It does not say anything about forcing people to use HTTPS, just that it will be done automatically instead of using a redirect. So it'll make sites which force HTTPS safer, but it won't force twitter to push https if you haven't asked for it.
Re:It is built in to Firefox 4 (Score:4, Informative)
From what I am understanding of the article its there to stop:
http://www.example..../ [www.example....] [redirect to] https://..../ [....]
Which could be grounds for a Man In The Middle Attack. It does not say anything about forcing people to use HTTPS, just that it will be done automatically instead of using a redirect. So it'll make sites which force HTTPS safer, but it won't force twitter to push https if you haven't asked for it.
There is a better explanation here [wikipedia.org]. Basically after the header is received the browser will convert any http: requests to https [slashdot.org]:, therefore bypassing any redirect. Whether this will force you to use https depends on whether Twitter will set this header on their https sites only or on both http and https. Even if they do set it only on the https site it will force you to use https if you visit the https URL even once.
Small correction (Score:2)
Strict-Transport-Security headers must be sent via HTTPS responses only. Client implementations must not respect STS headers sent over non-HTTPS responses, or over HTTPS responses which are not using properly configured, trusted certificates.
Why? (Score:3)
So you can securely upload your private data for public dissemination?
Re: (Score:3)
More like so you can be sure that someone using the same connection at your coffee shop won't post something in your name by sniffing your cookies.
Tweet widget (Score:2)
When will the "tweet this" button for websites be able to use SSL? Having this button in the footer of a site I worked on recently made it a bit of a hassle to create a page that's completely SSL.
Re: (Score:2)
Good point. Are browsers still putting out the notorious "not all elements on this page are SSL" errors they used to?
Re: (Score:2)
Well, I had to support IE8 with an SSL iframe because the client wanted some obscure payment processor that wouldn't break the continuity of the site's branding the way PayPal would.
So, if you have an iframe in SSL then you've got to jump through several hoops including adding something to mod_header and removing every single non-SSL element from the page. If you don't, then cookies get broken. Without cookies, I couldn't use the session variables that made everything work in the good browsers.
It's not a hu
Re: (Score:2)
Interesting. I'll bet you you had some kind of time convincing the client that hours billed for that research were worth it. ("If you're such a great developer, you should already know that")
What about their android app? (Score:2)
No HSTS? (Score:2)
Better than nothing, but I don't see any HTTP Strict-Transport-Security: header.
not HTTPS by default (Score:2)
It's not HTTPS by default. It's giving users the option to use HTTPS.
HTTPS by default would be switching all users automatically, allowing them to opt out.