Posted on

GMail can’t send to sendmail

Gmail Fail

What’s happening with Google? Their Internet engineering used to be spot on. They’re generally a bunch of clever guys, and they follow standards and their stuff just works. Or did. Lately their halo has been getting a bit tarnished, and problems with GMail are a good case in point.

It all started quietly around a month ago on the 6th August. About a week later, people started complaining that users sending mail to them from GMail were getting bounce messages. It looks like Google had rolled out a broken software update, but they’re keeping a low profile on the subject.

After a great deal of investigation it appeared that their new MTA was attempting to make a STARTTLS connection when delivering mail on port 25. STARTTLS is a mechanism that allows encryption on a standard unencrypted channel. Basically, the sender tries a STARTTLS command and if the receiver supports it, returns a reply of “okay” and the remainder of the connection is encrypted using TLS. unfortunately Google’s implementation, which had been working for years, is now broken. The GMail lusers got a bounce back a week later that said it couldn’t negotiate a STARTTLS connection. No further explanation has been forthcoming. STARTTLS should work, and if it doesn’t GMail should try again without using it, but doesn’t.

On the servers I’ve examined there is no problem with STARTTLS. Other MTAs are continuing to use it. All certificate diagnostics pass. Presumably Google has changed the specification as to what kind of TLS/SSL its going to work with, as, presumably, it’s not happy working with all types. Not all servers have this problem. But Google isn’t telling anyone what they’ve done, at least not so far. Working out what’s wrong with their new specification using trial and error takes a while, and I have yet to find a combination that works. And besides, it’s not Google’s place to tell recipients what kind of encryption they should be using, especially when the default state is unencrypted.

Google does offer a troubleshooter but it doesn’t cover this eventuality. There is an option to report other problems, but to date I’ve had no response.

So what’s the solution? The only method I’ve found that works is to disable STARTTLS on Port 25. This means that Google can’t try and fail, and go in to sulk mode. And here’s the bit you’ve probably been waiting for: how to do it.

Assuming you have an access DB configured for sendmail, (the norm) you need to add an extra line somewhere and makemap it:


srv_features: S

On FreeBSD this file is /etc/mail/access and you can make it active using make run from the /etc/mail directory. But you probably knew that.

The srv_features stuff basically tells sendmail which services to advertise as being available. STARTTLS is option ‘S’, with a lower-case letter meaning “advertise it”, and an upper-case meaning “don’t advertise it”. This over-rides defaults, and all we want to do here is stop advertising STARTTLS. If it’s not advertised, Google doesn’t try using it (at least for now).

You might want to read this sendmail documentation for more information in the normal Sendmail easy-to-understand(!) format. If that doesn’t do it for you, look at section 5.1.4.15 of the manual, available in PDF here.

Now Google may defend this state of affairs by saying that they’re implementing something odd with STARTTLS for “security reasons”. There may even be some justification in this. If I knew what they’d changed I might be able to comment on that, but I can’t. However, even if this was the case, they’d be wrong in principle. Since the dawn of Internet email we’ve had RFCs telling us how things should work. You can’t just change the way you do things and expect everyone else to change to suit you, however large you are. And it’s possible that what Google has done is RFC compliant, even if it is bonkers. There are unspecified aspects in RFCs, and some grey areas. However, anyone who’s been around for long enough will know that Sendmail is the de-facto MTA. If you have an argument about the interpretation of an RFC, you can settle it by asking the question “Does it work with sendmail?” If it doesn’t, it’s your problem.

And while we’re at it, it’s really good of Google to stop anyone reading your email while it’s in transit (could they be thinking of the NSA here?) After all, you don’t want email sent through GMail to be readable by anyone until they’re delivered, do you? The only snag is that they are still being read and analysed, by Google. Of course. Email is never secure unless you have end-to-end encryption, and by definition, you can’t get this with a webmail service.

Posted on

Problems receiving mail from GMail – STARTTLS is a bad idea

Gmail Fail

