Why you shouldn't give away your password

So, you want to embed details of you Twitter, or Facebook, or <insert flavour of the month here> account on you blog. There's a widget that will do this (in fact the widget is the only way to do this) and 'all' you need to give it is you user name and password. You are using a blog provided by a big well known provider so of course you can trust them not to misuse your credentials. What can possibly go wrong?

This:
http://techcrunch.com/2011/04/13/hacker-gains-access-to-wordpress-com-servers/

User-ids in a Shibboleth world

[This is a copy of a question posted to the JISC-SHIBBOLETH@JISCMAIL.AC.UK mailing list which, to date, hasn't seen much in the way of responses to the questions at the end]

A lot of existing web apps have wired into in the, often at a very low level, the idea that each 'user' has associated with them a unique, short-ish, fairly friendly identifier. Traditionally these were things like jw35 or 2006STUD42, though it's increasingly common to use an email address belonging to the user instead. Quite often these are (in fact or in practise) the primary key into the application's user database and they tend to get displayed (as in "Hello jw35", or in things like usage logs) and these two usages are often not distinguished.

When converting existing software for a SAML environment there's the question of what to use to fill this slot. If you have ePPN available then that will probably work (because it looks like an email address) but in the UK federation that's unlikely. The 'old' form of ePTID (rUL8A3M667VfsiCImQVFffN9cNk=@cam.ac.uk) might just about work, though it's ugly when displayed. The new form is close to unusable for display purposes:

https://shib-test.raven.cam.ac.uk/shibboleth!https://mnementh.csi.cam.ac.uk/shibboleth/ucam!rUL8A3M667VfsiCImQVFffN9cNk=.

Of course if you are creating accounts in advance and only later binding them to SAML identities you can use whatever user-id scheme you want, but what if you are creating accounts 'on the fly'?

We've noticed that 'off the shelf' Shibboleth adaptations (most recently for Plone and MediaWiki) tend to simply use what turns up in REMOTE_USER which, by default, will be the first of ePPN and the old and new forms of ePTID that isn't blank. In a UK federation context this doesn't really work, and I suspect many of these adaptations were written for contexts where ePPN is more widely available.

What have other people working in the UK environment done to address this problem, assuming you are seeing it too? Is there a 'best practise'?

Consent to be required for cookies? (updated 2011-03-15 and 2011-05-11 and 2011-05-17)

An amendment to the EU Privacy and Electronic Communications Directive comes into effect on 25 May 2011. This makes it necessary to obtain consent before storing and retrieving usage information on users’ computers. Details are unclear, mainly because the UK government has apparently yet to publicise any information on how this requirement will be implemented in the UK, but in the limit it could require every web site to obtain informed user consent before setting any cookies, which is going to be interesting...

Here are some external references to the topic:

• Out-Law.com
• Information Commissioner
• JISCLegal
• LocalGovermentLawyer
• Google Analytics Support Forum

Updated 2011-03-15: More links

• BBC News
• Sitepoint
• David Naylor (with helpful demonstration of best practice :-)
• Andrew Cormack's blog
• Out-LAw.com (again)

Updated 2011-05-11:

• Guidance from the Information Commissioner's Office (2011-05-09)
• DCMS Press Release (2011-04-15)

Updated 2011-05-17:

• Andrew Cormack's blog (again) (2011-05-12)

Other people's content shown to be dangerous

In Promiscuous JavaScript considered dangerous I said that including content from elsewhere on your pages was dangerous, not only because the people supplying the content might be malicious but also because they might fail to prevent third parties from injecting malicious content.

Judging by this BBC News article this is exactly what happened recently to the web sites of the London Stock Exchange, Autotrader, the Vue cinema chain and a number of other organisations as a result of displaying adverts provided by the advertising firm Unanimis. This will have caused problems for these various organisations' clients, and reputational damage and hassle for the organisations themselves.

Ideally you'd carefully filter other people's content before including it in your pages. But you may not be able to do this if, for example, the supplier requires you to let everything through untouched or if you are using the promiscuous JavaScript approach. In such cases you are entirely dependent on the competence of the supplier and, as demonstrated here, some are more competent than others.

Google Apps: SSO and IdM at #GUUG11

Here are some slides from a presentation I gave on Google Apps SSO and Identity Management at the inaugural 'Google Apps for Education UK User Group' meeting at Loughborough University on 15th February 2011:

Google Apps - SSO and Identity Management at the University of Cambridge

View more presentations from Jon Warbrick.

Loops in PKI certificate hierarchies and Firefox bugs

In a previous posting, I mentioned being surprised to discover that PKI certificate hierarchies were more complicated than the strict trees that I had always assumed them to be. At the time I rather assumed that they must be directed acyclic graphs.

I've subsequently realised that there is nothing to prevent them from being cyclic graphs and have actually found a loop in an existing commercial hierarchy. Unfortunately it looks as if I wasn't the only person making false assumptions since it seems that certificate loops trigger an old-but-not-yet fixed bug in Firefox that prevents certificate chain verification.

Certificates contain within them the 'Distinguished Name' (DN) of a further certificate that contains the public half of the key used to sign the first certificate. Certificate are only identified by name, and there is nothing to stop multiple certificates sharing the same name (though all the certificates with the same name had better contain the same key or new and exciting bad things will probably happen). All this is what I worked out last time.

What I've discovered that's new is illustrated in the following diagram:

This represents part of the hierarchy under which certificates are issued to UK HE institutions by JANET (and I think by similar organisations in other countries) under a contract with Comodo. In this diagram:

1. The blocks with grey backgrounds represent key pairs. The numbers at the top of the box are the first half of the key's 'Key Identifier'.
2. The smaller blocks represent certificates containing the corresponding public keys.
3. The arrows link certificates to the keys that signed them (and so which can validate them).
4. Certificates with red backgrounds represent self-signed certificates that are trusted roots (at least on my copy of Firefox). The certificate with blue background represent an example server certificate.
5. The number in each certificate is the first half of the certificate's SHA-1 hash.
6. Certificates with a  green border represent the recommended verification chain for JANET-issued certificates.

Copies of the certificates involved (and others) can be found here.

The problem here are the two certificates "31:93:..." and "9E:99:...", since each represents a potential verification route for the other. Neither are part of the 'official' verification chain for JANET-issued certificates. "9E:99:..." is distributed by Comodo in support of other of their certificate products. I don't know where "31:93:..." comes from, but I assume it appears in someone else's 'official' certificate chain. Both these 'intermediate' certificates will presumably be included in certificate bundles by particular web servers and, once serverd, tend to be cached by web browsers.

The problem is that, once a web browser has a copy of both of these there's a danger of it going into a spin since each is an apparently acceptable
parent for the other.  It turns out that Firefox has exactly this problem, as described in bug 479508. Unfortunately this bug last saw any action in March 2008 so it's not clear when, if ever, it's going to be fixed. There are some other reports of what I suspect is the same problem here and here.

So who's problem is it? Clearly Firefox could and should be more careful in how it constructs certificate chains. It's possible that other SSL software is vulnerable to similar problems, though I've only seen this manifest in Firefox (and only then occasionally). But I also wonder what the Certification Authorities thought they were doing when they issued these certificates. As far as I can see they were both issued as 'cross-certification' certificates, intended to allow server certificates issued under one root certificate to be validated by reference to another. Issuing one of these isn't a problem. Issuing a pair clearly is.

A work around, should this problem bite you, should be to delete "31:93:..." and "9E:99:..." from Firefox's certificate store. Neither are roots, and any server that needs them to get its certificate verified should be providing them, so deleting them should be entirely safe. The work-around should last until you next pick up copies of both of these, at which point you'll need to delete them again.

Root certificates for MacOS OpenSSL

In an earlier post I mentioned that, while MacOS includes OpenSSL it isn't preconfigured with any trusted root certificates. So before you can use it to do SSL properly you need to provide a set. 

My previous post suggested extracting them from the bundle that comes with Firefox, but I've recently come across a useful article about Alpine on MacOS by Paul Heinlein <heinlein@madboa.com> in which he points out that the MacOS operating system already has a set of preconfigured roots and that these can be extracted using the Keychain Access utility for use by OpenSSL. See his posting for details, but to quote from it:

1. Open the Keychain Access application and choose the System Roots keychain. Select the Certificates category and you should see 100 or more certificates listed in the main panel of the window.
2. Click your mouse on any of those certificate entries and then select them all with Edit → Select All (Cmd+A).
3. Once the certificates are all highlighted, export them to a file: File → Export Items…. Use “cert” as the filename and make sure “Privacy Enhanced Mail (.pem) has been chosen as the file format.
4. Copy the newly created cert.pem into the /System/Library/OpenSSL directory

Now, I wonder why Apple didn't do this for us?