Web Served: How to make your site all-HTTPS, all the time, for everyone

Adding in SSL termination and HSTS compliance because it’s the right thing to do.

Read the whole story

 

[bthylafh]

In before the nth iteration of WHY ISN'T ARS HTTPS WHARRGARBL.

 

[vnicolici]

and note that the colon and semicolon characters have to be escaped with backslashes or things will break!

Actually you have to escape the space characters. From the documentation:

If spaces have to be entered in strings, then they must be
preceded by a backslash ('\') to be escaped. Backslashes also have to be
escaped by doubling them.

 

[MartinHatch]

bthylafh[/url]":332zlkn4]In before the nth iteration of WHY ISN'T ARS HTTPS WHARRGARBL.

It is in HTTPS for subscribers

 

[Solidstate89]

The unencrypted Web is on the way out, and that’s a good thing. We’re still making the switch here at Ars—subscriptors can use HTTPS today, but we’re still working out the mixed content kinks for everyone else (the main holdup is handling the ad networks. Since subscriptors don’t see ads, there’s no holdup there!).

There are still issues even for subscribers. Like submitting comments for example. Right after I hit "Leave your comment" I'll be redirected back to HTTP. And the forums are completely unencrypted by default now. Before it used to at least result in a mixed content warning - now it doesn't even do that unless I manually add https:// to the URL.

 

[MartinHatch]

Seems like an awful lot of work.

My IIS site it was a case of:

* Install SSL cert
* Configure site bindings
* Setup URL Rewrites

the last step simply performs a 302-permanent redirect to anyone trying to use normal HTTP

 

[Deleted member 441963]

MartinHatch[/url]":1161xadj]Seems like an awful lot of work.

My IIS site it was a case of:

And what does SSLLabs say about your site? Because it's not about using ssl, it's about HSTS compliance (and strong ciphers are a bonus).

Lee: you're a little late, actually. Had to find out the same a few months ago. If you borrowed my notes you could have saved yourself a lot of time..

 

[tekknik]

The easiest solution for people that don't know how to setup an HTTPS proxy would likely be cloudflare.com. They have a HTTPS enabled on their free tier now.

 

[mmiller7]

vnicolici[/url]":3vglvpc6]

and note that the colon and semicolon characters have to be escaped with backslashes or things will break!

Actually you have to escape the space characters. From the documentation:

If spaces have to be entered in strings, then they must be
preceded by a backslash ('\') to be escaped. Backslashes also have to be
escaped by doubling them.

Where's that BINGO board?

 

[woegjiub]

MartinHatch[/url]":13yu3ems]Seems like an awful lot of work.

My IIS site it was a case of:

* Install SSL cert
* Configure site bindings
* Setup URL Rewrites

the last step simply performs a 302-permanent redirect to anyone trying to use normal HTTP

It's just as simple for that with nginx as well, if you're going with straight nginx.

The main gain here is using a caching layer.

 

[mmiller7]

MartinHatch[/url]":2jfuyrkf]Seems like an awful lot of work.

My IIS site it was a case of:

* Install SSL cert
* Configure site bindings
* Setup URL Rewrites

the last step simply performs a 302-permanent redirect to anyone trying to use normal HTTP

You forgot a few steps...

* Obtain more money
* Purchase SSL cert
* Figure out how to open the stupid IPTABLES and make it stick

Personally, I still don't see why *everything* would need to be HTTPS. I rent a very-low-end server to run a personal hobby photo album site. I'm really not concerned if someone snoops on the non-interactive flow of pictures. Nor am I worried about the speedtest.net mini-site having the random data snooped.

HTTPS sounds like a great way to bring an underspec'd server to it's knees with a fraction of the traffic. Yes, if you have accounts and logins or personal info it absolutely needs HTTPS. That doesn't mean *EVERYTHING* should be.


EDIT: Before I get slammed with "just use <insert photo share site here>" I'd like to point out...the things I post on my personally-admin'd server are usually bulk shots. It's raw, unedited (mostly) and I haven't weeded out any of the "bad" shots. It's a self-service mentality and I have coded it (and leverage a PHP no-database photo album with some custom tweaks to limit file access) such that I can simply make a folder and dump junk into it, and magically the photos get thumbnails generated on-demand so I don't have to actively upload or manage anything. If I have good shots, I'll post-process and put them elsewhere but I don't do that for everything. For the rest, I can share a link and people can dig thru as they see fit.

 

[willdude]

bthylafh[/url]":2khdf8be]In before the nth iteration of WHY ISN'T ARS HTTPS WHARRGARBL.

IT'S LIKE RAYAAAAAAAIN...

 

[Middling]

MartinHatch[/url]":3c7es12h]Seems like an awful lot of work.

If the author wasn't using HAProxy and Varnish for caching it would be fairly easy to do in Nginx too.

This is what i have on my server:

Redirect http URLs to https:

	server {
		listen 80;
		server_name	example.org	www.example.org;
		location / {
			return		301	https://$host$request_uri;
		}
	}

The SSL site:

	server {
		listen	443 ssl spdy;
		ssl	on;
		server_name	example.org www.example.org;
		ssl_certificate      /path/to/ssl/certificate/cert.chained.crt;
		ssl_certificate_key  /path/to/ssl/certificate/cert.key;
		ssl_trusted_certificate	/path/to/ssl/certificate/cert.chained.full.crt;
		ssl_session_timeout  24h;
		ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
		ssl_ciphers EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:EDH+aRSA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4;
		ssl_dhparam /path/to/ssl/dhparam.pem;
		ssl_prefer_server_ciphers   on;
		ssl_stapling on;
		ssl_stapling_verify on;
		resolver 8.8.8.8;
		ssl_session_cache shared:SSL:3m;
		spdy_chunk_size 8k;
		spdy_headers_comp 3;
		add_header	Strict-Transport-Security 	"max-age=31536000; includeSubDomains";
		log_not_found	off;
		charset utf-8;
		location / {
			root			/var/www/example.org;
		}
}

mmiller7[/url]":3c7es12h]

* Obtain more money
* Purchase SSL cert

StartSSL have provided free SSL certificates for the better part of a decade.

 

[Abhi Beckert]

mmiller7[/url]":1wduccwa]

MartinHatch[/url]":1wduccwa]Seems like an awful lot of work.

My IIS site it was a case of:

* Install SSL cert
* Configure site bindings
* Setup URL Rewrites

the last step simply performs a 302-permanent redirect to anyone trying to use normal HTTP

You forgot a few steps...

* Obtain more money
* Purchase SSL cert
* Figure out how to open the stupid IPTABLES and make it stick

Personally, I still don't see why *everything* would need to be HTTPS. I rent a very-low-end server to run a personal hobby photo album site. I'm really not concerned if someone snoops on the non-interactive flow of pictures. Nor am I worried about the speedtest.net mini-site having the random data snooped.

HTTPS sounds like a great way to bring an underspec'd server to it's knees with a fraction of the traffic. Yes, if you have accounts and logins or personal info it absolutely needs HTTPS. That doesn't mean *EVERYTHING* should be.

HTTPS is not just about snooping, it's also a security issue. Since your site is not using SSL, anybody who visits your website can be attacked.

The thing is, SSL isn't about protecting the server operator, it is about protecting ordinary people browsing the internet.

Also, SSL does not bring an underspec'd server to it's knees. I'm guessing your CPU load will increase from 99.999% idle to 99.998% idle if you enabled SSL. It's your bandwidth or disk activity or available RAM that matter on a low spec server, and encryption does nothing to make any of those work harder.

SSL is only expensive if you have a massively complicated server setup like facebook or youtube. For small sites it's free, except for learning how to implement it.

 

[Katana314]

Pretty much stopped reading at the "prerequisites" part, for a reason I already knew; my host is a shared host. It costs about $6 a month, and I can't justify doubling/tripling those costs to prevent the NSA from seeing it. It's sad that for that reason alone I'm going to be at the bottom of the newfangled Google search result rankings, but such is life.

I get how awesome HTTPS is, but sometimes I feel like the browser developers aren't actually aware of *why* all sites haven't implemented it straight away.

 

[tekknik]

Abhi Beckert[/url]":k5krljpx]

mmiller7[/url]":k5krljpx]

MartinHatch[/url]":k5krljpx]Seems like an awful lot of work.

My IIS site it was a case of:

* Install SSL cert
* Configure site bindings
* Setup URL Rewrites

the last step simply performs a 302-permanent redirect to anyone trying to use normal HTTP

You forgot a few steps...

* Obtain more money
* Purchase SSL cert
* Figure out how to open the stupid IPTABLES and make it stick

Personally, I still don't see why *everything* would need to be HTTPS. I rent a very-low-end server to run a personal hobby photo album site. I'm really not concerned if someone snoops on the non-interactive flow of pictures. Nor am I worried about the speedtest.net mini-site having the random data snooped.

HTTPS sounds like a great way to bring an underspec'd server to it's knees with a fraction of the traffic. Yes, if you have accounts and logins or personal info it absolutely needs HTTPS. That doesn't mean *EVERYTHING* should be.

HTTPS is not just about snooping, it's also a security issue. Since your site is not using SSL, anybody who visits your website can be attacked.

The thing is, SSL isn't about protecting the server operator, it is about protecting ordinary people browsing the internet.

Also, SSL does not bring an underspec'd server to it's knees. I'm guessing your CPU load will increase from 99.999% idle to 99.998% idle if you enabled SSL.

SSL is only expensive if you have a massively complicated server setup like facebook or youtube. For small sites it's free, except for learning how to implement it.

I was trying to find a nice way to say that last bit. If your server can't handle HTTPS then you should retire that server. I have a cell phone serving up some HTTPS traffic next to me, it has no issues. In fact, most modern processors have AES acceleration instructions.

 

[willglynn]

woegjiub[/url]":3bc88xry]It's just as simple for that with nginx as well, if you're going with straight nginx.

The main gain here is using a caching layer.

…which is also something that nginx can do, if you should choose to configure it that way See the proxy_cache_* directives.

nginx proxy caching applies only to proxied content, but that's okay -- static content is already cached by the filesystem, and dynamic content (the stuff you really want to cache) is almost always already being served via the proxy module. The configuration isn't as expressive as Varnish, but if you really need more, ngx_lua can provide that.

 

[tekknik]

MartinHatch[/url]":2tj03jd6]Seems like an awful lot of work.

My IIS site it was a case of:

* Install SSL cert
* Configure site bindings
* Setup URL Rewrites

the last step simply performs a 302-permanent redirect to anyone trying to use normal HTTP

This also seems like a lot of work, cloudflare.com

 

[willglynn]

Middling[/url]":2qnuub5l]StartSSL have provided free SSL certificates for the better part of a decade.

StartSSL issues non-commercial-use certificates for free, but even then they make you pay to revoke or reissue certificates. This creates some strange incentives.

Come on, Let's Encrypt!

 

[Entegy]

This tells HAProxy that if an incoming request is not HTTPS, to send a 301 redirect for the same resource with the HTTPS scheme instead of HTTPS.

Uhhh.

 

[Daveoc64]

MartinHatch[/url]":ndhenmdf]the last step simply performs a 302-permanent redirect to anyone trying to use normal HTTP

The weakness with that is that by trying to view your site over HTTP the user would be vulnerable to a spoofing attack. The user needs to be able to connect to YOUR server for that redirect to function, so if they have a bookmark configured to use http://example.com instead of https://example.com then they'll be very vulnerable to all sorts of attacks.

The strict-transport-security header mentioned above can help stop that, as the browser will then know that it should always connect via https, even if the user tries to use http. It does however only work if the user has already visited the site in question.

 

[giltwist]

bthylafh[/url]":2eqwmvyl]In before the nth iteration of WHY ISN'T ARS HTTPS WHARRGARBL.

That's not satire...THIS is satire...

 

[peragrin]

giltwist[/url]":32odd3lc]

bthylafh[/url]":32odd3lc]In before the nth iteration of WHY ISN'T ARS HTTPS WHARRGARBL.

That's not satire...THIS is satire...

I am going to play that every time I read an article with more than 40 comments.

 

[giltwist]

peragrin[/url]":8alj01g6]
I am going to play that every time I read an article with more than 40 comments.

It's really amazing how fast you get Bingo in some threads. Also, make sure to keep an eye on the Lounge forum. I'll post periodic updates to it there.

 

[drosboro]

Lee, is a “subscriptor” someone who uses a lot of subscripts?

 

[chrisnehren]

Middling[/url]":11c9bhcg]
If the author wasn't using HAProxy and Varnish for caching it would be fairly easy to do in Nginx too.

Yeah, I don't get that. HAProxy is not an SSL terminator (just because you can it doesn't mean you should), and the other servers do a much better job of it. Seems like unnecessary overhead to me. Also, for what it's worth, most people won't need a proxy (let alone two) on their personal site. So the simple nginx config above works fine (my HTTP->HTTPS config is the same lines).

MartinHatch[/url]":11c9bhcg]

bthylafh[/url]":11c9bhcg]In before the nth iteration of WHY ISN'T ARS HTTPS WHARRGARBL.

It is in HTTPS for subscribers

Spoiler

It wasn't in November when I set up my ttrss feeds after buying premium. The RSS URI I have in my ttrss feed is definitely plaintext (and all the article links coming from it, like this one)... but the ones available as of this story's publication are now HTTPS. Progress! Thank you, Ars! <3

Disregard that, apparently ttrss is ruining everything and forcing plaintext on all my feeds...

drosboro[/url]":11c9bhcg]Lee, is a “subscriptor” someone who uses a lot of subscripts?

Yes.

 

[Jeff S]

I would like to make a recommendation for an additional article for this series [edit: corrected; previously read 'server']: Making your webserver work over IPv6.

Ars from time to time runs articles about the need for people to start transitioning to IPv6. How about helping out with that, by explaining what challenges and pitfalls there are to getting the server working over IPv6, with all the functionality listed in this series?

 

[zarmanto]

burne_[/url]":2x1itvk1]Lee: you're a little late, actually. Had to find out the same a few months ago. If you borrowed my notes you could have saved yourself a lot of time..

No he isn't... he's early. It's just that the internet connection for his personal blog is running through a time/space warp, so he's actually interacting with us from the past!

(Either that, or Lee just hasn't gotten around to updating the copyright date, in the footer of his blog. )

 

[tinche]

Mozilla has an online SSL configuration generator that can help you get going and stay safe(r):

https://mozilla.github.io/server-side-t ... generator/

I've found it very useful. It supports generating configuration files for nginx, Apache, HAProxy and Amazon ELB.

 

[mmiller7]

Abhi Beckert[/url]":f8ingzxk]

mmiller7[/url]":f8ingzxk]

MartinHatch[/url]":f8ingzxk]Seems like an awful lot of work.

My IIS site it was a case of:

* Install SSL cert
* Configure site bindings
* Setup URL Rewrites

the last step simply performs a 302-permanent redirect to anyone trying to use normal HTTP

You forgot a few steps...

* Obtain more money
* Purchase SSL cert
* Figure out how to open the stupid IPTABLES and make it stick

Personally, I still don't see why *everything* would need to be HTTPS. I rent a very-low-end server to run a personal hobby photo album site. I'm really not concerned if someone snoops on the non-interactive flow of pictures. Nor am I worried about the speedtest.net mini-site having the random data snooped.

HTTPS sounds like a great way to bring an underspec'd server to it's knees with a fraction of the traffic. Yes, if you have accounts and logins or personal info it absolutely needs HTTPS. That doesn't mean *EVERYTHING* should be.

HTTPS is not just about snooping, it's also a security issue. Since your site is not using SSL, anybody who visits your website can be attacked.

The thing is, SSL isn't about protecting the server operator, it is about protecting ordinary people browsing the internet.

Also, SSL does not bring an underspec'd server to it's knees. I'm guessing your CPU load will increase from 99.999% idle to 99.998% idle if you enabled SSL. It's your bandwidth or disk activity or available RAM that matter on a low spec server, and encryption does nothing to make any of those work harder.

SSL is only expensive if you have a massively complicated server setup like facebook or youtube. For small sites it's free, except for learning how to implement it.

Care to point me to a free way of getting the certificate? When I've followed guides for self-issued certs everyone is scared away by the "this isn't trusted" warnings.

For under $10/mo, yes it's under-spec'd. A dual-core Atom sub-2GHz with I think 4 gigs RAM and 1TB disk? When I upload a gig of images it takes many minutes to generate and store the thumbnails - an action which only occurs on-demand when someone browses to a page where that image is required. When I monitor "top" as it's struggling I see 100-120% CPU and only about 10MB free memory. I can't imagine what SSL would do on top of all that.

And what the heck is SSL protecting these people from? Someone knowing they looked at a blurry photo of a train whizzing past? Is that really something that needs to be "protected"?

I don't see the "value added" from any perspective for the effort required.

 

[giltwist]

Side note: I've got subscriptor, and I have HTTPS Everywhere installed. However, I still seem to default to HTTP. Any thoughts?

 

[pokrface]

Jeff S[/url]":1dc8eyjj]I would like to make a recommendation for an additional article for this server: Making your webserver work over IPv6.

I'd love to, but it's a terrifying and scary prospect, honestly. I've looked at approaching it a few different ways and I still don't fully understand the best way for me to do it at home; it's something I'd want to understand fully and actually do & document before I try writing about it. So...maybe someday, but not yet.

chrisnehren[/url]":1dc8eyjj]
Yeah, I don't get that. HAProxy is not an SSL terminator (just because you can it doesn't mean you should), and the other servers do a much better job of it. Seems like unnecessary overhead to me. Also, for what it's worth, most people won't need a proxy (let alone two) on their personal site. So the simple nginx config above works fine (my HTTP->HTTPS config is the same lines).

Sure—with this, especially, there are multiple tools for the job.

My requirements & givens when trying to do this for me were as follows:
1) Requirement - implement HSTS;
2) Requirement - keep Varnish as my cache layer (more on that below)
3) Requirement - SSL termination must be multi-site compatible, since I'm running both my personal site (bigdinosaur.org & all subdomains) and the Chronicles of George on the same web server
4) Requirement - solution should be (relatively) easy to configure and should also be something under active development—no abandoned projects.
5) Given - Basically unlimited hardware, since I'm self-hosting