Note: You may wish to read this follow-up article, which contains a solution.

A couple of weeks ago, users started complaining that people using GMAIL (and possibly iCloud) were having their emails bounced back to them from my servers. This is odd – most complaints on the Internet are from users of dodgy hosting companies having their mail rejected by GMail as likely spam. But I haven’t blacklisted Google, and all other mail is working, so they must have been mistaken.

But as soon as I could, I tried it for myself. And sure enough, a bounce came back. The relevent bit is:

Technical details of temporary failure:
TLS Negotiation failed: generic::failed_precondition:
               starttls error (0): protocol error

On fishing around in Sendmail logs, I found evidence that this has been going on all over the place:

sm-mta[84848]: STARTTLS=server, error: accept failed=-1, SSL_error=1, 
               errno=0, retry=-1, relay=mail-qg0-f50.google.com [209.85.192.50]
sm-mta[84848]: STARTTLS=server: 84848:error:1408A0C1:SSL
               routines:SSL3_GET_CLIENT_HELLO:no shared cipher:/usr/src/secure
               /lib/libssl/../../../crypto/openssl/ssl/s3_srvr.c:1073:
sm-mta[84848]: t7QJXCPI084848: mail-qg0-f50.google.com [209.85.192.50] did
               not issue MAIL/EXPN/VRFY/ETRN during connection to MTA

Oh my! The STARTTLS stuff isn’t working because there’s no shared cypher! Hang on a minute, there isn’t supposed to be. Who told Google they could use STARTTLS on port 25. It’d be neat if it worked, but it’s not configured – at least not with a certificate from a public CA. It actually works just fine if you are cool with self-signed (private) certificates. So what is Google playing at?

In the wake of Edward Snowden, people have started worrying about this kind of thing, so companies like Google are trying to be seen doing something about it, and encrypting mail might seem like a good idea. Unfortunately STARTTLS is a bad idea. The rationale behind STARTTLS was to add encryption to a previously unencrypted port’s traffic. If the sender issued a STARTTLS as part of the protocol it could switch in to TLS mode if it knew how; otherwise it would just work as normal. The IETF was very keen on this in the late 1990’s as an easy fix, citing all sorts of iffy reasons, generally to do with having two ports; one standard and one encrypted. They thought it would be confusing, requiring different URLs and not allow for opportunistic automatic encryption of the kind Google seems to be attempting.

As far as I’m concerned, this is rubbish. Having clearly defined encrypted and unencrypted ports means you know where you are. It either is or it isn’t. If you say something must be encrypted, turn off the unencrypted port. STARTTLS allows a fall-back to plain text if you specify the clear text port; and if you have a man-in-the-middle you’ll never know that the STARTTLS was stripped from the negotiations. It opens up a vulnerability that need not be there, all for the sake of saving a port. And time is on my side in this argument. Since 1999 the implementation of encrypted ports has really taken off, with https, smtps (in spite of 465 being rescinded), imaps – you name it – all servers and clients support it and you know where you are.

So what’s this sudden clamouring for the insecure STARTTLS? Naivety on the part of the large internet companies, or a plot to make people think their email traffic is now safe from snoopers when its not?

I’ve reported this problem and I await an answer from Google, but my best guess is that they’re speculatively using STARTTLS, and then barfing and throwing their toys from the pram when it doesn’t work because the verify can’t be done. Having thought about it, I’m okay with the idea of trying STARTTLS as long as you don’t mind about the CA used for the certificate; and if you can’t negotiate a TLS link, go back to plain text. In many ways it’d be better to use the well known port 465 for TLS, and if it can’t be opened, go to plain text on 25. Except there’s no guarantee that port 465 is on the same server as port 25, and it’s normally configured to require SASL authentication. As everyone knows, apart from Google it seems, assumption is the mother of all foul-ups.

Encryption is a good idea, but making assumptions about Port 25 being anything other that straight SMTP is asking for trouble.

 

Posted on

Spam from WH Smith?

