|Please consider subscribing to LWN|
Subscriptions are the lifeblood of LWN.net. If you appreciate this content and would like to see more of it, your subscription will help to ensure that LWN continues to thrive. Please visit this page to join up and keep LWN on the net.
There are plenty of security buffs who lament that it may be too late for PGP encryption to ever become common practice for email among the general public, but many of them continue to believe that PGP signatures on email still have a fighting chance. After all, the signature adds its value without making the message unreadable to those recipients who lack the proper software support. Yet "proper software support" is a tricky level to achieve, as users of Mozilla Thunderbird have known for a while. A longstanding problem in the way Thunderbird interacts with the PGP add-on Enigmail triggers false signature-mismatch warnings in certain situations (not all of which are under the user's control), illustrating yet again how difficult implementing security in the email realm can be.
In a recent blog entry about encouraging GnuPG usage among Debian Developers, Jo Shields wrote about the problem, telling readers to avoid Enigmail entirely:
Such a claim might sound shocking, considering that Enigmail is one of the most popular Thunderbird add-ons and Thunderbird one of the most popular desktop email applications. Surely, if there was such a major bug, it would have gotten fixed quickly. But many others have pointed out the same problem over the course of several years—at least since 2007, and as recently as last year.
Essentially, the trouble happens when Enigmail attaches an inline PGP signature to an email in Thunderbird's HTML message composer. The HTML composer is a different component than the plain-text composer, and it performs some "clean up" on the message body after the user hits send. That is an obvious recipe for trouble, since it occurs after the signature was computed over the message. Any alterations, including those that are invisible to the user (such as white-space changes or replacing special characters with HTML character codes) will alter the hash value of the message, which is the element of the signature that is encrypted by the sender's private key.
In this case, the alteration that happens to the message body is automatic line-wrapping. Thunderbird's line-wrapping for HTML messages breaks lines that exceed 79 characters (or whatever the value of the mailnews.wraplength preference is set to), so not every message is affected. In an attempt to avert this trouble, Enigmail performs its own line-wrapping on the message body just before generating the signature, at mailnews.wraplength - 2.
Nevertheless, there are invariably some situations when a single "word" is longer than 77 characters; the simplest example is a lengthy URL. In these situations, the automatic line-wrapping Thunderbird performs after Enigmail has processed the message splits the long line at the mailnews.wraplength point when it is sent, therefore the signature no longer validates when the email recipient's PGP client checks it. Changing Thunderbird's line-wrapping behavior is not simple either; it requires changing several preferences. As Enigmail lead developer Patrick Brunschwig said in a 2009 comment thread (comment #10), "The problem behind it is that Mozilla is too clever -- it re-wraps the message after Enigmail has signed it, even though Enigmail already applied line wrapping with the same methods as HTML." Since Thunderbird provides a constrained API for extensions, there is nothing Enigmail can do. Thus, he continued, "the only solutions I have are: either use PGP/MIME or write plaintext messages."
Unfortunately, while support for inline PGP signatures is fairly widespread, support for PGP/MIME (which in essence makes the signature a message attachment) is less common—particularly with proprietary email clients. In addition, Thunderbird's default behavior is to compose replies in the same format as the original email; one can force it to reply to an HTML email with plain text by holding down the "Shift" key when punching the "Reply" button or by altering each account's composition settings, but both options seem like an unnecessary hassle. After all, as quite a few bug reporters have noted in the various bug reports about this topic, it is at the very least odd that Thunderbird auto-line-wraps HTML messages but does not do the same to plain-text messages. It would seem like HTML content could be sent as-is, leaving the receiver's email client to render the message in however many columns are available.
Plain-text emails are not problem-free either, however. Thunderbird's default is to send plain text in the format=flowed (RFC 2646) format, which can lose leading spaces; Enigmail tries to compensate for this by transforming leading spaces to "~". Moreover, Enigmail also dash-escapes plain text (as required by the OpenPGP specification), which regularly causes problems for people emailing software patches with signatures.
One way to look at the whole mess is that the root of the problem is the existence of two ways to include a PGP signature in a message (inline and through PGP/MIME), two code paths to compose email in Thunderbird (plain text and HTML), three programs that process the message between the user hitting "send" and the email leaving the machine (GnuPG, Enigmail, and Thunderbird), and multiple preferences that affect line-wrapping. There is certainly no shortage of opportunities for finger-pointing, but considering all of the variables involved, an equally defensible conclusion is that digital email signatures—despite their relatively small size on screen—ultimately cannot be simplified down to point-and-click ease.
Copyright © 2014, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds