Starting With Mozilla Thunderbird 10 and newer (and up to at least Thunderbird 17), SSL/TLS protocol failures are no longer user discoverable.

In Mozilla Thunderbird 9 and earlier, if the SSL/TLS protocol handshake with a server resulted in a fatal failure, an error prompt was shown that notified the user about the failure. With Thunderbird 10 and newer, no feedback will be shown, and the user cannot know whether the failure is on the client side or on the failure side, and what exactly causes the problem. With Thunderbird 17, you can at least find the error message hidden in the "error console" that can be opened from the menu (hidden between all the other frequent messages that are dumped to that place).

One example scenario where you'd run into this silent failing is a typical enterprise configuration, where the server requires the client to authenticate with a client certificate. If the client certificate is not accepted by the server, or no such cert hat been installed yet, then Thunderbird will fail silently. (There are additional SSL/TLS protocol failure scenarios where you'll get the same silent failing.)

The reason for this regression is that error reporting was removed, instead of working on a smarter solution for Bug 682329 . All proposals that would have kept the error reporting in Thunderbird working and that could have been implemented by me with a reasonable amount of work were rejected.

In case you'd like to test the regression yourself, you can follow the steps below.

Use Thunderbird to configure an additional email account. When asked by Thunderbird 17 choose existing account.

- Username: test
- email: test@ssltls.de
- password: test (it's wrong, but it doesn't matter)
- check "remember password"
- click continue
- click "manual config"

- Select IMAP
- hostname ssltls.de (NO leading dot as proposed, in other words, NOT .ssltls.de)
- port 993
- SSL/TLS
- auth: normal password

SMTP configuration doesn't matter, you won't be able to send email through this configuration, but in order to allow you to complete the configuration:
- SMTP
- hostname: ssltls.de
- port 465
- SSL/TLS
- auth: normal password

click ok

With thunderbird 17, the test fails, click "advanced config", and in the next dialog click ok.

You'll now see the standard Thunderbird window, and you should have the test account configured. Click on the inbox. Your statusbar (lower part of the window) might show "connected to ssltls" but that's all you'll ever get with Thunderbird 10 and newer, even if you click the "get mail" toolbar button. You might eventually, much later, see a "connection timed out" notification popup, but that's incorrect, and it's not helpful in diagnosing the cause of the problem.

If you do the above with Thunderbird 9 and earlier, you'll get
"An error occurred during a connection to ssltls.de, SSL peer was unable to negotiate an acceptable set of security parameters. ssl_error_handshake_failure_alert"

With Thunderbird 17, this message can be found in the error console.

We must solve the problem that any CA is a single point of failure for the Web's trust, as used by the SSL/TLS protocol.

In October 2011 I had published a rough description of a system that I named MECAI, Mutually Endorsing CA Infrastructure.

It took some time to think in more detail about the various aspects, and I'm thankful for the discussions I had with other security experts, who pointed out missing details, problems that still need to be solved, etc.

Now I'm able to announce that I've published (yesterday) a more detailed writeup (version 2), you can find it here:https://kuix.de/mecai/mecai-proposal-v2.pdf

I'm looking forward to your feedback. It might be best to post your feedback to the IETF's mailing list therightkey.

Using NSS command line tools can be tricky.

I recently wrote this little HOWTO that describes how you can use the NSS command line utilities to create a CSR (Certificate Signing Request), later import the certificate you receive, and make a backup of key and certificate to a PKCS#12 (p12) file.

http://kuix.de/mozilla/nss/howto/create ... st-etc.txt

Also recently, I was asked for help. An Add-On author had created a key pair using NSS tools, for the purpose of the Add-On updating mechanisms (which involves the McCoy tool). Later it became necessary to extract the private key in order to use it with other applications.

Unfortunately, dealing with raw key pairs can be tricky in NSS, the tools are more powerful when dealing with keys that are bound to certificates.

So, we had an NSS database containing a private key, an external copy of the public key as base64, but no direct way of exporting the private key. The solution we used was tricky, so I'm documenting it here.

Using a separate empty NSS database, we used certutil to create a new CSR, of the same key type and size, and stored the binary encoding of the CSR in file some-other.csr

We also created the binary encoding of the public key that we had externally available (found in an update.rdf file).

Then we used the dumpasn1 tool to create a binary dump of some-other.csr - this told us at which byte position inside the public key starts.

Then we used a binary file editor (dd) to create a remixed CSR...
- start with the initial part of some-other.csr until the public key begins
- append the public key from the production key
- append the remainder of some-other.csr, the part after the public key

At this point we had a CSR for the production key, but an invalid one. It's invalid, because the digital signature inside the CSR (a proof of possesion of the private key) didn't match the contained public key.

Next we created a hacked version of NSS' certutil, we disabled the call to CERT_VerifySignedDataWithPublicKeyInfo - which disabled the check for the signature.

This way, we were able to use a local CA certificate (one that I use for testing purposes) to create a certificate for this certificate request. This certificate could be imported (and a nickname assigned to it) into the original production database that had only keys, but no cert.

Now it was possible to use NSS utility pk12util to export the certificate, including its keys, to a PKCS#12 files. As this is a standard container, you can use tools provided by other crypto toolkits to extract the keys and use it elsewhere.

I'm documenting the procedure in the hope it can be helpful for other's who run into the same dilemma.

But the more important message of this story, please avoid this kind of hassle. You shouldn't deal with raw keys, but rather use certificates.

