Saturday, January 23, 2016

Advertures in S/MIME - Sending encrypted email with MS Outlook

In parts 1 and 2 of this series, I reviewed the difficult process of purchasing a personal certificate to use with S/MIME and the lengthy process required to get that certificate installed where Microsoft Outlook 2016 can use it for S/MIME signed email.  This post will show how to send your public key to friends, where you and they can then finally send email encrypted with S/MIME.

Distributing public keys

At this point, you and the other person have each completed the process of purchasing and installing a personal certificate for use by Microsoft Outlook.  By sending a SIGNED email to each other, your public key travels along with the email message and is used by Outlook to verify that a signed message was properly delivered.

I expected that receiving the public key (validated by public key crypto) would mean that it is possible to now send an encrypted email to the party that sent you the public key.  False - not there yet.  First have to get their public key installed into your Contacts entry for their email address.

I am told later that you can highlight their email in a received signed message and add them to your contacts.  They are already in your contacts, but this will merge the public key into your existing entry, completing the key acceptance.  I didn't do it that way.  Here's the long way.

Upon receiving a signed email message, click on the "signed" icon. Its red, on the right side.  Get this dialog.




Click on Details




Click on signer (two down from highlighted in the above).
And "View Details".



And view the certificate.

And EXPORT the certificate to a file.

And then go back to Contacts, look up the person,



Click on Certificates.
Click on Import, and import the other persons public key that was exported above.

Now you CAN send them an encrypted email via their public key and can sign that email using your private key.  Mission accomplished.  In a way success.  There's more.

Construct an email

Write an email to the person that you have now the ability to send encrypted mail.  You still must click the little tiny icon to bring up the security dialog to instruct Outlook to encrypt and sign the email.  Major usability mistake here.  Outlook by default will NOT encrypt the email to this person even though you have their public key.

If you write a secret letter - and you're going to send it - and you hit send, did it go encrypted?

If you have a public key for someone Outlook should go out of its way to default require sending all mail to that person encrypted.  Failing to do this puts you in a position of having to be very careful about whether or not the the security properties on the mailing are set.  If you get it wrong, outlook will happily send the email "in the clear".

You installed an S/MIME certificate for yourself because you want to be able to receive encrypted email.  You installed someone else's public key because you want to be able to communicate with them securely.  Outlook should REQUIRE that all email sent to that person be encrypted, or make you at a minimum jump through approvals to send non-encrypted.  It doesn't, and that's a shame.

Outlook should also "collect" public keys for all email received where you have a matching email address in your Contacts.  It doesn't, and that too is a shame.

Summary

We blame users for not being good at complicated things like certificates when in reality, we as programmers are not very good at making the user's life easy. They should not have to care about all these details.

Certificate authority actions

For a certificate purchase, why is a web browser used for installation of the cert???  I'm okay with using a web browser to conduct a purchase, but when I get done, what I want is a certificate file stored on disk containing my public and private key, encrypted with some password that I assign.  THEN, I will load that cert into programs where I want to use it.

To go beyond the call of duty, let me download a utility program that will do the entire operation.  To say you don't want OS specific utilities to develop is false.  The registration in my case used ActiveX control and that means Windows, so there is already per-OS code used on the website registration.  Instead, the website should prompt me to download and RUN a utility program that will do the functions of certificate purchase and installation.

When the certificate purchase is complete, the program should enumerate all the potential certificate stores on the machine and PROMPT me for which to install the cert.  IE/Windows cert store, Firefox, Outlook, they are all different and installation of the purchased certificate should automatically put the certs in the place where I want to use them.

Email program actions (Outlook)

Default to making it secure.  Automatically update my contacts when you receive a valid public key - or at a minimum, prompt me that you are going to do this and seek approval.  When sending email to someone that has a public key in my contacts entry, absolutely encrypted it - always!  And when I send to people that have a certificate themselves, do SIGN my emails and do ENCRYPT.  Default to doing it securely and should I ever try to send a non-encrypted email to someone that can accept encrypted, well don't do that - always send it encrypted.

S/MIME adoption

It is somewhat self fulfilling that S/MIME adoption is low.  Make this stuff work like it is supposed to work and things will be much easier.  Much easier to convince people to spend $20 to make it secure for a year if all they had to do was make a purchase over the internet.  Get this right, the money side can get in place and user count up, which should inspire email programs to do a better job defaulting to secure transport of email messages.

My $0.02 to secure the world.

Joe Nord

2 comments:

Karl Vegar Larsen said...

Utility to create certificates:
Something like Open SSL for instance?

And in Outlook.
Add the ability to update the certs as they expire.
As is, when you finaly get to the cert installed, all is good for a while. And then the cert on one end expire, lets call it cert A. Sourcing a replacement cert and installing it, is the same song and dance. But the other end doesn't automagically update the cert the next time you send a mail. You'll need to delete the contact, and re add it with the new cert.

Joe Nord said...

Excellent point Karl, thanks for the addition.