Re: Varnish - I'm not confident that Nginx's static caching abilities are better than Varnish's, and I've got a good and mature VCL config set up that does exactly what I need to do any bypasses cache where I need for everything I'm hosting (eleven distinct web sites, including instances of Discourse, Piwik, Roundcube, and Ghost). I have first-hand experience with how Varnish helps under a nice solid reddit hug, since the Chronicles of George gets mentioned pretty regularly on various subreddits and can sometimes spike up to 200+ requests a second for an hour or two at a time. Same thing happens when I publish a new episode of Fangs, my little Elite: Dangerous webcomic. Keeping varnish in play in situations like that keeps my response times consistently low by every measurement I can make (including synthetic tests like blitz.io). So, rather than invest time in testing out Nginx's proxy cache, I stuck with Varnish.

Multisite compatibility was a big deal, too, since I have three different domains in place—bigdinosaur.org, chroniclesofgeorge.com, and bigsaur.us (which I don't host anything on but I might, at some point—right now I use it for link shortening). I looked at four SSL termination solutions here—nginx, stunnel, stud, and haproxy. Out of the three, I went with haproxy because stud hasn't been updated for years, stunnel's multisite support looked problematic, and doing this with haproxy looked simpler and more lightweight than adding a full second nginx instance.

A big disclaimer with any guide like this is that web configurations are crazy-variable and what works perfectly for one person might not work for another. Doing SSL termination with haproxy or any other separate ssl terminator makes for a relatively portable HSTS-compliant solution that you can drop in in front of pretty much anything; that was the impetus for writing this up for Ars.

 

[pokrface]

Also, with respect to paying for SSL certificates—every two years, I drop $60 with StartSSL for a class 2 "identity verification." They look at my driver's license and cell phone bill to verify my identity—because vouching for your identity is, after all, one function of a root certificate authority—and that $60 gets me as many SSL certificates as I want for as long as the validation is good (30 days, I think—I'd have to look).

