How Microsoft once again demonstrates not caring about security

On June 27 Microsoft announced they would stop sending security bulletins by email. The announcement stated:

As of July 1, 2014, due to changing governmental policies concerning
the issuance of automated electronic messaging, Microsoft is
suspending the use of email notifications that announce the
following:

* Security bulletin advance notifications
* Security bulletin summaries
* New security advisories and bulletins
* Major and minor revisions to security advisories and bulletins

In lieu of email notifications, you can subscribe to one or more of
the RSS feeds described on the Security TechCenter website.

This change is speculated to be related to a Canadian anti-spam regulation, although the normal course of action would normally be receiving explicit approval for sending these announcements. Some questions have also been asked about the timing of the announcement, as the regulation was known well in advance. Whatever the reason for suspending these services, on July 3rd, Microsoft reversed its course with the following message:

On June 27, 2014, we notified customers that we were suspending
Microsoft security notifications by email due to changing
Governmental policies concerning the issuance of automated
electronic messaging. We have reviewed our processes and are
resuming security notifications by email commencing with the
release of this monthly Advanced Notification Service (ANS) mailing.

Now, a prudent reader might ask why receiving emails constitute a security relevant matter, after all they offer to keep sending announcements through an RSS feed. That brings us to the more interesting matter. Microsoft, rightly so, use OpenPGP digital signatures for the notification emails to make it possible to verify the authenticity of the sender and verify that the message has not been altered in transit. The OpenPGP signed email communication channel is the only available option provided by Microsoft with these capabilities and in order to grab focus on this property, they include the following in their own bulletins:

The Microsoft Security Response Center (MSRC) uses PGP to digitally
sign all security notifications. However, PGP is not required for
reading security notifications, reading security bulletins, or
installing security updates. You can obtain the MSRC public PGP key
at
<https://technet.microsoft.com/security/dn753714>.

So far so good; Microsoft is using OpenPGP and they are announcing their public key. Other people should do this as well.

Sadly it goes downhill from here: Despite Microsoft announcing a HTTPS website for the acquiring the public key used for these announcements, upon attempting to contact this URL, a HTTP 302 redirect is used with the following Location: http://technet.microsoft.com/security/dn753714 , i.e .without any protection from TLS at all. This opens up possibilities of various man-in-the-middle attacks, hence removing the possibility validating the provided public key.

Of course, this shouldn't normally be an issue, as OpenPGP keys rely on object security which is self-contained together with the key material itself - which is why keys are normally distributed through various keyserver networks. Before using any OpenPGP key the key will have to be validated by the participant, either directly with the owner of the key or through the Web of Trust (WoT).

If we are to trust that we have not been MiTMed just now, Microsoft is linking to public key information presented as a 4096 bit RSA key for Certificate and Signing use with a 4096 bit subkey for Encryption.

And here is the kicker; The key was created on 2014-06-03, i.e. it is a relatively new key, and it does not contain any certifications from any Microsoft employee or signature from earlier keys used for Microsoft Security Advisories as you would normally expect.

To add insult to injury, despite the emails containing references to the aforementioned website and key, the following Microsoft announcements on July 10 and 11 were actually signed by the key 0xF0B7406D which is not referenced as a key used for current Microsoft announcements. This key actually does contain a small number of signatures from external users, but as with 0xA92965F2 none from any Microsoft employee. As to whether the key is authentic your guess is still as good as mine.

So why is it so important that the key used for security announcements is signed by individual Microsoft employees, and in particular the members of the security team?

These employees are the only individuals that can reasonably make an assurance about the use of a team key. Additionally, as proper key validation procedures require ID-checks and a personal assertion about the key ownership, for others to get a trust path to the key in question, these members of the team will need to have their own keys verified by other participants in- and outside of the IT industry.

Users that wants Microsoft to try to get its act together when it comes to communication security (to allow a broader scope is probably utopia) should send messages to them through channels such as Twitter (@msftsecresponse). My own posts have not been answered so far.

