Back to: Service update | Forward to: Apology

Service announcement: upcoming outage(s)

Tomorrow morning (UK time) we will be updating the operating system on the server this blog and website runs on. Service may be intermittent as we're going to have to reboot it at least once. (In case you're wondering it's on Debian Stable, but an old release thereof—so it's time to blow off the cobwebs and bring it up to date.)

[this stage is now completed]

Some time in October the server is going to be switched off and spend about six hours overnight in the back of a truck as it is moved to a new hosting centre. I'll give you some more warning in the days before the move. Note that this is "overnight" in UK time, so it'll be an afternoon outage for most of you.

Next, Google have (un-)helpfully announced that, in an attempt to drive the internet onto SSL (to reduce third-party snooping) they are soon going to begin down-ranking search results from non-encrypted web servers (i.e. results obtained over HTTP, not HTTPS).

Now, speaking personally, this is an inconvenience to me. My blog is public, and if you post a comment on it you are posting it with the expectation of it being read by all and sundry. I don't need a secure server for what I do on the web: I'm not running an e-commerce site.

However, I'm all in favour of reducing corporate and government snooping on the open internet. And I'm all in favour of my blog still featuring high in the search results when you hunt for my name.

So, once we've done the operating system upgrade, we will be adding a multi-homed SSL-capable web server to this system. Once we're done you will be able to find the blog via https://www.accelerando.org/ as well as http://www.accelerando.org. (We'll probably make some other changes, too, including allowing you to leave out the www prefix. Shocking, I know.)