In other words, while shitty CAs like godaddy et al can charge literally hundreds of dollars PER CERTIFICATE, I've got my class 2 personal certs, 3x wildcard SSL/TLS certs (*.bigdinosaur.org, *.chroniclesofgeorge.com, and *.bigsaur.us), and a few other misc certs like one for my XMPP server, for a single $60 fee every two years. The wildcard certs aren't always the best choice, but they are for me, and I use the single *.bigdinosaur.org cert for all that domain's web sites and also for my e-mail server, my Mumble server, and probably for a couple of other things I've forgotten about.

It's not free (though startssl DOES have a free tier as well for single sites), but it's absolutely worth the money. $60 every two years for effectively unlimited SSL certs is a hell of a deal.

 

[Whiner42]

Nice piece, Lee. It's great to see how these things can be done.

I do object to the moral language though: "It's the right thing to do" ? Shades of Wilford Brimley and Quaker Oats!

Depending on the situation (as mmiller7 pointed out), it certainly may be the smart thing to do.

 

[pokrface]

Whiner42[/url]":320wqwtp]I do object to the moral language though: "It's the right thing to do" ? Shades of Wilford Brimley and Quaker Oats!

GreggN[/url]":320wqwtp]I still oppose the idea that ALL sites need to be HTTPS. Even if you go through the effort of getting a free certificate, you still have to go through the work of installing a new certificate every year. We have dozens of servers that go months without being touched....

