I never realised this before, but Transport for London have been spamming me for at least three years. Despite never having subscribed, I receive a weekly email detailing weekend closures to various TfL services. I've happily ignored this abuse of my email address because unlike most spam, or more specifically in this case, Unsolicited Bulk Email, it came from a legitimate company, I knew how they got my email address (card application) and the messages contained genuinely useful information. Furthermore, I only want to unsubscribe as part of the process of moving to a new email address. Having said that, I'm not the only one who's noticed this abuse.

It turns out that getting off the mailing list is harder than it looks. The message contains no unsubscribe links. Neither does the TfL website. However, on the subscribe form, they do offer to stop duplicate emails if you give them your Oyster Card number and your address. Well, that doesn't make me too paranoid about a giant government database.

Examining the email's headers, they appear to be sent from the domain c-f-1.com. Go to this domain and you'll get a PDF in which the company Communicator Corp explain how they're not spammers and how every email sent though their system contains "an easy and automated way for you to unsubscribe" (they don't) and how they "promise to keep your email address secure and private" (also untrue). I'd have found a link to an unsubscribe form far more convincing.

However, using Google, I was able to locate unsubscription forms for other email sent from c-f-1.com. From this, I constructed a URL of the form:

http://www.c-f-1.com/Unsubscribe.aspx?emailid={emailid}

where {emailid} was the value of the 'X-UEmailID' header of the TfL message. Imagine my geekish glee when I was presented with an unsubscribe page containing my old email address. I still received an email the following week, but now it seems they've finally stopped sending messages to that address.

What's rather disturbing is that those unsubscribe pages were even on Google in the first place. Looking at the email IDs, they appear to be nothing more than Base64 encoded integers. Whilst they don't seem to start from 0, they don't appear to be random either. Also, even after unsubscribing, these pages seem to remain. Yes, it seems Communicator Corp is leaking their their entire list of email addresses onto the World Wide Web. If that isn't a breach of privacy, not to mention the Data Protection Act, I don't know what is. All that's needed now is for an enterprising spammer to write a script to collect them all.

Update 26/04/2009: For the first couple of months after writing this, I noticed a number of hits to this page from what appeared to be Communicator Corp's Internet gateway. I can't be certain that it's connected, but I notice that the mailing list unsubscribe form now no longer leaks email address information and requires that the email address be entered as confirmation which is a definite improvement. If Communicator Corp are reading this, I'd also like to take this opportunity to ask them to ensure that all messages sent do actually have a link to the corresponding unsubscribe form.

Update 02/10/2009: I notice that the weekly TfL emails now have both subscribe and unsubscribe links although I'm unsure when they appeared.

This really is quite nice. Researchers used collisions in the MD5 hash algorithm to create a rogue CA (Certification Authority) certificate signed by RapidSSL. RapidSSL is apparently trusted by the majority of web browsers.

It was demonstrated years ago that MD5 collisions could be generated relatively easily, but that hasn't stopped MD5 being used in a number of contexts where cryptographically secure hash functions are required. The attack involves getting a CA that uses MD5 for hashing to provide a legitimate website certificate. The attacker then generates their own CA certificate which has the same hash as the legitimate one. It is now possible for the attacker to generate SSL certificates for arbitrary websites, signed by their rogue CA certificate. As the rogue CA certificate has the same hash as a legitimate one signed by the CA, browsers that trust the CA will accept the fraudulent site's identity.

What I really like about this work is that the authors have managed to bridge the gap between a result primarily of interest to security researchers and an issue which could affect the average web user. Quite often, when cryptographic research results get publicity, the implications are so obscure to anyone without a knowledge of cryptography that the reporting soon becomes badly distorted. Hopefully, this example of how MD5's unsuitability as a cryptographic hash can lead to such an easily comprehensible real-world vulnerability might make people take notice of the danger in using broken hashing and encryption algorithms. Well, one can hope.

As Bruce Schneier points out, the plethora of valid sites with broken certificates have trained users to ignore SSL warnings so the ability to spoof SSL certificates doesn't really add that much. Having said that, Firefox 3 goes out of its way to make it difficult to access web-sites with invalid SSL certificates. Still, given the multitude of far simpler methods criminals have for acquiring sensitive information, it's unlikely this attack will ever be seen in the wild.