As of now, this blog’s primary address is https://www.tbray.org/ongoing; note the red “s”. That means your communication with it is private, which I think is the way the whole Internet should be.
Depending which browser you’re using, you should see a little lock or some such in the address bar. On the right are readouts from (top down) Chrome, Safari, and Firefox. You can click on that readout to get some information on the privacy/security settings.
What It Means · The way this is set up, you can be pretty sure, when you see that lock, of two things:
First, that your browser is really connected to www.tbray.org, not some other site pretending to be mine.
Second, that the traffic between tbray.org and your browser is encrypted strongly enough that, should someone be watching it (and quite likely someone is), it would be very difficult for them to find out what I’m sending you and you’re sending me.
Why It Matters · There are a bunch of issues here, but privacy is at the center:
This blog isn’t terribly controversial. But if only the “controversial” stuff is private, then privacy is itself suspicious. Thus, privacy should be on by default.
People use the Internet in public places where others can listen in. If privacy is on by default, they can worry less.
People rely on WiFi encryption and the like to protect their conversations; but sometimes it doesn’t. If privacy is on by default, you have another layer of protection.
In many parts of the world, for example the United States, it is quite likely that employees of your government are collecting and archiving quite a lot of the traffic flowing across the Internet.
Likely these people are honorable public servants convinced that they working to protect everyone’s safety. History shows, however, that they often err on the side of intrusiveness, and suspicion of anyone with opinions outside the mainstream. History further shows that governments sometimes go seriously off the rails and that when this occurs, reasonable-sounding Public Safety measures are misused as instruments of oppression.
And of course, in many nations, the interests of government employees are very poorly aligned with those of the public.
For these reasons, I am convinced that privacy by default is generally in the better interests of society as a whole.
It is good to reduce the effectiveness of phishing attacks.
Running a Web Site? · Why not turn on privacy by default? It doesn’t cost much, and you’ll be doing the Internet, and the people who use it, a favor.
[If you’re not a geek, you can probably stop reading now.]
How It Works · It’s complicated; a triumph of pure math and human creativity. I’m not going to do a deep-dive on Public Key Encryption and TLS and so on. But if you really want to know, I recommend The First Few Milliseconds of an HTTPS Connection by Jeff Moser, an impressive walk-through of what actually really happens when the address begins with “https”.
Downsides · There are no free lunches, and this is no exception. That encryption requires quite a lot of computation, which isn’t free. But it’s actually amazingly cheap; the libraries and hardware have been optimized to the point where it’s not a big deal.
On the other hand, setting up the secure connection (the subject of Jeff Moser’s piece linked above) does require considerable chatter back and forth between the browser and server while you’re getting things going. On a high-latency Internet connection, say satellite Internet or an overloaded shared hotel connection, this can really hurt. Sterling Udell, in a G+ conversation, had some good links and personal experience.
Also, while server-to-browser HTTP caching still works just fine, HTTPS breaks quite a bit of intermediate-caching infrastructure. My feeling is that this just a cost we’ll have to live with.
From the developer’s point of view it’s essentially free; all the libraries you use to talk to the Web will cheerfully use either HTTP or HTTPS, on request.
Costs and Administration · On the client, HTTPS is free. But to set this up on tbray.org, I had to invest some time and money. You have to get a certificate and configure your Web server to use it. I asked my personal Internet Security Consultant Paul Hoffman where to go and he recommended SSLs.com, who re-sell RapidSSL certificates for less than RapidSSL itself does.
SSLs.com was straightforward and convenient to deal with. I asked Paul how he’d found them and he said “I typed ‘cheap SSL certificates’ into Google.” OK then. I wanted a “wildcard certificate” which will work not just for anything-not-just-www.tbray.org, which currently costs about US$90/year.
If you’re OK with just hard-wiring it to a particular domain, it’s way less, down in the $10/year region. In fact, I’m starting to hear talk about services offering them for free.
If I wanted to do it really, really right I would have had to pay up and get tbray.org a dedicated IP address. In the interim, things basically work OK, if you’re using a reasonably modern browser and aren’t on Windows XP. I can live with those limitations.
Geekery ·
I had to do some command line openssl
incantations to make
keys and requests and so on and so forth; but it was all spelled out in the
SSLs.com instructions.
I had to fiddle with
my publishing
software to wire in a few “https” strings, and also a few relative URIs,
for example //apis.google.com/js/plusone.js
; note the leading
double-slash. I apologize for subscribers to my feed, who had everything show
up as new because of the switchover.
Turn off HTTP? · For the moment, you can still get here through HTTP-without-the-S. I could auto-redirect to keep that from happening, or use HSTS to require the S.
However, the pointers to here from the Atom feed, and the ones I’ll post to Twitter and G+ and so on, will all be HTTPS. So that’s where most of the traffic will go.
But for the sake of the people on satellite Internet and Windows XP, the old-fashioned no-privacy gates are still open. For a while.
Comment feed for ongoing:
From: Dustin Q (Dec 03 2012, at 00:49)
FYI, I subscribe using google reader, and your inline image doesn't show up there, there's a broken image placeholder instead. Surely a side-effect of the new s.
[link]
From: Emanuel (Dec 03 2012, at 01:44)
Good points, I'd have preferred a stronger statement forcing HTTPS by default ;)
[link]
From: Bruno (Dec 03 2012, at 01:57)
Rergarding the cost factor, you can get a free basic certificate at startssl.com. There is an important difference between $10/year and free.
There are community efforts, as well, of course, most notably cacert.org. But if the certificate is not trusted by default by all major web browsers, only very skilled users are going to be able to handle it in a secure manner.
[link]
From: James Manger (Dec 03 2012, at 03:17)
I visited https://www.tbray.org from my Android phone... and got a security warning. The domain names in the URI and cert did not match. The cert was for favcolor.net!
Presumably the browser on my HTC Android 2.3.3 phone is not setting the Server Name Indication (SNI). Hence your server cannot tell which of the sites sharing your IP address I want at the start of the TLS handshake so the wrong cert is returned. :-(
Perhaps it is time for an updated phone.
[link]
From: Mike (Dec 03 2012, at 06:37)
The decision by MSFT to not implement SNI extensions on any version of IE released for Windows XP is such a disappointment. I work for a reasonably large shared hosting company. We'll happily put tens of thousands of users on a single IP address if they're HTTP-only, but as soon as they buy a cert we have to give them their own IP. Because of this, we have to just route whole /24s and /20s on our load balancer at the HTTPS serverfarm to accomodate them. And while you're bold enough to basically say "windows XP users won't get HTTPS" we unfortunately can't make that call. Not until XP falls below desktop linux in market share.
[link]
From: John Cowan (Dec 03 2012, at 07:15)
I'm reading this on Windows XP using Google Chrome. I don't see any issues; what should I expect?
[link]
From: Michael Zajac (Dec 03 2012, at 09:32)
As a non-US citizen, wouldn’t I assume that US law enforcement agencies can have full access to all of my encryption keys issued by US-based certificate authorities, without a warrant?
Anyone know of a Canadian CA?
[link]
From: Matt (Dec 03 2012, at 09:47)
@James, indeed the lack of SNI support is the biggest issue with doing https in a virtual host environment. As Tim and I were setting this up yesterday I was pondering what clients it would break.
I knew about the IE under XP, and figured there'd probably be a few libraries used by bots and scripts that might not handle SNI properly, but I never would have thought an Android based browser would have an issue. That's a little disappointing. Fortunately in my Jellybean based phone it seems to work fine.
And fortunately for Tim I have few enough https based vhosts if it really becomes a problem I don't mind making tbray.org the default https vhost so it works globally, even for brain dead clients. :)
[link]
From: Paul Downey (Dec 03 2012, at 10:11)
The use of the word "privacy" rankles with me a *lot*, given it's not you who can see my reading your blog, Google and Adobe and who knows else are tracking my surfing:
http://www.flickr.com/photos/psd/8242260898
Anyway, apart from leaking cookies, to all and sundry, the benefit of using HTTPS I value most for important sites is increasing the integrity of the content and reducing the risk of it being tampered with in transit.
[link]
From: scott f (Dec 03 2012, at 11:35)
@James Manger (or anyone with an Android 2.x phone): can you run Firefox Mobile? If so, does it handle the cert properly?
I agree with this article and recently switched my personal blog over to HTTPS using a free StartSSL certificate. If you're serving your site from Nginx, there's a very helpful guide here: http://blog.ruilopes.com/post/3678866680/from-http-to-https-with-free-certificates
[link]
From: Michael Pyne (Dec 03 2012, at 12:13)
@Michael Zajac: My understanding is that the CA never knows your encryption key in the first place. Your certificate request to the CA has enough information to prove that *you* know the private key without actually divulging it, and that certificate (w/ public key) is what the CA is signing, not your private key.
[link]
From: Arek Dreyer (Dec 03 2012, at 12:16)
I'm a big fan of startssl.com. It's free.
[link]
From: Rob... (Dec 03 2012, at 12:28)
Paul,
To solve the leaky cookie issue, I use Ghostery. (I acknowledge that I'm hypocritical in using Google Analytics on my website!)
I have to admit that I'm tempted to do the same as Tim as I find his arguments compelling. Time to talk to my host and see how much effort it would be.
Regards,
Rob...
[link]
From: scott f (Dec 03 2012, at 14:31)
Tim, take a look at your comment script: it seems unable to handle https web addresses. It added an extra "http://" in front of my address in my last comment, breaking the link. This will be increasingly important to fix if people take your advice. :)
[link]
From: Damjan (Dec 03 2012, at 18:35)
@Michael Pyne
sure, they can't decrypt the traffic between the browser and your server, if they only listen passively.
But, a CA can get them a "valid" certificate for your domain and they can then inject their own proxy server, an active MItM. The client browser will not warn you.
Unless you use something like
http://perspectives-project.org/
[link]
From: James Holderness (Dec 03 2012, at 22:12)
An unfortunate side effect of this update is that all the atom:ids in your feed have now changed as well. As a result, many feed readers are probably seeing a flood of duplicate articles (mine certainly was).
Not that there's much point in fixing that now. It's just sad that after years of having an Atom feed which is specifically designed to have immutable ids so you can change your links without breaking things, the one time you actually need to make a change, it all goes to pot. ;)
Also, as someone else pointed out, the Locks image is broken in the feed. Nothing to do with https though - you've somehow got it as Locks.jpg in the feed, but Locks.png on the site.
[link]
From: Aristotle Pagaltzis (Dec 04 2012, at 00:04)
Duplicate feed items, how? Isn’t your feed Atom with properly unchanging IDs? Et tu, Brutus?
[link]
From: Tim (Dec 04 2012, at 22:16)
James Henstridge: I only bothered to program those three IDPs into FavColor. AccountChooser doesn’t know about any IDPs, it just stores an IDP domain if a site said it was used for login (and tries to grab a favicon for decoration).
[link]
From: James Manger (Dec 05 2012, at 03:46)
@Matt
I now notice tbray.org is the default cert for this IP address. That now works, but of course favcolor.net no longer does.
It looks like you need Android 3 or 4 to have SNI support in the default browser, which is only 30% of Android devices today (http://en.wikipedia.org/wiki/File:Android_historical_version_distribution.png).
@scottf
Firefox Mobile isn't shown to my HTC Desire in Google Play -- presumably because that app isn't supported on this device. No luck there.
[link]
From: Jacek Kopecky (Dec 05 2012, at 04:20)
Hi Tim, fyi, you replied in the wrong post, it seems.
[link]
From: Terry Jones (Dec 05 2012, at 19:36)
Hey Tim.
I was reminded of your post yesterday when I discovered my ISP (TalkTalk, in the UK) doing this: http://blogs.fluidinfo.com/terry/2012/12/05/destructive-invasive-and-dangerous-behavior-by-uk-isp-talktalk-aka-stalkstalk/
Terry
[link]
From: Will Norris (Dec 06 2012, at 10:59)
Tim, I notice you don't redirect from http to https, so what do you really mean "by default"?
Also, are you concerned about the search engine implications of having two URLs with duplicate content? Currently, I have a separate https://willnorris.com/robots.txt that prevents crawling (though now after reading this post, I may reverse that)
[link]
From: Ole Eichhorn (Dec 06 2012, at 11:35)
Your blog has a website? Who knew? :)
Always read it via RSS
[link]
From: Karl Brodowsky (Dec 06 2012, at 14:08)
There is an issue to consider with organizations which restrict the usage of https. Two reasons are mentioned for this:
* They want to avoid having channels through which confidential information can slip out unwatched.
* They want to stop malware from coming in at proxy level.
Some disable https at firewall level, some put in a man-in-the middle and let users say OK to a suspicious certificate or distribute that certificate silently through regular update mechanisms.
I agree very much with your arguments in favor for using https, but I think that it will take some time for companies to get used to it.
[link]