It is the right thing to do, IMO, since every site that goes HTTPS-only moves the web closer to an encrypted-by-default state.

As to the difficulty—yeah, it's not necessarily easy at scale, though judging by your message that's only partially on the actual certificate system. With wildcard certificates or SAN + SNI, you don't have to have 10,000 certificates for 10,000 servers—you can use one per domain, period. SSL/TLS certificate deployment to servers is an OS-level kind of task, not an application one, so the way to go would be to script your certificate update & deployment procedure like any other software infrastructure update task.

Once every 2 years or whatever your preferred expiration period is, you get your updated certs, stage them, and auto-update them. Hell, make a juju charm and make it super-easy. Living in a windows word? Build a GPO or whatever active directory uses these days for mandatory automated configuration updates.

Yeah, I know, organizational inertia is heavy and actually doing it is a PITA. I've been there, believe me. Maybe your company has a policy that all servers must have individually-scoped SSL/TLS certificates with no SANs for audibility or something similarly stupid (not judging—like I said, I wore an enterprise sysadmin hat for many years and I've seen a lot of dumb mandated shit). But the problem in cases like that is not wholly with the tech—the problem is with the organization.

 

[Balderstrom]

Katana314[/url]":3i137zi2]Pretty much stopped reading at the "prerequisites" part, for a reason I already knew; my host is a shared host. It costs about $6 a month, and I can't justify doubling/tripling those costs to prevent the NSA from seeing it. It's sad that for that reason alone I'm going to be at the bottom of the newfangled Google search result rankings, but such is life.