Whoever next? We’ve intercepted a load of spam sent by French company EmailVision on behalf of WH Smith to honeypot addresses – i.e. definitely not opt-in and definitely not legal in the UK. EmailVision is getting quite a reputation for this kind of thing, with PayDay loan spam and suchlike. W H Smith – I’m surprised at you! Or perhaps I’m not.

Posted on

Stagefright on Android

This is a quick post as I’m a but busy at the moment, but it’s worth saying something about it this serious Android security flaw.

As I understand it, there is a buffer over run problem with the decoder for MMS messages. On receipt and decoding of a specially crafted MMS an attacker can get control of the process,
which on Android 4 or later means access to SD card data, your camera and microphone and other awkward stuff. On Android 2 they get the whole phone. I’ve yet to be convinced that this is a game over type problem on Android 4 but it bad enough. On earlier versions of Android, it’s a complete disaster.
The solution, of course, is to get a software update from your phone manufacturer. Good luck waiting for that to arrive.

My advice in the meantime is to disable MMS messages completely. I do this by default, because I think they are ridiculously overpriced and there are plenty of other alternatives such as email or even Instagram (so I’m told buy the teenagers hereabouts).

If you want to disable MMS, proceed as follows:

Go to phone settings. The last entry under Wireless and Networks will be More…

Here you will find “Mobile networks”, and under there will be ” Access point names”. On dual SIM phones you will now have to choose each SIM in turn, otherwise you’ll go straight to a list of profiles. This list may contain only one entry.
Choose the entry that is selected, i.e the one you are using. What you will find next depends on the version of Android you have. However somewhere down the list there will be an MMS service centre URL, beginning with HTTP and looking like a web address. Simply delete the contents of this field, and while you are at it, remove the entry for MMS proxy if you have one. This tends to be a dotted quad i.e. an IP address.

Just save this, and you will not be able to send or receive MMS messages from your phone.

Posted on

Problems with Thunderbird 38.0.1 and SSL

Dead Thunderbird
Version 38.0.1 of Thunderbird is an ex-mail client. It has ceased to be.

Thunderbird used to be my mail client of choice, but suddenly I’m not so sure! The latest update on the release channel (version 38.0.1) seems to have broken completely when using self-signed certificates for SSL.

A self-signed certificate makes sense when you know you can trust it; otherwise you get a signing authority you do trust to verify your certificate (for loadsamoney). If you’re talking to your own servers, there’s not point in doing this as there are other ways to check you’re talking to who you think you are. Thunderbird used to warn you that it didn’t recognise a self-signed certificate the first time it saw it, but if you told it to go ahead anyway it would add it to the trusted list and go on encrypting your data for you quite happily.

Since “upgrading” to version 38 it suddenly stopped working. No more email. No more sending email. It just failed silently (that’s bad, for a start), the only clue was that I couldn’t send an email or copy it to the drafts folder.

On examining the logs at the server end I found stuff like this:

Jul  7 23:17:54  dovecot: imap-login: Disconnected (no auth attempts):
    rip=###.###.###.###, lip=###.###.###.###, TLS handshaking: SSL_accept() 
    failed: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher

Suspicious! So I turned off SSL in Thunderbird and it all worked again. This is NOT a sensible solution. Unfortunately, I have yet to solve this one, other to simply not upgrade Thunderbird beyond 31.7.

Fortunately, you can still download the previous non-beta version from here, (assuming Mozilla don’t move it). You actually want 31.7.0, because the intervening releases were betas, and 31.7.0 is as recent as May 2015 so it’s not ancient. Just navigate around the site you don’t want the English version. Simply install it everything comes back the way it used to be, or at least it did for me.

 

Update 15-Jul-2015:

It appears that Thunderbird may have decided not to accept TLS with less that 1024-bit DH keys without telling anyone. Even if they had mentioned it, there’s not a lot users can do with it. This means that if you’re using a 512-bit key (which is considered export-grade) then it’s going to refuse to talk. Worse than that, it doesn’t pop up a message saying WHY it’s not going to talk. It’s just going to fail the connection. Presumably, as my friend Graham put it, this indicates that the Thunderbird open-source developers are hoping to get a job with Apple.