OpenPGP key statistics

Recently there has been some talk about the number of OpenPGP keys available on the various keyservers. My own contribution to this discussion is tracking the development at sks-keyservers.net . As can be seen on both the line chart of total number of keys, and the breakdown to a bar chart for daily addition, new keys are added at a higher rate today than it was just a few years ago, and without any statistical considerations, the change of rate seems to coincidentally correspond to the Snowden leaks.

 

LineChart BarChart

This post will look into some of the underlying data and hopefully provide a bit more information depth. The data was exported from one of my own keyservers yesterday and consists of 3,526,080 primary keys, of which 118 keys were invalid to the point that I've discarded them from the rest of the analysis (unable to properly parse the OpenPGP packets to extract the information). To emphasize; I have not looked into subkeys in any way for the purposes of this post and I have made no attempt to determine whether these keys are expired, revoked or otherwise inactive.

The overall majority (94.74%) were Version 4 keys c.f. RFC4880 with V3 keys representing 4.73% and V2 keys representing 0.53%. DSA keys represented 74.4%, while 25.6% were RSA keys and a minority ElGamal (0.03%), Elliptic Curve keys (35 keys) and keys in the experimental range (32 keys) .

The key lengths spans from 3 keys in the experimental range key with algo id 103 of 224 bits to 32,768 bits (3 keys, two of which are RSA and one DSA). Due to the low occurrence of ECC keys (that have an expectation of lower key lenghts for similar expected security levels -  normally in the 256-521 bit range, although there is a strong possibility that the aforementioned 224 bits keys should also fit in this category) I have not done any adjustment for these. A full 77.4% of the keys are included when looking at the aggregate figures up to and including 1024 bits, roughly 2.7 million of the keys, and the corresponding number when looking at a 2048 and 4096 bits respectively are 95.3% and 99.95% of all keys included.

key_length

Load-balancing SKS

The synchronizing key server (SKS) is the most used implementation of OpenPGP key servers. Despite its many strengths, however, its web frontend scales badly and should generally be placed behind a reverse proxy such as nginx, apache or varnish. For inclusion in the High-Availability (HA) pool of sks-keyservers.net this is a requirement, and it is also part of the weighting criteria for the various geographical sub pools. With the increase in number of keys I've been thinking of ways to ensure that the pool stays even more responsive, and currently considering (i) to make it a hard-requirement for inclusion in the pool to have a reverse proxy set up (ii) to reuse the HA pool for a set of servers that are even more available, by proving that they are load-balanced across multiple instances of SKS.

 

My own keyserver, for historical reasons named keys2.kfwebs.net (keys.kfwebs.net was located in another server facility and is currently not operational),  is running such a load balanced setup using Nginx's upstream module.But before getting back to that, some basic information about my SKS setup.

Two or three SKS servers (depending on whether I need to use one of them for experimenting with other projects such as the Key Signing Party list auto-generating lists based on publications to a keyserver) are running on different Virtual Machines, one server peering with the global network and the other servers peering internally. To ease the load on SKS, static pages are served by nginx directly using:

location / {
root /var/sks/web;
index   index.xhtml;
}

 

The actual data being served by SKS is in the /pks subdirectory and is being handled by the directive

location /pks {
proxy_pass http://sks_servers/pks;
proxy_pass_header  Server;
add_header Via "1.1 keys2.kfwebs.net";
proxy_ignore_client_abort on;
}

And this is where the load-balancing is starting to happen. "sks_servers" is not a hostname that is being referenced but an upstream directive in Nginx that states;

upstream sks_servers
{
server  localhost:11372;
server  192.168.0.27:11371;
}

When adding and removing servers I simply edit this directive and reload nginx, and here I also have the possibility of assigning weights to each of the servers (defaults to 1).
In the status list of the pool such load-balanced servers can be identified by a blue flag for RProx (Reverse Proxy). Hopefully enough operators will set up load-balanced systems for an even more responsive High-Availability pool to exist.