I get how awesome HTTPS is, but sometimes I feel like the browser developers aren't actually aware of *why* all sites haven't implemented it straight away.

Digital Ocean - $5 / month VPS, $6 if you enable backups on the droplet.

As far as HTTPS is concerned, if you don't have Deep Pockets, your fangdangled "secure" site wont be getting a SSL certificate that can handle mixed content cleanly --- until that issue can be resolved, HTTPS everywhere is for the big boys only.

 

[Erorus]

Personally, I still don't see why *everything* would need to be HTTPS.

My sites are all HTTPS because I don't want my visitor's ISP to MITM my code. Yes, it does happen. Comcast was thinking about sending copyright infringement warnings to their customers via MITM on HTTP pages, by adding their own scripts. Airports and hotels can't be trusted not to change (or add to) your site's ad providers with their own. Plus, I don't want my visitors' mobile providers trying to re-compress (and possibly screwing up) my scripts and images to save bandwidth. My sites are HTTPS because I don't trust my visitors' ISPs.

At the same time we’re going to start participating in HSTS—that’s "HTTP Strict Transport Security," a way to ensure that your site communicates to your visitors that not only do you support HTTPS, but that you insist on it.

You should really put a warning on this for your readers. HSTS means you cannot go back to plaintext on a whim. If you set HSTS for a year, then your SSL certificate runs out or you have hosting problems and need to go on shared hosting temporarily, or anything happens where you no longer have SSL, then your visitors can't get to your site until you either fix your SSL or the HSTS expires (which is a year since they visited your site). HSTS says, "Talk to me with HTTPS, or fail completely." Important for banks and other sensitive sites, less important for others.