At the Fosdem.org 2012 conference in Brussels I had the opportunity to talk about Web Security, the various proposals we've seen regarding trust of key ownership (including my own MECAI proposal), and my opinion what we should be done next.
The text can be found at: https://kuix.de/fosdem2012/

I need a Linux desktop that is stable, reliable, feature complete, obvious to use, suitable for both programmers (such as myself) and users (such as the variety of people around me that I have converted to use Linux).

Unfortunately, as of today, there is no such desktop.

Once upon a time, we had a great Linux desktop environment, its name was Gnome 2. To my shock, Gnome 2, the central piece of software that gave the Linux desktop a chance for growth and success, has been declared as obsolete.

Because Gnome 2 is no longer supported, it effectively means it's no longer available for use on modern computer hardware that require a current Linux kernel and therefore require to use a very recent Linux distribution.

Gnome 2 had a rich set of features and standard add-ons, that made the Linux desktop really work, for example:
- adjustable starter shortcuts, visible for easy discovery
- a list of running programs and open windows
- an obvious, discoverable mechanism to safely shut off the computer, not requiring to be aware of and having to remember a keyboard shortcut
- notification icons for important events
- a mechanism to always display user configurable important information, such as weatcher, stock quotes or other news
- an obviously reachable place for current files of interest (the Desktop)
- quickly reachable monitor settingsm, helpful when connecting to a video projector
- preview of file contents for easy discovery
- it was very stable and reliable

What have we got instead? Let's have a look at the alternatives that are available today.

Gnome 3 is removing features and hiding functionality.
You no longer have a list of open windows, important for people that understand what's going on and want to have full control, and who want to check which applications might have unsaved data.
There are no easily customizable starters, only the ability to run applications with their default parameters.
It's difficult to create a list of easily visible shortcuts, which can help users to be reminded what applications they are supposed to use.
Instead, all users are expected to be smart and remember the name of programs and type those names in. How is that easier?
If a user moves the mouse to a certain position (upper left), the whole display changes, giving users the impression that something is suddenly broken.

XFCE has a nice and simple concept. In many areas it uses the expected, traditional approach to use the desktop.
Unfortunately it appears to be unrealiable. The most important part of the desktop environment, the window manager xfwm4, crashes frequently.
Whenever that happens, an ordinary user is completely helpless. No, they don't know how to open a terminal and restart it.
Sometimes the desktop gets stuck and it's impossible to logout or shutdown.
The desktop doesn't have a preview of file contents and labels are shortened radically.
The drag-and-drop interaction when interacting with files is unexpected and causes confusion, e.g. when dragging files to a folder within the filesystem, files get copied, not moved.
The sound level control is very complicated to use and not as elegant as in Gnome.

I have not looked at LXDE in much detail.
It appears to be very incomplete in terms of features, and does't seem like an alternative for demanding users.

My experience with KDE is mixed. I was a KDE user many years ago and I liked it. When incomplete KDE 4 came out, I had to switch to Gnome.
Now I've tried recent version 4.7. In the beginning I was very enthusiastic. I had the hope that I found what I was looking for, because a lot of things behave as I'd expect it.
But I quickly encountered frequent crashes.
Sorry guys. It's simply not acceptable to use unstable software for the central piece of computer interaction.

A group of people has started the Mate project, an understandable attempt to revive and maintain Gnome 2.
But it appears it's difficult to make Gnome 2 and Gnome 3 work right in parallel, and offer the full set of capabilities that Gnome 2 used to had, which effectively means to adjust and provide a large set of software around Gnome 2.
I honestly wish them good luck, but I'm not sure it's the right path, as attention focuses on the Gnome 3 libraries.

Then I heard about Mint Gnome Shell Extensions (MGSE), which is an attempt to "fix" Gnome 3 by adding workarounds to it.
That's what I'm using currently, but it was a mess to get installed correctly on Fedora.
I had to experiment with the shell extensions made available by Gnome on their own, with MGSE, and with some independent extensions published by third parties.
It was a mess to find a mix of extensions that is compatible with each other and provide a desktop experience as I expect it.
This is certainly not something an ordinary user can do.
I see this as a temporary workaround, feasible for me as a programmer, while I'm waiting for something better.

The most recent initiative I heard about is called Cinnamon.
This approach makes a lot of sense to me.

It uses the modern base libraries made available by the Gnome 3 project, so there is hope that it can be as reliable and as feature complete as Gnome 2 used to be.
It brings back the classic desktop interaction, list of open windows, area for system notifications, and panel starters.

There are a couple of things that don't work right yet.
The notification icons of some applications, such as the deja-dup backup tool, are not yet visible, apparently there is incompatibility between applications and the desktop environment. That's not surprising based on today's chaos of Desktop alternatives. I hope that can be fixed.
Cinnamon should fix the upper left mouse area and remove the desktop shuffle confusion.
Cinnamon should offer a mechanism to adjust the starter shortcuts shown on the desktop or the panel (something like the right mouse click, edit properties, command line) that we used to have in Gnome 2.
The integration of system control widgets needs to be completed and fixed.

Besides that, to me, Gnome 3 base plus Cinnamon appears to be the most reasonable initiative to fix the Linux desktop at this point of time.
While some convenience usability features are missing, at least the desktop is based on modern libraries and behaves according to my expectations

If you can, please support the Cinnamon project. I'm desperately waiting for it to be ready and available as the new default Linux desktop environment.