Back to: Test Case | Forward to: On hold

Server upgrade coming

Hi there. Sorry for the hiatus on blogging; I'm just back from the Eastercon, and managed to forget to schedule an April Fool update while I was gone.

The bad news is, the hiatus is going to continue for a bit longer—and I'm switching off comments, too! The good news is, this is so that I can do a long-overdue operating system upgrade and blogging system upgrade, and add support for secure HTTP (so that google doesn't start flagging my wholly non-commercial blog as an insecure ecommerce site and downrank it in search). There may be other new features, too, when service is resumed: I particularly want to see if I can make the blog more tablet- and smartphone-friendly (while not compromising on the desktop experience).

There will be a couple of regressions, however: notably, the secure web server support will not include Internet Explorer 10 and previous releases (yep, Windows XP is officially end-of-life at this point). There may be other issues with support for older/obsolescent standards too, although I'll try to keep the system accessible to users with browsers less than a decade old.

Schedule: as of now, I'm switching off comments so that I can take a complete and consistent backup of the database and download it to my NAS, so that if everything goes pear-shaped I've got the wherewithal to rebuild everything. With close to a quarter of a million blog entries and comments, running on an ancient machine, this takes some time. (Yes, I run periodic backups. But new comments are coming in all the time, so they're incomplete.)

Once the backup is done, downloaded, and verified, my highly experienced sysadmin will do a long-overdue security audit and operating system upgrade, we'll create certificates for SSL and set up secure HTTP servers, mess with the DNS settings for to support them, and switch things back on. Then I will do a long-overdue blogging software upgrade (skipping the technology forward about five years) and make sure everything works.

We should be back up by this time next week (hopefully a few days earlier).

See you on the other side!


| Leave a comment

Testing ...

If you can see this, comments are re-enabled and the borked update attempt has been rolled back.

You should also be able to see the site via https: but there are ... anomalies; Movable Type likes to hard-code absolute URLs into things like the side-wide javascript and css loading code, and mixing http: and https: requests violates the security model in some browsers so that they fail to load (so you end up with no ability to comment and no formatting).

I'll tackle this later. There may be some, shall we say, interesting glitches ahead.


... And now I'm trying to figure out why commenting isn't working (for me) using Browser A but works fine using Browser B (this one). Groan.


... And if this works, it was just a borked cookie. I hope.

(Edit: yup, it worked, cookie thrown in bit bucket, preferred browser working again. Phew. Next stop: tweaking mod_rewrite on apache to rewrite URLs and funnel everything over https. But first I have to finish checking the copy-edits on a novel.)


Well, Chrome works for comments... ;)


Testing with Safari running under Yosemite*…

*Yes, it's old. No, I can't upgrade because my 6 TB photo library is in Aperture, which was orphaned at Yosemite.


Works here -- Windows/Firefox.


What's with the address? I get this:

403 Forbidden
You don't have permission to access / on this server.
Apache/2.4.10 (Debian) Server at Port 80

Obviously fine from the antipope address.


Chrome on Windows, the site is doing some weird shit when I try and access it via https, I keep getting thrown back into "not secure" mode when I try and navigate anywhere.

Using https for I get a 1995-looking front page, all text with no formatting or images etc. Same with Firefox. I assume this is just teething troubles.