In order to go from HSTS to using standard HTTP, even temporarily, you need to continue hosting on SSL, sending out a "Strict-Transport-Security: max-age=0" header, hoping all your visitors stop by and see it before you have to turn off SSL. The includeSubDomains header makes this even more important. With that, you can no longer have any subdomains that are HTTP-only (obviously). This includes admin-only subdomains (for which you may not want to pay for a cert), or a blog or other non-critical subdomain, or maybe a subdomain that points to a CDN... etc. When most people get an SSL cert, it covers the domain and the www subdomain. If you use includeSubDomains on your HSTS, then a month down the road you want to expand and try a custom subdomain, you're forced to get a new cert immediately, which will cost more money since you now have to cover more subdomains, instead of just using it plaintext for a while.

HSTS is a good thing, and I use it on my sites (I like having the user's browser doing the https redirect automatically), but you need to be mindful when using it. My max-age is 2 weeks, which is long enough to protect most of my visitors (since it will refresh every time they see it), but short enough that if I screw something up, my visitors aren't permanently barred from using that domain anymore.

 

[ajmas]

bthylafh[/url]":354659e1]In before the nth iteration of WHY ISN'T ARS HTTPS WHARRGARBL.

You can add this to "why doesn't Ars support IPv6?". As much as we would like to see Ars support both and we see these technologies trotted out in a number of articles, the people running the show and the people providing the content aren't the same.

It believe it is really Conde Nast that should be waking up and making these changes. Actually it would be interesting to find for certain what Conde Nast is responsible in terms of infrastructure and what the Ars team is?

As for HTTPS, the devil is in the details. Think dual IPv4/IPv6 stack, named virtual hosts and getting your head straight around certificates, public keys and private keys. Essentially there are too many moving parts for a simple setup. If security doesn't matter then HTTP is so easy and saves many head hairs.