I hope this nonsense will be resolved in 38.1! In the mean time, turn off auto-update.

Update 30-Jul-2015:

I’ve now updated the server certificates being in-date (which doesn’t actually matter), and made sure they were 1024-bit (which they were) and apart from upsetting everyone who has had to accept the new certificate, Thunderbird still barfs.

Update 15-Aug-2015:

It get’s worse – there has been an update to the 31.x branch to 31.8.0, and this has the same problem. Use the link above and make sure you’re using 31.7.0

 

Posted on

Malware claiming to come from Transport for London

I often get Transport for London information messages. I suspect a few million people in London do. But until just now, I’ve not seen it used as a malware distribution trick. Here’s what they look like:

Received: from [80.122.72.234] ([80.122.72.234])
	by  (8.14.4/8.14.4) with ESMTP id t5QAj0ns002218
	for ; Fri, 26 Jun 2015 11:45:01 +0100 (BST)
	(envelope-from noresponse@cclondon.com)
Date: Fri, 26 Jun 2015 12:45:04 +0200
From: 
Subject: Email from Transport for London
To: 
Message-ID: 
MIME-Version: 1.0
Importance: Normal
X-Priority: 3 (Normal)
X-Mailer: SAP Web Application Server 7.00
Content-Type: multipart/mixed;
 boundary="=_5557BCCC15D34570E10080000A82A3EC"
Envelope-To: 


--=_5557BCCC15D34570E10080000A82A3EC
Content-Disposition: inline
Content-Type: text/plain;
 charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Description: Email from Transport for London


Dear Customer,

Please open the attached file to view correspondence from Transport for
London.

If the attachment is in DOC format you may need Adobe Acrobat Reader to
read or download this attachment.

Thank you for contacting Transport for London.



Business Operations
Customer Service Representative

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com

This email and any attachment are intended solely for the addressee, are s=
trictly confidential and may be legally privileged. If you are not the int=
ended recipient any reading, dissemination, copying or any other use or re=
liance is prohibited. If you have received this email in error please noti=
fy the sender immediately by email and then permanently delete the email.
______________________________________________________________________
--=_5557BCCC15D34570E10080000A82A3EC
Content-Disposition: attachment;
 filename="AP0210932630.doc"
Content-Type: application/doc;
 name="AP0210932630.doc"
Content-Transfer-Encoding: base64
Content-Description: AP0210932630.doc

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAJwAAAAAA

The file attachment is a dodgy Microsoft Word document, unknown to malware scanners, and in spite of the faulty English it’s unlikely that Bayesian analysis will think it odd, although the SPF records don’t match and the IP address is currently flagged as slightly dodgy with no reverse lookup. It belongs to Telekom Austria, and I suspect it’s NOT a botnet at this time.

If anyone else has received one, I’d be interested to know! I let TFL know, and, refreshingly, got through to the right people and they took the matter seriously. This is hardly ever the case, so my feelings for TFL have gone up several notches!

Posted on

Spam From Amazon SES

Spam has always been a problem with Amazon’s email service (SES). They make an effort to filter the outgoing missives transmitted by their customers, but it’s not perfect. And Amazon is no respecter of laws outside the good ‘ol US of A, where the right to free speech is a license to spam any kind of junk you like; whether the recipient asked for it or not.

Here’s a case in point:

Received: from a8-55.smtp-out.amazonses.com (a8-55.smtp-out.amazonses.com [54.240.8.55])
	by xxx.xxx.xxx.uk (8.14.4/8.14.4) with ESMTP id t5NHpefn075543
	for <spambait@xxx.xxx.uk>; Tue, 23 Jun 2015 18:51:40 +0100 (BST)
	(envelope-from 0000014e218bf8a9-07659756-debc-452c-9a9f-1b0ecedf709d-000000@amazonses.com)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
	s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1435081898;
	h=From:Date:To:MIME-Version:Message-ID:Reply-to:Subject:Content-Type:Feedback-ID;
	bh=jCdtb+gUf4FAvUudtcIKxlX0IOnQHEd/YxIGxHXLcQ4=;
	b=cNIs7cNe5LzyxYvGWw/LdIeA7epknAFAoeQYjiyf9b5mTKRYLAW9KLvUTSGtlsr7
	WWy52wd3Tz9o9vQryvK/Q5l5okAFxgZCZa5uSbXMor7sa/1dU02kwjCyACnb7viR1np
	BlEytfbGEBUlAfBBrrJueagmdzwa+IXNZsBo4w2Y=
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
	s=lfgclj2zbjygv5i5rirpal2v2zj3dquy; d=uebaps.com; t=1435081898;
	h=From:Date:To:MIME-Version:Message-ID:Reply-to:Subject:Content-Type;
	bh=jCdtb+gUf4FAvUudtcIKxlX0IOnQHEd/YxIGxHXLcQ4=;
	b=bZZSEICBkHU8HkdFtiYg9fp+qxzmxJlfNj6UclS3B4dtaKBMTf1oSCSQR5jm0XXE
	0JxmIdNWKsgumLUcf8XnZGZFVfwe2f7cVOCiA1EcHX7oHn0weHQjoce+nxwVClgCQYz
	m0OlXn/YvNBE1MwSvpQR3PfoSCyTVQQpBWjgD8dQ=
From: Ray-Ban Sale <enews@uebaps.com>
Date: Tue, 23 Jun 2015 17:51:38 +0000
To: "spambait@xxx.xx.uk" <spambait@xxx.xx.uk>
X-MessageID: OXx8fHwxMzY3MXx8fHxmcmFuazJAZmpsLmNvLnVrfHx8fDEwfHx8fDF8fHx8MA%3D%3D MIME-Version: 1.0
Message-ID: <0000014e218bf8a9-07659756-debc-452c-9a9f-1b0ecedf709d-000000@email.amazonses.com>
X-Priority: 3
Reply-to: Ray-Ban Sale <enews@uebaps.com>
Subject: Spambait: Keep Calm and Get 80% Off Ray-Ban!
Content-Type: multipart/alternative; boundary="b1_b18fea4f74280e521923210f4d5c61eb"
X-SES-Outgoing: 2015.06.23-54.240.8.55
Feedback-ID: 1.us-east-1.E00ipiLUCdDBKP1kTeYjtCc2E2c3DbfGjCtoi1emL2E=:AmazonSES 
--b1_b18fea4f74280e521923210f4d5c61eb
Content-Type: text/plain; charset = "utf-8"
Content-Transfer-Encoding: base64
SGksRnJhbmsgTGVvbmhhcmR0OiAjUl9Ub3BfVGl0bGUjLg0KQm9ybiBmcm9tIGEgbWVzaCBiZXR3
ZWVuIHR3byBvZiBSYXktQmFuJ3MgbW9zdCBpY29uaWMgYW5kIHBvcHVsYXIgc3VuZ2xhc3NlcyAt
IHRoZSBDbHVibWFzdGVyIGFuZCBXYXlmYXJlciAtIFJheS1CYW5DbHVibWFzdGVyIE92ZXJzaXpl

As you can see (if you’re used to reading email headers), this looks very legitimate – send from a correctly configured server. However. these characters are as guilty has hell. The email body, once decoded, claims that the spambait email address belonged to a past customer of theirs, and was used for placing an order (in the USA). This is, of course, physically impossible.

If this had been sent in Europe they’d have been breaking the local law that implemented  the EU Privacy and Electronic Communications Directive, 2002.  But they’re sending it from the USA. Other text in the email suggests it’s not from an English-speaking country (not even the USA), and it’s probably a scam. But Amazon doesn’t t seem to mind – they don’t even have an abuse reporting system for ISPs plagued by this stuff.