I'm using Chrome on Win10 - & as you can see this seems to be working.
( On view that is - let's try "preview" ) ...

NOTHING can pssibly go worng / clikck / go worng / click .....


Aperture works for me under High Sierra 10.13.4. I don't use it much, but it does open and run without complaint.


But I wasn't using "https" - I was simply replying to the open page with comments.

My header line says:
&2460; |


The styling looks different with/without https. It looks normal with http, but there are no margins with https. Some kind of CSS weirdness, I guess.


ANd THAT didn't take ... the unicode was supposed to produce a lowercase "i" inside a small circle ( information-warning )
Um again.


Possibly some kind of CSS caching glitch going on? Had a look last night and it was all in serif with quite a small font size and a much wider main column. Had a look earlier today and it was still like that. But it's gone back to normal now.

(Pity, I preferred the smaller font and wider column. I thought it was a deliberate change at first. It was a lot easier to read with the much-reduced amount of scrolling required.)

My setup redirects all https requests to plain http (apart from an exception list of the handful of sites where there is actually some point to encryption), so if this works it confirms that such access is not broken...


Chrome on Windoze7:-

I'm still seeing the old http server and a "not secure" warning. Since I don't have any person info on here besides an e-mail address I don't actually care as long as this comment goes through.


typo - the linked comment should read "...any personal info..."

And this gave me "too many comments too close together" error the first time I tried to post it, so that still works.


And quick test using Internet Exploder 8 under Windoze7 (I know but it's still on my work machine) - No "not secure" warnings and address starts "http_colon_double_slash_treble_w..."


Me too - though, of course I'm on Win 10
Will try "Firefox" & see if it makes a difference ....


My advice would be to not test https until Charlie has done all the mods_rewrite bits he needs to do (Good luck with that its why I now use S3 and cloudfront for all images and everything else I can nowadays).


Works for me on Firefox.

21: shows up empty (actually as "403 Forbidden").

And it's running debian, which is good, and apache, which is... dunno, kind of 2012...?


I'll fix tomorrow. (Today, I've just been ploughing through copy edits and un-borking a bunch of lost/corrupted files -- backups are wonderful things.)


Welcome back. Working here on Firefox as well v 58.0.1 (64-bit)


The usual ball-aching Typepad login still seems to work OK on my creaking Win7/Chrome laptop.

I can't login on my iPhone 7 plus, not that I could before!


Signed in through Movable Type, using Opera on Windows 10.


Works with Firefox 59.0.2 (32-Bit) on Win7, too.

And now gone for the Real Life(tm) interference, 10 days to go till eviction. Moving my things into storage. Just as planned

On another note, sounds interesting:

VNV Nation Tour dates.


BTW, what about text-mode browsers like elinks? Any idea about them being supported?
Just setting up an old 600 MHz lifebook with Linux, so...


Doesn't Links support SSL? Last time I looked there was an SSL version, and that was the best part of a decade ago ...


Why not just leave SSL access optional instead of forcing it? That way the question doesn't arise. I get the problem re. Google's interest in misdirecting people to think that transport security is the be-all and end-all so they forget to consider the endpoints, but SSL does zip in terms of concealing what someone's looking at on this site from anyone snooping traffic, and you can always use "RewriteCond %{HTTP_USER_AGENT} Boogleot" (or whatever it is) to make it a forced option for the crawler.


Only page I'm seeing a problem with is at where the stylesheet and MT.js pages have hardcoded http:// referrals. Easiest solution is to remove the http: and leave the // (utterly wrong but all browsers support it).


Why not just leave SSL access optional instead of forcing it?

Google (and other search engines) interpret multiple distinct URLs pointing to identical content as spam.

Google will also be downranking websites that don't use SSL end-to-end in search in the very near future.

This is the real reason I'm switching.


Only page I'm seeing a problem with is at where the stylesheet and MT.js pages have hardcoded http:// referrals

Unfortunately that page is re-generated whenever the blog content changes.


If it's only SSL I see little problems, guess I'll try it out next week. I was just somewhat confused about "dropping support for older browsers". BTW, Opera Mini pn Android working, too, though long comments swallow the send-buttom...

On another note:

Since Feorag tweeted about a DAF concert some time ago, AFAIK it's available quite cheaply on ebay...


Chrome on Windows 7.
The regular website (http://) comes through in the usual style.
Going to the https:// makes it look exactly like your old version.
Hope this helps.


Signing in worked fine.
https clicking any link redirects me to http and logging in also sent me to http.

On https is fine, but for and /feorag Firefox is warning me that some elements of the page are not secure, such as images. Mixed content in other words. I also lose all stylesheets and the usual black header, just getting a very basic plain page.
/freethinkers and /fisherrow are both considered fully secure.

Google's interest in misdirecting people to think that transport security is the be-all and end-all so they forget to consider the endpoints, but SSL does zip in terms of concealing what someone's looking at on this site from anyone snooping traffic

TLS/SSL does indeed conceal what someone's looking at, though of course not perfectly due to timing / size attacks and the like.

I've seen you complain about it before and I really don't understand what you're complaining about: using TLS everywhere provides a modicum of end-to-end transport security, which is much better than nothing at all. As a pretty basic example, if you used open coffee shop wifi, someone could trivially swipe your auth token and post a long screed about their undying love of Javascript as you!

TLS is sufficient to block that kind of abuse, and indeed works better than a VPN (ideally you use both).


In theory TLS/SSL conceals what you look at, in practice it conceals close to nothing.

First, DNS lookups are being montitored and it's not a big deal to maintain a FQDN->IP map in real time, even today.

Second, no sites anywhere pad their contents to mask the size of the objects, so they may not have a copy of the bytes you saw, but they know _exactly_ where on the site you got them.

Third, all the third party add-tracking crap is monitored head and tails, and the information leaks all over the place to everybody who are willing to pay.

... And a lot of people are: Your visit to a so-called "well-monetized" web-page causes about a couple hundred requests to cascade out.

All HTTPS really does in practice, is that it makes it very hard for researchers to publish exactly what websites do to you and your browser.

Privacy is a human rights issue, and can only be tackled at a constitutional level, like free speech etc.

Plastering encryption over any and all communication without a right of privacy backed by law, means that encryption will cease to provide privacy.


I haven't worked through the protocol in detail, but I believe that SSL also makes it much easier for the likes of Google to identify whether two apparently unrelated connections come from the same client. In particular, I don't know how often browsers recreate their 'randomness'.


Using Win10 with IE 11 (yeah, I know, but it's a managed work machine), no problems bringing up the main page in SSL, but clicking comments links flips back to the http:// version of the page.


Ah - the link on the main page still directs to the non-secured site.


To clarify, the comments link at the bottom of the https:// entry directs to the non-secure comments page.


Maybe the answer for now to get https support is to simply setup an nginx proxy in front, and leave the old website behind it, not knowing that it's behind a proxy at all. This let's you concentrate on just the SSL side of things first, and then on the upgrade.



One thing good about SSL is that it considerably complicates, sometimes even for a nation state, some packet injection attacks.
E.g. Man on the side Attacks
At least this was a concern a few years ago. Maybe it's gotten better.
I've taken to running browsers in a sandbox/jail whenever possible when visiting http sites.


Uhm, not really.

Any moderately competent nation state-level actor can get hold of a SSL cert for any domain name they are for. If you think the CA-bal is trustworthy, it's only because you have not ever looked at your browsers built in list of root certificates.

Google and FaceBook &c are pushing protocol extensions for "certificante pinning", "DNS over TLS" etc. because they think they will win this race if they add just one bit more of encryption, while totally ignoring that every little step in brings us closer to state control encryption being the only legal encryption.


The trouble about using terms like 'nation state-level actor' is that it confuses the naive 99.9% of the USA and UK into thinking that equates to countries, even roughly. I doubt that it includes any of the really poor or undeveloped countries, but it definitely includes many of the USA's multinationals (and some of some other countries).


"I really don't understand what you're complaining about"

I'm complaining about the Google-led PR/propaganda/blackmail campaign to plug HTTPS under the banner of "safety" in such a way as to make yer average user on the Clapham omnibus miss the important distinction between transport security and endpoint trustedness, while also painting themselves in false "good guy" colours to distract from their status as one of the top snoopers.

For the reasons Poul-Henning Kamp points out, the protection of HTTPS is largely illusory, and that little which is not still does nothing at all to address the most likely threats. Transport security or the lack thereof is of minor significance compared with the gaping hole in web security that all browsers consider all content on all endpoints trustworthy by default. To label sites as "safe" or "unsafe" based only on the protocol, while still allowing all content (including from third parties) to load and execute unchecked (and making it hard to modify that behaviour), is mendacious and misleading, since transport attacks are rare compared with the near-certainty that at least some of the site content is not worthy of the trust accorded to it by default.

Like I said, I can quite see the reason for Charlie wanting to present this site to Google over HTTPS. I just don't see the point of making plain HTTP unavailable to ordinary users, as opposed to bots, for reasons such as Trottelreiner brought up.


"Google (and other search engines) interpret multiple distinct URLs pointing to identical content as spam."

Oh how I wish their search results reflected that interpretation...

I'm complaining about the Google-led PR/propaganda/blackmail campaign to plug HTTPS under the banner of "safety" in such a way as to make yer average user on the Clapham omnibus miss the important distinction between transport security and endpoint trustedness [...]

You're rather missing the forest for the trees here. The primary threat model TLS in this regard is protecting against is casual attacks on the end user from their own lan segment or similar. This is critically important these days because so many network access points are completely insecure, and untrustworthy in any event.

Think "a teenager in the coffee shop." If your network protocol isn't proof against that, it's not safe to use for pretty much anything in the modern world. And keep in mind the most trivial sort of attack is just what I proposed: stealing your access token and issuing commands as you.

The sorts of attacks Poul-Henning Kamp was talking about (which are far less significant than he stated in my opinion) are not really relevant. Sure, an attacker can see that you're using Charlie's blog and can even infer that they're in a coffee shop with Pigeon by trivial timing analysis, but they can't take over your email and use it to seize control of every other account just by using a simple packet sniffer. And if you're worried about nation states.. well good luck.

The sorts of problems you're talking about are real but have nothing to do with encryption. Yeah, corporations are untrustworthy and will gladly sell you to the highest bidder. You still have one less thing to worry about if you connect over TLS.

P.S. I'm typing this on a mobile phone in a coffee shop so if you see a love poem to JavaScript here you'll know my session has been hacked!


Like I said, I can quite see the reason for Charlie wanting to present this site to Google over HTTPS. I just don't see the point of making plain HTTP unavailable to ordinary users, as opposed to bots, for reasons such as Trottelreiner brought up.

There is one other reason for me to want HTTPS.

You will have noticed the username/password requirement for posting comments here. This is my #1 defense against blog comment spam, and it's been very effective -- spammers generally can't be arsed registering a username and password.

You are mostly sensible, security-aware people. But it is conceivable that someone will reuse a username/password combination on my site that they also use for something sensitive like online banking or Gmail or nuclear missile launch codes -- go figure.

Currently the login username/password travel unencrypted over HTTP. Using HTTPS will make it that little bit harder for third parties to intercept credentials, and thereby reduce the risk to non-security-minded folks. QED.


Oops, that's reminded me... [quickly changes password for nuclear missile launch control system in shed]


Am not a practitioner (of attacks, no strong interest), but stories like this, Dissecting Man-on-the-Side Attacks on MotS/MitM attacks, are what I was wondering about, including the coffee-shop/ISP versions.
Scouting around, I see coffee-shop-grade tools available, e.g.

In theory TLS/SSL conceals what you look at, in practice it conceals close to nothing.

None of these criticisms of TLS really amount to a reason not to use it or trust its security, as far as it goes.

To summarize your points in simple terms:
- TLS can't prevent an attacker from seeing which server you connect to.
- TLS can't prevent an attacker from tracking how many bytes you transferred.
- TLS doesn't help if you can't trust the place you're connecting to not to sell your data.
- A nation-state level actor can subvert the certificate system TLS is built on.

These are all true, but they're also all basically irrelevant. I'd also assert that you're wildly overstating the risks involved in someone seeing the size of objects you're transferring. Yes, they may be able to infer that you're on your bank's "Transfer Money" page -- what of it? And most of the other scenarios are less risky than that. There are some real crypto attacks based compression and the like, but they're not usually the sort of problem a regular person should worry about.

TLS is effective at preventing casual theft of credentials, email snooping, stream hijacking or injection, and those kinds of problems. The fact that it does nothing about the web site owners being bad actors or the social problem of having no recourse against capitalist excess isn't a mark against it. It hardly conceals "close to nothing."

The most we can really say is that people should be educated that someone claiming "it's encrypted" is no reason to stop asking questions about your privacy and security.


None of these criticisms of TLS really amount to a reason not to use it or trust its security, as far as it goes.

I agree with this. TLS is not the silver bullet of network security, but it does prevent easy attacks on for example passwords and other sensitive data. It doesn't help with more sophisticated attack vectors.

If you want better security, there are options. I'd start with a computer which routes everything through Tor, to help with connection tracking on your own computer, and consider the threats if I needed to do something about for example traffic rate analysis or changing exit nodes regularly.

There might be problems with having such a setup in some jurisdictions, however, and obviously it's kind of clear you are using Tor, which might by itself make yourself a target of more surveillance in other ways. Keeping your head down even more vigorously would probably mean building some system where you could steganographically put your real traffic into some kind of fake traffic, which would be theoretically easy, but practically probably hard. You'd at least need some other computer to disassemble the steganography, and that's again a new point to attack, but if it's in an another country, it might be hard for attackers to gain access to it.

A simple VPN service might also work against attackers near you, but there is the exit node - do you trust it and its owner enough?

It all depends on what are you defending yourself from. Doing some things you'd probably be better off getting off the internet altogether.

(Disclaimer: these are my opinions and not my employer's, and mostly musings, not really thought-out advice. Do think them through before trusting them. I think I need this because this is getting close to my work.)


I tried leaving a comment using the lynx browser on my slackware box. Didn't work because login with movable type is not available. Had to start up the GUI. A serious problem for the dozens of lynx users around the world.


I believe you are wrong. Chrome has for quite some time included a list of real google certs, and it's been in the news about nations that try to snoop with bogus certs getting caught that way.

But since everyone wanted their certs in Chrome and every browser, there is now Certificate Transparency which is becoming mandatory for certs. People will still be able to issue bogus certs, but they'll have to announce publicly that they are doing so, and when the rightful owner of that domain complains, I believe logs that issued such a cert will stop being trusted (we shall see how that works out in practice), which will be bad for the registrar who allowed that. So for any nation state to twist an arm to get a bogus cert will require them to have company they want to spoof play along.


I tried leaving a comment using the lynx browser on my slackware box

The comment system requires Javascript/ECMAScript support. Lynx does not (and never will) support Javascript.

ELinks will probably work (on a terminal). Javascript is the real issue with the blog ... and has been, since about 2006.


Firefox on Ubuntu Linux, not https. Lets me comment.


Non-techie W10/Firefox ... signed in okay & now let's see if it publishes.

OOC - Pretty sure I'm not alone in having to keep an eye on multiple windows/sites concurrently throughout the day: so, how do the snoopers track folks who routinely have several windows/sites running at the same time and who flip/call up different windows/site here, there & everywhere?


"Javascript is the real issue with the blog ... and has been, since about 2006."

Just out of curiosity, is that because you love javascript and everyone else hates it or because everyone else loves it and you hate it?

Or because javascript is so easy to abuse?

Or ...?


I'd start with a computer which routes everything through Tor

I have a VPN which I use at times that routes through Tor. If I forget to turn it off I can't access some banks' (plural) web sites and other various things. If you want to use the web for much of your life Tor can hurt as much as it helps.


For everyone's amusement, I built the latest version of ELinks with ECMAScript support, poked random keys until I found the sub-menu to enable said support, and loaded this page on your blog.

Sadly it threw JS errors on page open and didn't give me the ability to log in or comment.


Because I'm using off-the-shelf blogging software that requires Javascript for logging in, and is too complex to rewrite trivially.

(As to why I'm using Movable Type ... it's because I don't want to let PHP onto my server, which is the language the main rival blogging platform -- Wordpress -- is implemented in. Call it an old prejudice, but PHP seems to be one crawling mass of security holes and exploits.)


That, unfortunately, is not how TLS/SSL is being sold, and more importantly, that is not what the TLS/SSL proponents really care about.

If the people pushing TLS/SSL so hard were actually interested in improving the overall general level of security, browsers would not treat self-signed-certificates like they were HIV infected radioactive ebola virus.

If browsers silently accepted self-signed cert and then treated the connection *exactly the same* it treats an unencrypted connection *in all aspects* (ie: no padlock or anything else), then we could do wonders about passive wiretapping in no time: Any apache and nginx could just create a cert if they were not given one, and off you go.

But instead, even after Snowden, browsers got even more militant against SSC's so what's going on here ?

Quite simply, the major push here is that $BigSites don't want *anybody* to look at their traffic, not NSA, not ISPs and in particular not independent researchers.

The entire SSL/TLS push is focused on making sure nobody spies on how much you are being spied on by FaceBook, Google and the host of companies in their shadow.

To them, SSC's are 100% sure indication of MiTM attacks, I've literally had people tell me to my face that was the only thing you *could* use SSC's for (Insert distant echos of MPAA and home video here.)

The downside of rolling out SSL/TLS everywhere, is that a minor annoyance have become a major head-ache for law-enforcement, forcing politicians to implement measures, (whatever measures they can come up with) which will prevent encryption from neutering the criminal justice system, and that means encryption will also be neutererd in the places where we *really* need it.

Like it or not, "SSL everywhere" is not a technical statement, it is a political statement, and the people making it are absolutely *shit* at playing politics, so they're loosing it all as we speak.

That, unfortunately, is not how TLS/SSL is being sold, and more importantly, that is not what the TLS/SSL proponents really care about. [post about peoples' motivations snipped]

Or maybe they'd just prefer people to use the system as it's designed, which is to be resistant to man-in-the-middle attacks. You know that free, signed certificates are available these days pretty trivially with minimal configuration, right? In fact, on many managed hosting setups, the configuration is just a button click.

I mean we could assume that some security people have some nebulous and hard to explain nefarious secret scheme (which boils down to "be more secure" in the end anyway) or we could assume that they try to think about known security issues and fix them.

A lot of people have been unhappy with the paid Certificate Authority nonsense from the beginning, and have suggested various technically superior decentralized approaches (e.g. integrating with secure DNS, and so on). Obviously, that didn't happen, and while it may be hoaky and annoying, the current system does work.

I don't really know what to say about the rest of your political commentary. It's true that police state elements of various governments have been whining about difficulties in the dragnet ubiquitous surveillance they desire. So what? What does that have to do with someone doing a security audit on a TLS implementation?


All that https-everywhere and TLS Certificate pinning is all about (imo) protecting Ad revenue.

If Joanie ISP can come along and replace all their customers' traffic's Ads with their own Ads, it destroys the revenue stream.

Browsers are heading in the same direction as consumer game/video/audio endpoints: to deliver unmodified approved licensed content.

All that https-everywhere and TLS Certificate pinning is all about (imo) protecting Ad revenue.

Possibly less known fact:

Big corporations also want to do dragnet ubiquitous surveillance, as intrusive as any police state, on their employees. Because TLS makes this difficult for them, industry has a standard and widely used solution with product suites tailored just for their needs.

The standard approach is to create a private certificate authority, and install it on all corporate computers as a trusted root. Browsers have to support this or be banned. Note that the certificate-based security TLS uses is based on the browser itself being trusted, which in this case it obviously isn't.

The company then deploys large-scale deep packet inspection network gear, which man-in-the-middle attacks every TLS connection it sees and replaces the real key with one it makes on the spot, signed with the company's private root. The browser will then accept the connection as secure, even if it knows through other methods (pinning) that it's not. To do otherwise would be to anger the IT gods.

The same method is eminently available to any ISP, and all the requisite forgery attack and ad-replacement equipment exists and can be easily deployed in whatever easy-to-use form desired. All that the ISP needs to do is get you to install their software on your computer, by claiming you need it to get online and have the best experience.


You're missing the point, because you're dismissing the importance of how it's being sold - ie. in such a way as to imply that "to be resistant to man-in-the-middle attacks" and "to be secure" are the same thing - apparently on the grounds that those behind the initiative are all disinterested, altruistic actors concerned only with the users' welfare and couldn't possibly have even a shred of their own interest to look after, which is not even remotely accurate as a description of the prime mover in it, Google.

An earlier move by Google to promote their own interests is what it grew out of - that move being to make searches default to HTTPS, to degrade the usefulness of your webserver logs as a means of keeping tabs on how your website was doing, so instead of log file analysis you have to use the inaccurate - for so it is - information provided by Google Analytics (or else the hopelessly incomplete and utterly useless results of the "link:" search modifier), and are therefore steered into managing your site in a way that follows Google's interests first and your own second. Google's own page on the matter was all about blowing their own trumpet as high-minded altruistic guardians of privacy (HAHAHAHAHAHAHA), but nary a mention that all browsers have had a "turn off Referer:" user option for donkeys'. Plus a bit of plugging of Google Analytics.

While MITM attacks on people's credentials may be possible, in practice they seem to be unpopular; attackers' first choice seems to be human weaknesses (weak guessable passwords, bamboozling the human curators of password recovery facilities, etc), and where the hole exploited is in a computing system it is nearly always the massive gaping one that browsers, never mind the moaning about the connection it's delivered over, once it has been delivered unconditionally trust all content. The same one that Google themselves depend on. And then use the information they've obtained through it to decide that this account obviously belongs to the same person that that account does so let's be really helpful to them and sync all the personal information between the two accounts.

The MITM "attack" that HTTPS does frequently "defend" against is wiresharking your own web traffic and thereby observing all the crap your browser is sending out that you don't want it to (whether that was the intent of the exercise, or just something you can't help noticing while trying to reverse-engineer some API because the interface the website itself has given you doesn't fucking work).

PHK is quite right that overusing encryption to the point that agencies of the government get annoyed with it will end up resulting in government back doors or something equally nasty; we've narrowly escaped that once already, with all the fuss that happened when they merely realised that ordinary people now had access to strong encryption, US export controls on software that used it and all that. I very strongly suspect that the reason the current rumbles by government against encryption haven't really resulted in anything yet is that, now, people using SSL doesn't really hinder the agencies much.


When using a USB 3G adaptor to get internet access when the ADSL went down, I found T-Mobile doing exactly that. They were using it to (a) block people who don't have a credit (not debit) card from accessing sites that aren't approved by Mary Whitehouse, and (b) avoid spending money on upgrading their infrastructure by compressing the living shit out of JPEGs so they look like people having their faces hidden on TV. (I had to set up a VPN to my server and just put up with them throttling it to about 1 packet every 10s.)


While I appreciate that Google is hardly a blameless, altruistic actor, your description of the situation really strikes me as... shall we just say, deeply flawed.

It's just a quirk of history that "Referer:" headers exist at all, and arguably they're just a bad idea (though not as bad as "User-Agent:"). I appreciate that there's some nuance involved between Google's interests and those of web site owners, but come on -- Google's possible duplicity doesn't affect whether or not a more secure socket is a good thing.

As a user of the internet, I absolutely want all my connections to be secure, and further, man-in-the-middle resistance is part of that. You'll have noted, I hope, that SSH (which at a high level is the same basic idea as TLS, but without the public certificates) also implements a poor form of man-in-the-middle resistance via a host id cache.

As for snooping your own browser traffic, you're free to use the same mitm attack vector corporations use on your own sessions with your own proxy. This is actually how many virus scanners work these days, for that matter. Sure, it's another hoop to jump through with wireshark but hey, nobody ever said computers are easy.

As for your phone company, firewall penetrators are always popular for a reason.


"Google's possible duplicity doesn't affect whether or not a more secure socket is a good thing."

Of course, but you're still missing the point that the problem is not with the socket per se, but with the nature of the promotion and the consequential effects. See my first paragraph.

Of course a more secure socket is a "good thing", on a one-bit good/bad scale. But when you use more bits things are not so simple. The fundamental problem is that the web simply does not have any security model; it has a trust-everything model with a rag-tag collection of kludges bolted on the side to address a subset of those threats that have been observed. SSL is just one of the many kludges and of limited importance. But it is being promoted as if there is a web security model and SSL is it, misleading users into giving insufficient consideration both to other security measures and to other threats (including both those which have been addressed in some way or other and those which have not).

It is also being promoted in a manner which gives rise to new attacks. Most if not all web sites where SSL is genuinely important - banking and the like - have been HTTPS-only for a long time already, but the limited amount of SSL traffic from such "natural adoption" was not enough to worry most companies enough to make them go to the trouble of installing MITM boxes. But with widespread HTTPS there is an incentive for the existence of lots of large private networks with a hole punched in their security, giving an attacker rich pickings if they can compromise one of the machines on it.


The push for https is not about privacy -- it's about data integrity, to reduce the likelihood of MITM attacks, which has already resulted in malware being distributed. It's also a "fuck you" on google's part to certain ISPs who like to rewrite packets for their own purposes.

Of course, but you're still missing the point that the problem is not with the socket per se, but with the nature of the promotion and the consequential effects.

You're saying this as if Google has one unified strategy for promoting this change, that anyone with any technical know-how believes this is some sort of silver bullet, or indeed that people haven't been trying to get people to use TLS for years and run into roadblocks which Google is neatly breaking down for us.

This is just a small and necessary piece of the overall security problem, and nothing more. The Internet as a whole can't have a security model, because it's just a network of computers chatting over arbitrary application protocols. In other words, it's a social/legal/organizational problem, not a technical one.

And with that in mind, there are security models in the social/legal sense that exist. For one example, anyone who wants to hook their web site up to the finance industry these days has to meet PCI Compliance requirements. These aren't a particular software or networking model, but rather a set of requirements about how data is handled, encrypted, how the organization secures its computers, and so on.

If you don't like the fact that human beings are considered less important than credit cards by society, well... TLS is the least of your concerns.

By the way, companies were deploying man-in-the-middle attacks long before Google started making noises about TLS.


I've toyed with the "if you can't beat them, join them" model of using one of the several blogging platforms built recently around node.js. But it's a broad field, I'm pretty time poor and the way through it that appeals the most means a relatively large initial effort. Which is why I'm still not running a blog at this time.


BTW and FWIW, I can get onto the site via https just fine, but the CSS doesn't load and all the the internal links I've tried are http only. In my increasingly distant experience both those things could be apache configuration, but I'm sure you're perfectly aware.


Problems with migrating to a different blogging platform:

1. Steep learning curve for new technology (it's not something I'm likely to be able to pick up and configure after 15 minutes reading)

2. Scale: when I backed up this blog, it turns out to have ~3000 blog entries and ~200,000 comments. An XML dump that Wordpress or Movable Type can reimport runs to ~270Mb. Migration without data loss is therefore a risky propositio.

3. Brain rot: I haven't done sysadmin/programming work for a living for nearly 18 years now. I'm so rusty it's not funny. Wouldn't you rather I spent my time writing books?


It's Movable Type generating hard-coded http:// links to CSS and .js files. This is a Problem.

It can be fixed by having Apache rewrite URLs on the fly, but that's going to impose some additional load on the server. I'll consider it, but not right before I run off to a convention in a small town in Italy on Tuesday!



(1) is murder, unless you have a friendly expert who can guide you to an initial understanding of how the new system works. In most cases, you have to reverse engineer that from the documentation and trial-and-error :-(

(3) isn't just brain rot, because the (usually undocumented) horrible hacks you need and assumptions that 'the ecosystem' makes also change over time.


Rather than trying to mangle mod_rewrite have you tried...

Redirect permanent / any VirtualHost *:80 stanzas? I'm using that along with...

Header always set Strict-Transport-Security “max-age=15768000" httpd.conf on servers at work to force https.


Surprising to see how many in the above thread report using Chrome with win7, here I thought I was being a stingy, foot-dragging curmudgeon about sticking with my 2008 model. Possibly ten years ago was when everything people could imagine themselves doing with a desktop was satisfied by what the market provided. In other words, they'd become largely uniform commodity items like salt or milk and the only advantage available to one brand or another was how low the price could drop. Sea salt and antibiotic-free milk are available at a premium in stores, and I suppose Pacific blue desktop computers are too, but as a whole there's not much point trying to sell hugely improved PCs because users are good with what they got and can't get added utility from much more. Now that we're ten years further down the line, maybe the same thing is happening now to mobile computing. I'm not suggesting anyone short Apple stock, however. Market values are not subject to the same compulsions as individuals, they can do nothing at all indefinitely and still not have to get off the pot. And to the extent that an item can be marketed as a fashion accessory, there's no accounting for taste, how else would closets and thrift shops fill up with perfectly good apparel. Got to make room for the new stuff or the whole product life-cycle idea breaks down.


Something (probably gmail) seems to be eating any email I send to you.

Have fun at the con on Tuesday.

(This is just a test post with Firefox (mumble) on Snow Leopard because it's an old MacBook and I still like Eudora.)


I assume you are in the US?
Antibiotic-free milk?
Like all of ours?
As for "Sea Salt", well
1 - Maldon isn't very far from here ... ( 51.5 km in a straight line )
2 - If you are pickling or preserving items, then "ordinary" salt won't do, because it has anti-clogging agents in tiny quantites, which alter the colour of the final stored product - everything goes brown, ugh.
3 - Pure salt is more expensive than salt which has had said ant-cloggin agents added ...


Yup, heartland of the prairie. Discounters here used to stack skids of canning jars in their patio sections through the garden season, and always featured little displays of pickling salt nearby. At long last I understand why they bothered with it. Milk has been 98 cents a gallon at Aldi's now for almost a year. The antibiotic-free brand goes for like four bucks, at that steep a premium I'm willing to wait for the dairy industry and the market to sort out their differences. Makes me wonder about the whole organic food biz as a sustainable strategy, people are enthusiastic as early adopters to spend a buck for 16 ounce bottles of water, but eventually go back to drinking out of the tap at home when the novelty wears off. And Starbucks at five bucks a cup gradually gives way to lower priced alternatives, like instant out of the microwave. Whole Foods struck me as kind of an exercise in futility with what they were asking. Bezos may be brilliant as the founder of Amazon, but as a merger and acquisitions guy, he might have got too caught up in his own food preferences and what he sees coastal enclave elites spending money on. Buying Whole Foods may be more a sign he's running out of ideas for where to park his cash, than a real mass market action plan.


It was only at the end of last year that Windows 10 passed Windows 7 as the most commonly used Windows OS. Huge numbers of corporate machines (mine included) still on Win 7, since it works, and there hasn't been a compelling reason to go through the massive effort to upgrade to Win 10.

I'd bet that Chrome on Windows 7 is (by a decent margin) the most common browser/OS combination for non-mobile devices in use today.


"Surprising to see how many in the above thread report using Chrome with win7, here I thought I was being a stingy, foot-dragging curmudgeon about sticking with my 2008 model."

Doesn't surprise me at all. Windows 10 was such an unmitigated disaster when I tried to "upgrade" that I swore (or cursed) that I'll never have a computer with Windows 10. The one (of three) computer I was able to get it "working" was clogged up with so damn much bloated APPCRAP it was, for all practical purposes, unusable.

Every time I tried to use a program, Windows 10 would substitute one of its "APPS" and I'd have to fight the OS to get to the program I wanted to use. And goddamn Cortana NEVER Shut The Fuck Up!

I had to uninstall it to do a clean reinstall of Windows 7 and all of my software.

I don't use Chrome because Google is already too intrusive in everything I do on the internet. Plus I couldn't get the interface to look right; where "look right" means "Do it MY WAY!" (see Windoze10 above).

But I understand Chrome is a very popular alternative to Mozilla browsers.


I think your time is definitely better spent writing novels. I'm not trying to make suggestions, just reliving misadventures.

I keep finding myself wanting to write things that are too long as arsebook posts or as comments on other people's blogs. I've recently subsumed this by starting full time pg studies without taking time off work. Which is another way of saying I'm probably not going to be sorting out my own blogging platform for a while.


Hey! Leave apache alone - it's nice.

Well, apart from mod_rewriet which makes the baby Jesus cry. One tiny submodule that is so damned complex it has it's own book.


I'm still running a vintage 2009 PC with Win 7 and will NOT "upgrade" it to Win 10, ever! I also have an Alienware X51 that I made the mistake of "upgrading"; it's been seriously borked since. I'm actually considering shipping it back to Alienware for a SLEP, since it also ate the video card, if and only if they'll do a clean Win 10 install. Otherwise, it's a $1300 doorstop.

I bought an Asus laptop with native Win 10 and have had no major problems, apart from your reported issue of wanting to use "apps" instead of proper programs. I think the Win 7 to Win 10 upgrade path was totally fucked by Microsoft.


I miss XP, but unlike others, I find Win10 certainly acceptable ..
I have permanently silenced "cortana" by never activating it in the first place ....


"I miss XP, but unlike others, I find Win10 certainly acceptable ..
I have permanently silenced "cortana" by never activating it in the first place ...."

Didn't see an option for that during the "upgrade", or I certainly would have chosen it. But, I don't think that would have made Windoze10 any less of a disaster.

Leave a comment

Here's the moderation policy. If this is your first time, please read it before you post.

If you need to sign in and want to create a local account on this blog, select "Movable Type" from the "Sign in ..." menu. You will need a working email address.



About this Entry

This page contains a single entry by Charlie Stross published on April 4, 2018 12:15 PM.

Test Case was the previous entry in this blog.

On hold 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