However. This machine provides web services for multiple domains, and in order to provide a secure web service for multiple virtual hosts with only one IP address (they're in short supply) we have to use a server-side extension called SNI. SNI is not supported by some older web browsers, notably Internet Explorer 6 on any operating system, or IE running on Windows XP, or Safari on XP.

Let me emphasize that the site will remain fully accessible and functional via unencrypted HTTP, just like you're using right now. However, if you want to thumb your nose at the NSA and for some reason insist on running Windows XP, you'll need to grab a copy of Firefox or Opera.

46 Comments

1:

SNI is also not supported in the default browser in Android 2.x. Honeycomb and later are fine, though.

Will antipope.org also have https access?

2:

On SSL: same bugbear that comes up in so many other contexts, encrypting things that don't need to be encrypted. The rule of thumb is a 10% hit on CPU cycles and therefore watts just for the packet pushing. That stuff adds up... somewhere will be the maths about how much crypto leads to the requirement for a whole extra coal fired power station.

"Leaving off the www" is just another way of saying configure an A record for the domain and point it at the main website since that's what people expect. Which is a good thing really.

Bugger about needing SNI though :/

3:

Can't believe you accepted defeat on www - what next you announce that you are watching Dr Who?

4:

SSL taking up 10% of your CPU is a vastly outdated canard.

http://serverfault.com/questions/570387/https-overhead-compared-to-http

(Answer from Google engineer: less than 1% on modern machines. A few more packets -- and more importantly, round trips -- at the beginning of the connection.)

5:

I am sure I shall be able to cope.

You have that rare combination of understanding the tech and good communication skills. I doubt I'd get so clear a notice from Facebook.

6:

AFAIK, it's recommended practice to redirect either the no-www or the www variant to the other, so that there's one canonical URL. This should help your Google rankings in that it converges all inbound links on the same final URL.

7:

Okay - rule of thumb *was* that. This is interesting, thanks for the link. It's not quite the same to claim 1% on machines with otherwise computationally intensive backend tasks though, versus sites that just do (mostly) packet pushing.

The other way of saying that is that crypto algorithms optimised for modern chipsets are very efficient. Google folks would know best, of course, since power is maybe their most significant operating cost. Maybe "encrypt everything" is okay these days...

8:

SSL really doesn't add anything, even on a site like this that's basically all text. Well, at the point like this when it's 7 comments you might notice the load if you try really hard. When we're over the 100 comments size you'd struggle, when we're over 300, you really won't.

As a matter of interest, although I know people still use XP, how many people hit your various sites using IE6? The general rule of thumb these days is not to support much back past IE8 and there are plenty of sites that don't support anything except IE10 if they support IE at all. Admittedly they do a lot more singing and dancing than your site though.

9:

know people still use XP, how many people hit your various sites using IE6?

This month, 1.86% of hits came from MSIE 6. A further 1.26% came from MSIE 7 and 0.94% from MSIE 8.

If I was prioritizing support via browser the only one I would bother about is Mozilla/5.0 -- with 55% of total hits. Nothing else delivers more than 3.10% of total volume, and that's an RSS aggregator of some kind -- the other browsers max out at 1.85% (MSIE 6).

10:

Sod IE6, this site works perfectly well in Lynx! I suspect I could even add comments if I had a non google account.

11:

I guess I'm surprised for your fan base MSIE 6 is that high.

I'm not surprised to see you have a big Mozilla user base though.

I am surprised not to see mobile browsers up there, which would normally be mobile webkit unless they're misreported.

12:

Sorry about that, but I don't get to choose a decent browser instead of IE.

13:

Nope, you need Javascript to comment. But I believe Links should work.

14:

Then just keep using the old (non-encrypted) HTTP server to access the blog. It'll still work!

15:

One trick that you may (or may not) find useful is to acquire one of the many usb devices which provide random numbers, and plug it into the server. Some of the overhead for SSL isn't actual CPU load, but is down to the OS scrabbling around to keep /dev/random topped up.

Give it an easy source of random numbers, and it'll use that instead of grinding CPU, and thus will keep the server load down a bit.

Most of the time, BTW, this advice will be superfluous. However, you being a famous author and one of the vanishingly few internet commentators who actually understands the subject, every so often you'll get slashdotted. On an SSL server, slashdotting tends to burn through /dev/random pretty quickly, and in such circumstances being able to top it up easily is really quite nice.

16:

However, you being a famous author and one of the vanishingly few internet commentators who actually understands the subject, every so often you'll get slashdotted.

Happens every month. (Boingboing and Hacker News too.) It's no big deal.

Now, breaking a political news story before the major newspapers latch on is an entirely different matter ...

17:

You were namechecked in TheReg a couple of days ago too although you were described as a "one-time-sysadmin" rather than a Perl wrangler.

http://forums.theregister.co.uk/forum/1/2014/08/25/brit_scifi_author_alistair_reynolds_says_ms_word_drives_me_to_distraction/

18:

Small headsup on the Debian upgrade. When I recently did a Squeeze>Wheezy upgrade on my home server it failed to install the upgraded grub boot sector and left the system unbootable (the boot sector grub seemed to be looking for an on-disk file that isn't in the wheezy install). Fun and games with a LiveCD ensued. Probably best to re-run the grub-install command before rebooting !

Strangely there was no mention of this possible issue in the upgrade release notes.

19:

NI is not supported by some older web browsers, notably Internet Explorer 6 on any operating system, or IE running on Windows XP, or Safari on XP...if you want to thumb your nose at the NSA and for some reason insist on running Windows XP, you'll need to grab a copy of Firefox or Opera.

Which camp does chrome belong to? I assume that given google is driving this it would be alongside Firefox or Opera but ass/you/me/making of, etcetera

20:

Pro tip Charlie I wouldn't rush to conclusions about the google prefers ssl sites just yet - its an interesting idea but has a lot of opportunities to fuck things up.

The pros are in the wait and see mode at the moment - site migrations are non trivial events I should know having had to dig several major publishers sites out of self inflicted holes.

21:

Assuming I'm still on WinXP (very likely) I assume if I use Google Chrome, rather than IE8 I can still find you?
Or can IE8 "see" SNI anyway?

22:

This month, 1.86% of hits came from MSIE 6. A further 1.26% came from MSIE 7 and 0.94% from MSIE 8

Interesting how things vary, I've got those three at 0.14%, 7.28% and 8.5% for the past month and not that different for the past 6 months. IE6 seemed to be holding on at a much higher level until I realised the University penetration tester was using that UA and dropped it. Combined IE is a quarter of our traffic and Chrome a third.

23:

Small headsup on the Debian upgrade.

I'm outsourcing the upgrade to someone who does this for a living (a sometime Debian package maintainer and full-time professional sysadmin).

And in event of remote whoopsies, there is a serial console connected to a TMUX with ssh login available.

24:

There's another longer-term reason why having SSL support may be useful to me, but I'm not talking about it in public (because workflow-related stuff). In any event, I haven't actually done it yet.

25:

You just need to use the same URL as ever. You won't be able to use the encrypted connection but just because I'm building a new porch doesn't mean that I'm going to brick up the back door.

26:

Some of us have browsers that lie about these things. too.

27:

Your sites may not process financial transactions or store sensitive user data, but SSL does a bit more than just protect users from having their traffic snooped. It also assures us that what we are reading under your name are actually your words. So, there's that.

28:

HTTPS is definitely a good idea on your website, since people need to log into post comments. Sending unprotected passwords is dangerous because most people use the same passwords on multiple sites, and it's reasonably easy to intercept passwords over WiFi (even encrypted WiFi access points, as long as there's one password for everyone).

Or we could all use OpenID, but then we get URLs instead of user names..

29:

The one other issue is to prevent password sniffing by intermediary web proxies.

This site uses passwords SOLELY as an anti-spam measure. Blog comment spammers see the "register a password" page and generally fuck off immediately rather then jumping through hoops. There aren't actually any hoops -- or checks on your email address: you can enter any damn thing you want -- but it deters them, so it does the job.

However, someone who's not terribly cluefull might use the same password for commenting on my blog that they use for, say, their email account or online banking. This is A REALLY BAD IDEA and they should really use a password database like 1Password or SplashID to track separate passwords for each site they visit ... but I've got no way of knowing that.

The risks of a password breach are fairly minimal. My server is locked down reasonably tightly, and I try to minimize its attack surface as much as possible, mostly by following common-sense measures (and paying an expert to do stuff that's outside my experience). However, if my site was breached, there's an RDBMS sitting around with a table of username/password tuples that might be fed into some sort of botnet and used to go fishing for valuable targets.

It's much more likely that someone might go through a "free public wifi" hotspot being broadcast by some scammer who has set up a router and a modified squid proxy to MITM incoming requests and snoop for web forms with "password" fields. That I have no control over, and as long as people check my blog from web cafes or public locations there's nothing I can do to prevent it ... except that if they do so over SSL then the MITM attacker gets nothing.

So the increase in security afforded by using SSL on this site is minimal, and only applies to clueless users WHO REUSE PASSWORDS PROMISCUOUSLY (hint: don't let it be you, m'kay?). But it's still probably worth doing.

30:
The other way of saying that is that crypto algorithms optimised for modern chipsets are very efficient. Google folks would know best, of course, since power is maybe their most significant operating cost. Maybe "encrypt everything" is okay these days...

Most modern CPUs support the AES-NI hardware-accelerated instruction set extension which makes it pretty cheap to do (both encryption and decryption). When AES-NI is unavailable, Google also uses ChaCha20-Poly1305 on their servers and in Chrome, which was designed to be fast in software.

Mozilla published recommended TLS configurations for anyone interested; it also gets an "A" on the Qualsys SSL test

31:

except that if they do so over SSL then the MITM attacker gets nothing.

Well, except if the user clicks "Proceed anyway" or equivalent when the browser says that the certificate does not match the server. Not that there's much you can do about that, either.

And now I'll doff the work hat and say that this is probably a problem if somebody reuses the passwords, for reasons already said. And it's still more secure than the current setup.

32:

The latest versions of Links don't support javascript (even though that's one of the things that originally made Links famous), because "it's too buggy", according to the Links docs. (Whether "it" refers to Links' implementation of javascript, or to javascript in general, is not made clear.) :)

Since neither w3m nor lynx support javascript either, I think a graphical browser may be required to post comments on this site at present.

33:

Quite - there are plenty of people who grew used to a culture of self-signed certs in the workplace, where they were advised and encouraged to ignore or work past browser warnings. Organisations have had to grow enough maturity to build CAs and install their root certs on managed devices, but that's far from ubiquitous even now in a world where browsers work harder to convince users that self-signed certs are dodgy. But at least most users will have been at the receiving end of some of that communication now.

ISTR there's a cool xkcd about harvesting passwords from habitual password re-users by setting up a dummy site with a registration page. Forget how long ago.

BTW Mr Stross, I read Rhesus File last week and it has reminded me just how similar your working experience was to mine. I didn't take up writing (yet... I have always wanted to... I'm sure there's still time), instead went into architecture then management (PHB). But your example showing it's possible is very reassuring and thank you.

Dunno if you were still around the scary devil monastery in the early noughties, but I was there and at clpm a little at that time. Did web applications with Perl, but possibly the coolest thing I did involved cobbling together an NMS-like tool from Net::SNMP, rrdtool/mrtg and a database. Managed about 20 floors worth of network gear. Could map a logged-in user to physical location via switch port and structured cabling. But what I remember of course is my eyes swimming from screen after screen of numeric oids and getting unpleasantly intimate with a bunch of Nortel MIBs.

But that was then. Today I'm going to express my team's work allocations as post-it notes on a whiteboard, because we have been instructed we now use agile methods for management. No-one has advised how that is supposed to work, of course, but informal advise is to focus on appearances. I've considered holding stand up meetings where the team literally forms a scrum and tries to push over the wall, but that might be laying it on a bit thick.

34:

SSL, finally. Keeping plain HTTP - very wise.

Encryption's not needed? Fine, but make it possible anyway. Google's push is decent here, as much as SSL is a crutch, it's better than the pothole (that the plain HTTP is).

35:
Or we could all use OpenID, but then we get URLs instead of user names..

Er, I get a username, not a URL, with my Google-provided OpenID account here.

36:

> reminded me just how similar your working
> experience was to mine.

I think there are many of us. Our paths diverged after Charlie went to writing full-time, but the earlier similarities are eerie.

37:

I'm curious, why would not requiring the www be a bad thing? From what I had understood, it is a holdover from when you would have www.site.tld for html stuff, ftp.site.tld for files, etc.

38:

Quite - there are plenty of people who grew used to a culture of self-signed certs in the workplace, where they were advised and encouraged to ignore or work past browser warnings. Organisations have had to grow enough maturity to build CAs and install their root certs on managed devices, but that's far from ubiquitous even now in a world where browsers work harder to convince users that self-signed certs are dodgy. But at least most users will have been at the receiving end of some of that communication now.

I agree, most organizations do not use self-signed certs anymore, except occasionally in development and testing environments. While there are problems with the cert signing procedures, I think this is a Good Thing to do.

However, there still is some bad usage culture. Earlier this year (I think, recently anyway) a large Finnish bank (or a Finnish branch of a bank) forgot to update its certificate used in the online banking system. The certificate expired, of course, and customers' browsers started complaining about an expired certificate. The instructions from the bank were (paraphrased) "Just ignore the warning, our online bank is still secure". This is of course quite the opposite of what you should do when your online bank's certificate has problems.

There was much screaming at my workplace when this happened.

39:

But that was then. Today I'm going to express my team's work allocations as post-it notes on a whiteboard, because we have been instructed we now use agile methods for management. No-one has advised how that is supposed to work, of course, but informal advise is to focus on appearances. I've considered holding stand up meetings where the team literally forms a scrum and tries to push over the wall, but that might be laying it on a bit thick.

We had similar problems. We found that getting the team to "make a waterfall" got quite messy and started to smell; and pairs programming always ended up with a fight over who got the chair in front of the keyboard; so we were quite excited by the thought of Extreme Programming.

Unfortunately, we've found that lycra isn't flattering on the middle aged, and it's impossible to keep the laptop's network connection up while skydiving or jumping a motorbike over a ramp.

40:

Test comment -- ignore

41:

Upgrade to Wheezy worked; blog functioning!

42:

I'd say this is off-topic, but I'm not sure there really is one, and we've discussed the one-way trip to Mars here before.
Colorado man may be headed to Mars — for good

The father is an acquaintance (and CS prof at the Air Force Academy). Somehow I don't think he needs to worry about his son dying on Mars.

43:

Hi,

Great to hear you're turning on HTTPS. I know it is a hassle - however after the last year, turning on HTTPS is a service to everyone that visits your site. Recent revelations have shown that anything that is not HTTPS can be used to inject attack vectors against users. (See this op-ed for more info: https://firstlook.org/theintercept/2014/08/15/cat-video-hack/)

Cheers

44:

There's a bit of "well duh!" about that article. It completely elides over the assumption that all browsers are as porous as Swiss cheese and that attack vectors based around browser and plug in vulnerabilities will be successful. The main point it is making is an obvious one that has nothing new about it, other than that some commercial companies are selling appliances that do this for allegedly legitimate purposes. Which only leads you to wonder about the IT security industry and the notion of white hats and their ilk. Certainly the dominant skill-set seems to be around spreading fear and mistrust in boardrooms, rather than actual technical expertise (made-up stats about the proportion of compromise due to disgruntled employees is usually enough to make business leaders mistrust their own IT departments).

Doesn't change the basic principle at all: it doesn't matter if the data comes from youtube or from warez.hackerz.org, you don't trust data from the internet . That's why releases and official downloads are supposed to come with checksums.

That said, I see that using web-of-trust CA certs helps with guaranteeing authenticity on https connections. If you've compromised the network you can compromise DNS, but you can't fake CA-signed certs. Though if you have the network you can insert your own CA cert in the first non-https Mozilla download... well or anything else the user will go ahead to install without questioning its authenticity. That is another way of saying that you're f@#ked anyway unless you're really deeply paranoid, on a level at which it isn't really worth your time to function.

Note that deep packet inspection on proxy traffic in an enterprise environment is normal, since in that case you manage the client devices and can install whatever certs you like. And this is in fact exactly the same as MITM from the point of view of either the client or the remote website. BYOD arrangements pretty much hinge on the organisation being able to do that.

45:

>> time to blow off the cobwebs

I do hope you have provided alternate housing for the spiders/dustbunnies required for system stability in the future?

46:

TL;DR: SNI's required when a SAN (multiple domain name) certificate is impractical?

Specials

Merchandise

About this Entry

This page contains a single entry by Charlie Stross published on August 27, 2014 11:33 AM.

Service update was the previous entry in this blog.

Apology is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Search this blog

Propaganda