It’s tempting to simply block all Amazon SES IP addresses, but this will cause collateral damage. Spam filtering isn’t likely to detect it any other way, as the sending server is set up correctly, with SPF records and so on, so the Bayesian filter in a spam classifier will be over-ruled. However, this correctness can be used against it…

Let’s be clear here – it’s easy enough to block the whole of SES. You can get its address range just by looking at it’s SPF records:

%nslookup
> set type=TXT
> amazonses.com
Server: 127.0.0.1
Address: 127.0.0.1#53
amazonses.com text = "v=spf1 ip4:199.255.192.0/22 ip4:199.127.232.0/22 ip4:54.240.0.0/18 -all"

I suspect this may cover more than SES, but SES is certainly covered by it. However, blocking it will, as I mentioned earlier, block some innocent stuff that you do want. This is a job for Spamassassin.

I’m experimenting by adding the following to SA’s local.cf file:

header AMAZON_SES Received =~ /amazonses.com/
score AMAZON_SES 3.5
describe AMAZON_SES Sent from Amazon SES - often used by spammers

The the appropriate score to weight it by is an interesting question. By default good SPF records are ignored anyway; if they were not then it would obviously be a good idea to negate a positive score here. So I’ve picked 3.5 as this matches a clear Bayesian score rather than for any good statistical reason. Check back later to see how well it works.

Posted on

Infosec 2015 – first thoughts.

This is my customary personal blog post on the Infosec Europe show. Specific articles may, or may not appear here later.

This year the show has moved to Olympia from the defunct Earls Court, which is is probably the best choice available. It’s made me nostalgic for the old Personal Computer World shows of the 1980’s. Except there’s not a lot of interesting technology here. The theme of the show seems to be governance and the IT Security industry – governance and compliance rather than solutions to real problems. It’s been the way things have been moving over the last few years, with the modern IT professional being hard pressed to know which end of a soldering iron to hold it by.

There were a few interesting new(-ish) ideas, and the bleedin’ obvious stuff being packed with a GUI and monetised.

Libra Esva is a good case in point. They’ve taken Linux, spamassassin, Clam-AV (and optional commercial AV products),together with extra filtering and firewall functionality of the kind an old-style UNIX admin would customise their rigs with, and created a virtual appliance with a good looking and easy-to-use front end for users to deploy on VMware and so on. Sure, it takes the fun out of it but it looked good.

ActiveDefence were on hand, offering to launch a DDoS attack on your infrastructure to see how good it was. What, how do you launch a realistic DdoS attack without a botnet? “We have our own, they said.” And they were serious. The service may not be unique, but it’s very rare (unless you hire a bunch of crims, of course – I’ll have to see how prices compare).

KnowBe4’s PR has been bombarding me with their name for a few weeks now; I had to see why. They’re a company after my own heart – they’re launching cyber-security awareness training and consultancy in the UK, at a level appropriate to users and at a price point where SMEs really have no excuse for not doing something about what I (and KnowB4, obviously) regard as one of the greatest threats. Call it spear phishing or human engineering attacks – the weak link is employees being duped. And the criminals are very sophisticated, so awareness is about the old defence.

I’m off to see some more people who seem to have re-invented the obvious, and put it on the market. They’re using honey-pots to capture IP addresses to dynamically configure firewalls, it appears. Quite what their angle is remains to be seen, but it’s presumably a better honey-pot than we’ve all be writing for years now.

Posted on

Kids can review Kindle books in their parents’ names

Occasionally I write the odd review on Amazon products directly on Amazon. This is normally information I wish I had when I was looking for an item or book. Then, today, I was clicking about and came upon a list of things I’d written about:

AmazonReviews

Now I don’t remember reviewing E. Nesbit’s classic, and I prefer her Barnstable series anyway (although I doubt it’d be PC enough to make in to a film, so its merits are less widely appreciated).

So what’s going on here? And I certainly don’t remember reading “The Ugly Duckling”, illustrated or otherwise.

