They are correct that everyone should be using HTTPS. It costs as little as $12/year for the certificate, there's tons of tutorials on how to set it up in Apache, and there's only a couple of hundred sites in the world that need to be concerned with the performance hit (no, I doubt your blog is on that list).
https incurs a heavy performance penalty for everyone. Server load isn't the problem; a large increase in latency for every single connection is.
Your typical blog is probably going to suffer even more from enabling https globally when compared to major sites because not as much effort has been put into combining js, css, and images into sprites.
I wish I could uprate you with more than one vote.
Seriously, https performance sucks from start to finish. If the average user doesn't care about https, but does care about performance, who are they going to go with - you or your faster competitor?
Probably depends on if their account gets hijacked at your site or the site of your fastest competitor.
I agree that anonymous or non-logged-in activity has no need of HTTPS, but anything that's transferring cookies, passwords, or other important user or session information should be HTTPS.
Google is currently working on something called "False Start" to reduce the number of roundtrips for an SSL connection to reduce latency. I believe there is already code in Chrome for this.
Is there a good way to set up a Varnish or Squid-like caching proxy in front of HTTPS, or is that by design impossible? My fairly small sites don't generally have performance problems, but on the occasions that they get Slashdotted or on the front page of Reddit, the caching sure helps keep things moving.
Edit: It looks like the best way might be to do SSL between the client and nginx on my side acting as a reverse proxy, and then non-SSL internally on my side? Not sure how that setup compares to Varnish in general, but it's probably fine for my purposes.
yep, you'd use something like nginx or apache traffic server and set that up to serve SSL.
One special case though, if you have multiple servers that serve your content load balanced, and if these servers are in different colocations, then you probably need to run any sync between them over SSL. Even if you do control the link between the two boxes, there's that off chance that your link goes down and the IP layer automatically routes traffic through a different set of routers.
one nit to pick... there are still people stuck on slow connections. they are not always there by choice. In some cases the infrastructure is lagging the advances in content proliferation. when you get to dialup (the remaining ubiquitous and typically unlimited connectivity) running HTTPS where it is not needed is painful. v90 is only able to achieve compression on HTTP traffic. HTTPS traffic ends up moving at 40-50% the speed of HTTP traffic. While data security is certainly a valid objective, not everything moving as HTTPS needs to do so.
It's a trade off. Security vs performance. Personally, I think a small reduction in performance for a massive increase in security is a worthwhile exchange. Other people don't think so.
I'm not attempting to verify the veracity of OP's statement but, going on face value, OP says "40%-50% slower". Surely you do not consider that a small reduction in performance, do you?
I don't recognise the 40%-50% figure. I've been using the HTTPS-Everywhere Firefox addon and I notice a very small slow down on some sites, and nothing noticeable on others.
So I've been setting up all my sites as separate domain names, with things like code.domain.com and email.domain.com. Should I migrate these services, or is there a way to use HTTPS on many subdomains?
You can buy a global wildcard certificate that lets you create a domain name for *.domain.com. It costs like $199/year on GoDaddy I think, so you'd have to figure out if you think it would be worth it over getting individual certificates as $12/cert.
Can't the argument be made that if you are a startup and have launched a product to test the market, it would take up too much developer time to think about https? Depending on the nature of the service, shouldn't you defer the extra effort until only after you've validated the product/market fit?
Well, the contradictory argument can be made as well: If you're a start-up, and your early adopters get annoyed because someone made sure Firesheep works with your web site, and they're all getting pranked, they're going to decide they won't bother.
OTOH, I am writing this comment on an open wireless router.
On the gripping hand, nothing I put here is private, and if someone "pranks" me, I can just login again and delete offensive content. Karma isn't actually money...
Your local network admin, your ISP, any ad networks your ISP has or will have arrangements with and your government can log all the websites you visit and build profiles of you because https isn't used everywhere.
This might not bother you individually, today. But maybe it will cause problems for you in the future if laws change? Maybe it is causing problems for a lot of people who aren't you today? Maybe it is causing problems for citizens in countries other than yours?
The World would be better off if https was used everywhere.
Surely you're understating the time? 15 minutes sounds like the "happy path" estimate. Don't you have to think about mixed content and other edge cases? Or do these just not come up that often?
It's obviously going to be easiest if you do it from the beginning, but even retrofitting won't be a huge issue. It's probably also easier if you secure your entire site rather than piecemeal (like just for logins).
I actually did it last night, from yum install httpd to (self-signed) SSL in less than 15 minutes. There are some webapp considerations, but they are negligible when compared to other security efforts like XSS diligence.
Comments
They are correct that everyone should be using HTTPS. It costs as little as $12/year for the certificate, there's tons of tutorials on how to set it up in Apache, and there's only a couple of hundred sites in the world that need to be concerned with the performance hit (no, I doubt your blog is on that list).
https incurs a heavy performance penalty for everyone. Server load isn't the problem; a large increase in latency for every single connection is.
Your typical blog is probably going to suffer even more from enabling https globally when compared to major sites because not as much effort has been put into combining js, css, and images into sprites.
I wish I could uprate you with more than one vote.
Seriously, https performance sucks from start to finish. If the average user doesn't care about https, but does care about performance, who are they going to go with - you or your faster competitor?
Probably depends on if their account gets hijacked at your site or the site of your fastest competitor.
I agree that anonymous or non-logged-in activity has no need of HTTPS, but anything that's transferring cookies, passwords, or other important user or session information should be HTTPS.
Google is currently working on something called "False Start" to reduce the number of roundtrips for an SSL connection to reduce latency. I believe there is already code in Chrome for this.
The main detractor is inability for intermediate parties/networks to perform caching.
You can't cache something that's encrypted!
Is there a good way to set up a Varnish or Squid-like caching proxy in front of HTTPS, or is that by design impossible? My fairly small sites don't generally have performance problems, but on the occasions that they get Slashdotted or on the front page of Reddit, the caching sure helps keep things moving.
Edit: It looks like the best way might be to do SSL between the client and nginx on my side acting as a reverse proxy, and then non-SSL internally on my side? Not sure how that setup compares to Varnish in general, but it's probably fine for my purposes.
yep, you'd use something like nginx or apache traffic server and set that up to serve SSL.
One special case though, if you have multiple servers that serve your content load balanced, and if these servers are in different colocations, then you probably need to run any sync between them over SSL. Even if you do control the link between the two boxes, there's that off chance that your link goes down and the IP layer automatically routes traffic through a different set of routers.
one nit to pick... there are still people stuck on slow connections. they are not always there by choice. In some cases the infrastructure is lagging the advances in content proliferation. when you get to dialup (the remaining ubiquitous and typically unlimited connectivity) running HTTPS where it is not needed is painful. v90 is only able to achieve compression on HTTP traffic. HTTPS traffic ends up moving at 40-50% the speed of HTTP traffic. While data security is certainly a valid objective, not everything moving as HTTPS needs to do so.
It's a trade off. Security vs performance. Personally, I think a small reduction in performance for a massive increase in security is a worthwhile exchange. Other people don't think so.
I'm not attempting to verify the veracity of OP's statement but, going on face value, OP says "40%-50% slower". Surely you do not consider that a small reduction in performance, do you?
I don't recognise the 40%-50% figure. I've been using the HTTPS-Everywhere Firefox addon and I notice a very small slow down on some sites, and nothing noticeable on others.
So I've been setting up all my sites as separate domain names, with things like code.domain.com and email.domain.com. Should I migrate these services, or is there a way to use HTTPS on many subdomains?
You can buy a global wildcard certificate that lets you create a domain name for *.domain.com. It costs like $199/year on GoDaddy I think, so you'd have to figure out if you think it would be worth it over getting individual certificates as $12/cert.
> would be worth it over getting individual certificates as $12/cert
Which you can't really do in shared-IP virtual hosting, since SNI support is still a bit spotty.
"everyone should be using HTTPS"
Can't the argument be made that if you are a startup and have launched a product to test the market, it would take up too much developer time to think about https? Depending on the nature of the service, shouldn't you defer the extra effort until only after you've validated the product/market fit?
Well, the contradictory argument can be made as well: If you're a start-up, and your early adopters get annoyed because someone made sure Firesheep works with your web site, and they're all getting pranked, they're going to decide they won't bother.
OTOH, I am writing this comment on an open wireless router.
On the gripping hand, nothing I put here is private, and if someone "pranks" me, I can just login again and delete offensive content. Karma isn't actually money...
Your local network admin, your ISP, any ad networks your ISP has or will have arrangements with and your government can log all the websites you visit and build profiles of you because https isn't used everywhere.
This might not bother you individually, today. But maybe it will cause problems for you in the future if laws change? Maybe it is causing problems for a lot of people who aren't you today? Maybe it is causing problems for citizens in countries other than yours?
The World would be better off if https was used everywhere.
It's $12 and 15 minutes, not a big investment.
Surely you're understating the time? 15 minutes sounds like the "happy path" estimate. Don't you have to think about mixed content and other edge cases? Or do these just not come up that often?
It's obviously going to be easiest if you do it from the beginning, but even retrofitting won't be a huge issue. It's probably also easier if you secure your entire site rather than piecemeal (like just for logins).
I actually did it last night, from yum install httpd to (self-signed) SSL in less than 15 minutes. There are some webapp considerations, but they are negligible when compared to other security efforts like XSS diligence.
Or rather, everyone should be using HTTPS once XP dies. Until then, HTTPS breaks the shared hosting model.
Until XP or IPv4 dies. I'm guessing IPv4 will be around longer than XP though.