And then I realised – this was my daughter using a Kindle attached to my account. It appears that it’s possible to rate books from it directly, and this she has obviously done. In my name.

Her pronouncements as to their literary merit  may be valid, especially for someone her age, but this needs to be made clear.

I’ve sent some pointed feedback to Amazon on this point, and will wait to see what happens.

 

Posted on

Microsoft’s Windows 10 Security Update Plan

The headlines on luser news media are all about Windows 10 being the last ever release of Windows. Apparently Microsoft’s plan is to issue incremental updates thereafter. As those in the know, know, this has always been the way. Microsoft only releases a new version when it wants to flog it to the punters as the next great thing, and it does this by giving the latest snapshot of the code a new name (e.g. Windows 7, Windows Vista). Okay, there have been major step-ups; for example Window 2000 was the marketing name for Windows NT 5.0 (ditching some of the disastrous code in Windows NT 4.x), then came 5.1 – sold to the public as XP. Windows Vista was the next re-write; technically it was Windows 6.0. Confusingly to the punters, 6.1 was flogged as 7 and Windows 8.0 and 8.1 were 6.2 and 6.3 respectively. The reality is that OEM versions of Windows appear frequently, to track the new hardware as it turns up in production machines. It’s only the retail customers that believe in these retail versions. So what is Microsoft really doing?

Well, one effect of having a retail version of Windows is that every three years the punters stop buying new PCs, waiting for the next “version”. As Microsoft actually makes a lot more of its revenue from selling OEM licenses (bundled with PCs) than the retail versions, keeping the hardware manufacturers happy by killing off the boom/bust cycle is probably A Good Thing.

Is Microsoft getting a bit humble, acknowledging that hardware makers have a choice and Windows isn’t the only game in town? I don’t believe they do; the punters want Windows on their desktop PCs, and that’s that. So what is in it for Microsoft?

The clue is in what Terry Myerson was saying at Ignite 2015 in Chicago last week. The new version of Windows will feature greatly enhanced on-line update capabilities, with peer-to-peer patch distribution and a lot more. Patch Tuesday is to be abolished, with updates rolled out on a continuous basis. And all in the name of security.

Let’s play devil’s advocate here, and pretend that Microsoft has other reasons. First off, Patch Tuesday, the monthly release of non-critical Windows updates in an ordered manner, will become obsolete. The policy was originally formulated to avoid patches coming out willy-nilly at odd times in the month and catching IT departments off-guard; and now they’re going back to the old chaotic system. A broken update can knock your IT systems out at any time of the day or night. If this sounds like a recipe for disaster, don’t despair – according to Terry Myerson, patches will be rolled out to the lucky home users first, which means that it can be pulled and business won’t be affected if an update screws up. Enterprise customers will still be given the choice as to which updates they install; it would have been a hard sell to knowledgable IT people otherwise.

Is this actually going to improve Windows security? Peer-to-peer patch distribution? 24/7 patches coming from Redmond as soon as they’re presumed ready? What could possibly go wrong?

Rather than looking at this as a security fix, I think the policy should be taken in to consideration alongside Microsoft’s move towards licensing, rather than selling, software. They want a continual revenue stream and they don’t like their software pirated. Who does? By moving to an OS model that requires the host to be Internet connected and constantly patching itself, it becomes much harder for cracked versions of the OS or applications to exist. (Microsoft’s own applications, that is). Peer-to-peer updates will make updates harder to block. If a crack turns up in the wild, the next day a patch to kill it can appear from Redmond. And if your stop paying the license fee, your copy of Windows stops working. This last aspect isn’t being talked about openly. I’m just guessing here. But considering Microsoft’s penchant for licensed/rented software of recent years, Windows 10 being released with a mechanism that appears ideal for licence enforcement should they ever decide to move to the rental business model, I think it’s a good guess.

Or it could simply be that Microsoft is panicking over the less-than-warm reception the world gave Windows 8/8.1 and had decided that releasing new retail versions frightens the horses.