Using client certificates for smtps

Hi!

Is it possible to use client certificates for authentication to smtps
srver?
Mozilla Thunderbird is supporting smtps, but I see no way to install
client certificates and use them to authenticate...

Regards,

--=20
Mariusz Wo=B3oszyn
Internet Security Specialist, GTS - Internet Partners
0
Mariusz
8/24/2004 5:26:51 PM
netscape.mozilla.crypto 949 articles. 0 followers. Follow

33 Replies
571 Views

Similar Articles

[PageSpeed] 37

Mariusz Woloszyn wrote:

> Is it possible to use client certificates for authentication to smtps
> srver?
> Mozilla Thunderbird is supporting smtps, but I see no way to install
> client certificates and use them to authenticate...
> 
> Regards,
> 
The word I've received is that the Thunderbird developers decided that
all the UI for managing certs, keys, and the "master password" was just
"too confusing" for former IE users, so they decided to leave it out.

I guess that means if you want to use client certs, you have to use the
mozilla suite (e.g. moz 1.7) instead of TBird.
0
Nelson
8/25/2004 2:24:54 AM
Nelson Bolyard wrote:
> Mariusz Woloszyn wrote:
> 
>> Is it possible to use client certificates for authentication to smtps
>> srver?
>> Mozilla Thunderbird is supporting smtps, but I see no way to install
>> client certificates and use them to authenticate...
>>
>> Regards,
>>
> The word I've received is that the Thunderbird developers decided that
> all the UI for managing certs, keys, and the "master password" was just
> "too confusing" for former IE users, so they decided to leave it out.
> 
> I guess that means if you want to use client certs, you have to use the
> mozilla suite (e.g. moz 1.7) instead of TBird.

Sounds disingenuous. Outlook users, which is Microsoft's mail app - not 
IE - has quite a few crypto features. So, if anything, Outlook users 
will miss those features if they switch to Thunderbird

Granted, client auth for SMTP doesn't seem to be one of Outlook's 
features, but it does S/MIME signing and encrypting.

Also, if there is no UI for managing certs in Thunderbird, even basic 
SSL connections may fail if there is no way to install corporate root 
certs and trust them. That's going to be a much more common problem than 
not supporting client auth.
0
Julien
8/25/2004 3:22:15 AM
On Tue, 24 Aug 2004, Nelson Bolyard wrote:

> > Is it possible to use client certificates for authentication to smtps
> > srver?
> > Mozilla Thunderbird is supporting smtps, but I see no way to install
> > client certificates and use them to authenticate...
> >
> > Regards,
> >
> The word I've received is that the Thunderbird developers decided that
> all the UI for managing certs, keys, and the "master password" was just
> "too confusing" for former IE users, so they decided to leave it out.
>
:(

> I guess that means if you want to use client certs, you have to use the
> mozilla suite (e.g. moz 1.7) instead of TBird.
>
I don't see any way to use client certs in Mozilla _mailer_.
I want it to authenticate to the remote peer by presenting a certificate.
All I can see I can do is trust the remote site by trusting it's
certificate or the CA that signed it, but how can I present my client
certificate to the other side?

Regards,

--=20
Mariusz Wo=B3oszyn
Internet Security Specialist, GTS - Internet Partners
0
Mariusz
8/25/2004 7:35:11 AM
Mariusz Woloszyn wrote:
> I don't see any way to use client certs in Mozilla _mailer_.

They do work. You can configure your default client cert for SSL under 
edit/preferences/privacy & security/certificates . Set either "select 
automatically" or "ask every time". Admittedly, there is no specific 
setting of the client cert to use to login to each web site. In most 
cases there is no ambiguity and Mozilla & NSS can determine the right 
cert to use automatically. If not, set "ask every time" and mozilla will 
present you with a dialog to let you select the client cert you want.

Of course that can only work if you installed your client certs in 
mozilla previously (eg. from a PKCS#12 import).
0
Julien
8/25/2004 9:28:40 AM
Mariusz Woloszyn wrote:

> On Tue, 24 Aug 2004, Nelson Bolyard wrote:
> 
> 
>>>Is it possible to use client certificates for authentication to smtps
>>>srver?
>>>Mozilla Thunderbird is supporting smtps, but I see no way to install
>>>client certificates and use them to authenticate...
>>>
>>>Regards,
>>>
>>
>>The word I've received is that the Thunderbird developers decided that
>>all the UI for managing certs, keys, and the "master password" was just
>>"too confusing" for former IE users, so they decided to leave it out.
>>
> 
> :(
> 
> 
>>I guess that means if you want to use client certs, you have to use the
>>mozilla suite (e.g. moz 1.7) instead of TBird.
>>
> 
> I don't see any way to use client certs in Mozilla _mailer_.
> I want it to authenticate to the remote peer by presenting a certificate.
> All I can see I can do is trust the remote site by trusting it's
> certificate or the CA that signed it, but how can I present my client
> certificate to the other side?
> 
> Regards,
> 
As I understand, the service will require mutual authentication and ask for your 
certificate. It can also ask for your certificate with specific characteristics.
Then you can answer automatically or select the signing key you wish to use. This
would be just like a mod-SSL Apache service using SSL.
Ed

Ed
0
Edward
8/25/2004 10:05:24 AM
On Wed, 25 Aug 2004, Julien Pierre wrote:

> Mariusz Woloszyn wrote:
> > I don't see any way to use client certs in Mozilla _mailer_.
>
> They do work. You can configure your default client cert for SSL under
> edit/preferences/privacy & security/certificates . Set either "select
> automatically" or "ask every time". Admittedly, there is no specific
> setting of the client cert to use to login to each web site. In most

I'm not connecting to a _web_ server.

> cases there is no ambiguity and Mozilla & NSS can determine the right
> cert to use automatically. If not, set "ask every time" and mozilla will
> present you with a dialog to let you select the client cert you want.
>
> Of course that can only work if you installed your client certs in
> mozilla previously (eg. from a PKCS#12 import).
>

This works for Mozilla _browser_ and not for mozilla mailer. :(
If I try to connect to smtps service the mailer does not ask me for any
certificate (although "ask every time" is set).
If the remote peer is configured to not authenticate the client everything
works perfectly, but if the remot end requires certificate I got an Error
Code -12227.
On the server side I got:
Aug 25 16:40:51 XXX stunnel[7890]: SSL_accept: 140890C7:
error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not
return a certificate

The mailer is configured to _send_ mails through smpts on port 465.

Seems like the client certificate authentication feature is missing in
mozilla mailer (1.7.2).

Regards,

--=20
Mariusz Wo=B3oszyn
Internet Security Specialist, GTS - Internet Partners
0
Mariusz
8/25/2004 2:45:33 PM
On Wed, 25 Aug 2004, Edward Feustel wrote:

> > I don't see any way to use client certs in Mozilla _mailer_.
> > I want it to authenticate to the remote peer by presenting a certificat=
e.
> > All I can see I can do is trust the remote site by trusting it's
> > certificate or the CA that signed it, but how can I present my client
> > certificate to the other side?
> >
> As I understand, the service will require mutual authentication and ask
> for your certificate. It can also ask for your certificate with specific
> characteristics. Then you can answer automatically or select the signing
> key you wish to use. This would be just like a mod-SSL Apache service
> using SSL. Ed
>
Yes, exactly. I'm seeking for an opportunity to authenticate the clients
to my smtps server using certificates.

Rgrds,

--=20
Mariusz Wo=B3oszyn
Internet Security Specialist, GTS - Internet Partners
0
Mariusz
8/25/2004 2:47:02 PM
Mariusz,

Mariusz Woloszyn wrote:

> 
> 
> This works for Mozilla _browser_ and not for mozilla mailer. :(
> If I try to connect to smtps service the mailer does not ask me for any
> certificate (although "ask every time" is set).
> If the remote peer is configured to not authenticate the client everything
> works perfectly, but if the remot end requires certificate I got an Error
> Code -12227.
> On the server side I got:
> Aug 25 16:40:51 XXX stunnel[7890]: SSL_accept: 140890C7:
> error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not
> return a certificate
> 
> The mailer is configured to _send_ mails through smpts on port 465.
> 
> Seems like the client certificate authentication feature is missing in
> mozilla mailer (1.7.2).
> 
> Regards,
> 

I tried it with SMTPS I don't have an SMTPS server with client auth, but 
I do have an HTTPS server with client auth. All I did was configure it 
as SMTPS server, with SSL . When trying to send a message through it, I 
did get the cert selection pop-up (I have "ask every time"). Of course, 
I couldn't send the message after that, because the server behind isn't 
SMTP, but the initial part - the SSL handshake with client auth - worked 
correctly. So, I believe the code for client auth is the same for all 
SSL sockets in Mozilla .I am using Mozilla 1.7 .

Please try https://yoursmtpserver:465 to find out if you get the client 
cert pop-up. I suspect you won't, because you have another problem, such 
as a misconfigured SMTPS server.
0
Julien
8/25/2004 11:42:56 PM
On Wed, 25 Aug 2004, Julien Pierre wrote:

> > This works for Mozilla _browser_ and not for mozilla mailer. :(
> > If I try to connect to smtps service the mailer does not ask me for any
> > certificate (although "ask every time" is set).
> > If the remote peer is configured to not authenticate the client everyth=
ing
> > works perfectly, but if the remot end requires certificate I got an Err=
or
> > Code -12227.
> > On the server side I got:
> > Aug 25 16:40:51 XXX stunnel[7890]: SSL_accept: 140890C7:
> > error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not
> > return a certificate
> >
> > The mailer is configured to _send_ mails through smpts on port 465.
> >
> > Seems like the client certificate authentication feature is missing in
> > mozilla mailer (1.7.2).
> >
> I tried it with SMTPS I don't have an SMTPS server with client auth, but
> I do have an HTTPS server with client auth. All I did was configure it
> as SMTPS server, with SSL . When trying to send a message through it, I
> did get the cert selection pop-up (I have "ask every time"). Of course,
> I couldn't send the message after that, because the server behind isn't
> SMTP, but the initial part - the SSL handshake with client auth - worked
> correctly. So, I believe the code for client auth is the same for all
> SSL sockets in Mozilla .I am using Mozilla 1.7 .
>
> Please try https://yoursmtpserver:465 to find out if you get the client
> cert pop-up. I suspect you won't, because you have another problem, such
> as a misconfigured SMTPS server.
>

I set up my own https server using mod_ssl. I set it up to:
SSLVerifyClient require
SSLVerifyDepth 1
SSLCACertificateFile /path/cacert.pm

If I connect using stunnel s_client and providing the proper cert
everything works, but if I type into Moxilla 1.7.2 https that server I got
exactly the same error:
"hostname has received an incorrect or unexpected message. Error Code:
-12227"


However now I realized that Mozilla requires my client Cert in PKCS#12
format (not pem). I was mislead by the "Purposes" field of "Web Sites"
certificates tab, which says "Client,Server" and I installed only the
server certificate.
When I converted the cert to PKCS#12 and installed it in mozilla it
worked!
THANK YOU for your help!


p.s. Mozilla should be able to properly report that there is no
certificate...
p.s. why is mozilla not capable of importing pem client certs?

--=20
Mariusz Wo=B3oszyn
Internet Security Specialist, GTS - Internet Partners
0
Mariusz
8/26/2004 11:09:27 AM
Mariusz Woloszyn wrote:
> 
> p.s. Mozilla should be able to properly report that there is no
> certificate...

There is nobody working the mozilla security UI and so many errors are 
displayed with numbers, such as the one you got, instead of strings .

> p.s. why is mozilla not capable of importing pem client certs?

I believe (but am not sure) that PEM format may contain the object in 
plaintext, and thus is not a suitable secure transport format for a 
private key, unlike PKCS#12, which allows the key within the file to be 
encrypted, when you set a passphrase, and thus PEM is considered too 
insecure a format to support for NSS and Mozilla, at least as far as 
private keys are concerned.
0
Julien
8/26/2004 11:46:58 AM
Mariusz Woloszyn wrote:
> However now I realized that Mozilla requires my client Cert in PKCS#12
> format (not pem). I was mislead by the "Purposes" field of "Web Sites"
> certificates tab, which says "Client,Server" and I installed only the
> server certificate.

PEM usually only includes the public certificate and not the private 
key, at least Mozilla only understand the form with the cert only, even 
if openssl can concatenate both together inside a PEM (but you can find 
many things inside an openssl PEM even a crl for exemple).

If you import a PEM, you can not use the result a personnal certificate, 
because you get only the cert, not the private key.
It can be useful to import PEM cert to be able to send encrypted mail to 
someone (you only need to know his public key to do that).

The purpose tab might be confusing. If it says 'client' for a cert that 
is not your own, that means that the owner of that cert can use it for 
client usage, *not* that /you/ can use it as a client cert.

It's probably not so useful to know that, and maybe it should be left in 
the certificate details.

0
Jean
8/26/2004 6:27:08 PM
Julien Pierre wrote:
> Also, if there is no UI for managing certs in Thunderbird, even basic 
> SSL connections may fail if there is no way to install corporate root 
> certs and trust them. That's going to be a much more common problem than 
> not supporting client auth.

I have this sort of setup on a system I manage as a hobby. I have Cyrus 
IMAP running IMAP over SSL and Postfix supporting SMTP over SSL; however 
I'm not using client authentication, just password-based authentication 
over SSL. The server certs are issued using a mini-CA I operate using 
OpenSSL. (Nelson, please avert your eyes :-)

Thunderbird works OK with this setup, but as you note there is no way 
for me to import the root CA certificate for my CA. Thus I have to rely 
on TB to present the initial cert warning dialog, and then tell it to 
accept the server certificate. After that everything seems to work OK.

Not being able to manage certs is certainly an inconvenience, but let me 
play devil's advocate for a moment: In a real enterprise deployment of 
Thunderbird it might be better to ship a customized version with 
pre-loaded certs, as opposed to relying on users to import a corporate 
root cert. Thus one could make an argument that instead of trying to 
design and implement Thunderbird UIs for cert management it would be 
more useful to enterprise customers just to make it as simple as 
possible to do cert preloading. (When I have some spare time I should 
seach out the instructions on how to rebuild the relevant NSS library 
and see if I can do this myself.)

Frank

-- 
Frank Hecker
hecker@hecker.org
0
Frank
8/26/2004 11:51:40 PM
Franck,

Frank Hecker wrote:
> 
> Thunderbird works OK with this setup, but as you note there is no way 
> for me to import the root CA certificate for my CA. Thus I have to rely 
> on TB to present the initial cert warning dialog, and then tell it to 
> accept the server certificate. After that everything seems to work OK.

So, how informed is the decision when you make it ? Can you view the 
cert details before accepting the cert and trusting it ? Or do you have 
to do it just blindly ?

> Not being able to manage certs is certainly an inconvenience, but let me 
> play devil's advocate for a moment: In a real enterprise deployment of 
> Thunderbird it might be better to ship a customized version with 
> pre-loaded certs, as opposed to relying on users to import a corporate 
> root cert. Thus one could make an argument that instead of trying to 
> design and implement Thunderbird UIs for cert management it would be 
> more useful to enterprise customers just to make it as simple as 
> possible to do cert preloading. (When I have some spare time I should 
> seach out the instructions on how to rebuild the relevant NSS library 
> and see if I can do this myself.)

It's often not a practical solution in multi-platform environment to 
rebuild all the clients with pre-loaded certs. I think the deployment 
cost is too high, and the corporations will just look elsewhere for apps 
that have a cert manager.
0
Julien
8/27/2004 12:47:57 AM
Julien Pierre wrote:
> I believe (but am not sure) that PEM format may contain the object in 
> plaintext, and thus is not a suitable secure transport format for a 
> private key, unlike PKCS#12, which allows the key within the file to be 
> encrypted, when you set a passphrase, and thus PEM is considered too 
> insecure a format to support for NSS and Mozilla, at least as far as 
> private keys are concerned.

I can protect PEM format objects with passphrases using OpenSSL.

-- 
   Heikki Toivonen
0
Heikki
8/27/2004 7:16:06 AM
Frank Hecker wrote:

> Thunderbird works OK with this setup, but as you note there is no way 
> for me to import the root CA certificate for my CA. Thus I have to rely 
> on TB to present the initial cert warning dialog, and then tell it to 
> accept the server certificate. After that everything seems to work OK.

Ummm I have the same situation, but using CAcert signed certs to protect 
the key and I imported the root cert just fine... Imported in the same 
way mozilla/firefox do, with the same popup what do you trust this root 
certificate for etc...

tools -> account settings -> security (on any accounts listed) -> manage 
certificates -> authorities -> import -> cacert.crt

tick, tick, tick

ok a few times and well that's all there is to it...
0
Duane
8/27/2004 8:51:16 AM
Duane wrote re importing certificates into Thunderbird:
> tools -> account settings -> security (on any accounts listed) -> manage 
> certificates -> authorities -> import -> cacert.crt

D'oh! I don't know how I missed this. I guess I was prepped by previous 
messages not to expect this to be present.

So what's all the fuss about then? AFAICT Thunderbird appears to have 
essentially the same capabilities for cert management as Mozilla.

Frank

-- 
Frank Hecker
hecker@hecker.org
0
Frank
8/27/2004 10:06:23 AM
Julien Pierre wrote:
> Frank Hecker wrote:
>> Thunderbird works OK with this setup, but as you note there is no way 
>> for me to import the root CA certificate for my CA. Thus I have to 
>> rely on TB to present the initial cert warning dialog, and then tell 
>> it to accept the server certificate. After that everything seems to 
>> work OK.
> 
> So, how informed is the decision when you make it ? Can you view the 
> cert details before accepting the cert and trusting it ? Or do you have 
> to do it just blindly ?

The cert acceptance dialog presented in Thunderbird appears to be 
exactly the same dialog you'd see in Mozilla for connecting to an 
SSL-enabled web site with a certificate from an untrusted CA (even the 
dialog wording says "web site"); you can view the cert details and do 
everything else you can do in Mozilla.

> It's often not a practical solution in multi-platform environment to 
> rebuild all the clients with pre-loaded certs. I think the deployment 
> cost is too high, and the corporations will just look elsewhere for apps 
> that have a cert manager.

Well in any case I think this point may be moot, since based on Duane's 
comment Thunderbird (0.7x) does appear to have a cert manager.

Frank

-- 
Frank Hecker
hecker@hecker.org
0
Frank
8/27/2004 10:11:34 AM
Frank,

Frank Hecker wrote:
> Duane wrote re importing certificates into Thunderbird:
> 
>> tools -> account settings -> security (on any accounts listed) -> 
>> manage certificates -> authorities -> import -> cacert.crt
> 
> 
> D'oh! I don't know how I missed this. I guess I was prepped by previous 
> messages not to expect this to be present.
> 
> So what's all the fuss about then? AFAICT Thunderbird appears to have 
> essentially the same capabilities for cert management as Mozilla.
> 
> Frank
> 

Some of us prefer to use the full mozilla suite. I never tried 
thunderbird. I was just commenting on the (apparently incorrect) 
information about thunderbird not having a cert manager. I'm glad to 
read that was wrong.
0
Julien
8/27/2004 11:40:02 PM
In the newsgroup news://news.mozilla.org:119/netscape.public.mozilla.browser
in a thread named "Master Password", there is a discussion about the
absence of UI for setting or using a Master Password in Thunderbird.

As a consequence of this lack of UI, it is reported in that thread that

a) users of profiles with key DBs that had a master password cannot use
those key DBs with thunderbird (no way to enter the master PW), and

b) users cannot password protect their key DBs or their saved password
files (no way to set the master password).

Look especially at these two articles:

news://news.mozilla.org:119/09hKc.2080$iK.145@newsread2.news.atl.earthlink.net
news://news.mozilla.org:119/l06Wc.8150$2L3.4968@newsread3.news.atl.earthlink.net

Now, if it's true that TBird users CANNOT password protect their key DBs,
then I think we (NSS developers) should insist that this be fixed.
This is a GROSS security hole.  Perhaps we should declare a moratorium
on additional NSS work until this capability is restored ot the TBird UI.

I'd be very happy for some TBird users to tell me that Mr. Gable is mistaken
about the absence of Master Password UI in TBird, but no-one has yet 
contradicted him in that newsgroup over this issue.

/Nelson
0
Nelson
8/28/2004 5:36:09 AM
Heikki Toivonen wrote:

> Julien Pierre wrote:
> 
>> I believe (but am not sure) that PEM format may contain the object in 
>> plaintext, and thus is not a suitable secure transport format for a 
>> private key, unlike PKCS#12, which allows the key within the file to 
>> be encrypted, when you set a passphrase, and thus PEM is considered 
>> too insecure a format to support for NSS and Mozilla, at least as far 
>> as private keys are concerned.
> 
> I can protect PEM format objects with passphrases using OpenSSL.

Yes, but you don't have to.  Most folks don't.

A .PEM file is a text file containing one or more blocks of lines with
the following general format:

---- BEGIN something ----
(lines containing only base64 encoded data, typically broken at 64 columns)
---- END something ----

IIRC, this is called the "PEM" format because this general format was
codified in the "Privacy Enhanced Mail" RFCs, which were predecessors
of the S/MIME RFCs.  See RFC 989 pages 11-15 for the original
specification and examples.

Today, a "PEM" file can contain many different kinds of objects, including
public keys, certificates, private keys (encrypted or not), cert signing
requests, and lots of other goodies.  The file extension "pem" only tells
you that the file contains one or more goodies in that format.  It doesn't
tell you what the goodies are, and that file format doesn't (IMO) promote
secure key storage and management.

There is a certain tool that makes PEM files that contain unencrypted
private keys.  The tool can be made to encrypt them, but does not
require that, and many users simply choose to skip it.  Since we're trying
to promote real security, and not the willy-nilly use of keys, we want to 
discourage the use of files of plaintext private keys as a key transport 
mechanism.  That, in a nutshell, is why mozilla only imports private keys
in PKCS12 format, which format does not define or allow the transport of 
unencrypted private keys.

mozilla is able to import certs from files in pem format, provided that
those files do not contain other types of goodies, IIRC.
0
Nelson
8/28/2004 6:03:54 AM
Nelson,

> Now, if it's true that TBird users CANNOT password protect their key DBs,
> then I think we (NSS developers) should insist that this be fixed.
> This is a GROSS security hole.  Perhaps we should declare a moratorium
> on additional NSS work until this capability is restored ot the TBird UI.

Because of FIPS 140-2 validation on softoken, we may be forced to put 
hard requirements on the password in the future, and no password 
wouldn't do . So, I think Tbird would be broken in the future if users 
can't set a password on the NSS DB, at least if FIPS mode is enabled. I 
guess they wouldn't be able to turn on FIPS mode anyway either ...
0
Julien
8/28/2004 6:45:20 AM
Nelson Bolyard wrote:
> In the newsgroup 
> news://news.mozilla.org:119/netscape.public.mozilla.browser
> in a thread named "Master Password", there is a discussion about the
> absence of UI for setting or using a Master Password in Thunderbird.

Hard to find in the UI, but it's there (at least in TB 0.7.1). Same 
place as FF (0.9.1). Had to use Google to figure this out - search for 
words "master", "password", "thunderbird" and this is the first link:

http://kb.mozillazine.org/index.phtml?title=Thunderbird_:_FAQs_:_Set_a_Master_Password

I did not find how to reset master password, or how to set master 
password timeouts - I even tried making 
chrome://pippki/content/pref-masterpass.xul the "message of the day" or 
whatever it is called but I got an error about a missing entity.

> Now, if it's true that TBird users CANNOT password protect their key DBs,
> then I think we (NSS developers) should insist that this be fixed.
> This is a GROSS security hole.  Perhaps we should declare a moratorium
> on additional NSS work until this capability is restored ot the TBird UI.

Isn't it premature to think about moratoriums without talking to the 
developers first and seeing if you can reason with them? A little 
positive attitude and cooperation can go a long way...

-- 
   Heikki Toivonen
0
Heikki
8/28/2004 7:55:25 AM
Nelson Bolyard wrote:

> I'd be very happy for some TBird users to tell me that Mr. Gable is 
> mistaken
> about the absence of Master Password UI in TBird, but no-one has yet 
> contradicted him in that newsgroup over this issue.

Don't know about changing the password etc, but it deff asked me to set 
one when I was importing certs, and it deff prompts me to enter it when 
encrypting email, at least the first time that session. I haven't really 
bothered looking into it any further then that.
0
Duane
8/28/2004 3:09:53 PM
Nelson Bolyard wrote:
> There is a certain tool that makes PEM files that contain unencrypted
> private keys.  The tool can be made to encrypt them, but does not
> require that, and many users simply choose to skip it.  Since we're trying
> to promote real security, and not the willy-nilly use of keys, we want 
> to discourage the use of files of plaintext private keys as a key 
> transport mechanism.  That, in a nutshell, is why mozilla only imports 
> private keys
> in PKCS12 format, which format does not define or allow the transport of 
> unencrypted private keys.

If this tool is a popular tool, then the decision to not
accept its output format may well do more security damage
than good.

If users find that dealing with mozilla products is difficult,
they are far more likely to either not deal with the product,
or not set it up to use keys at all.  Hence, they have lost
any security benefit, and only the very few who go through
the trouble and jump through all the security hoops to use
the more difficult tools will enjoy any protection.

In general, if Mozilla wants to provide people protection, it
should bend over backwards to help.  Even to the extent of
opening up weaknesses and apparent security holes - if it
helps more people to use it.  It's much more useful to say
that we have millions that are being protected, but there
are weaknesses, than we have thousands that are being protected,
and there are no weaknesses (that we admit to).

The notion that an unencrypted key is insecure is rather an
unsupportable statement.  If the PEM-producing tool is on
the same machine, and the machine hasn't been compromised,
then it matters not if it is encrypted.  Such an unencrypted
key is secure - leaving us with the bad situation that valid,
secure activity is not permitted.  "Sometimes might be insecure"
is generally weak security design, as the open source developer
rarely has a way of measuring that "sometimes."  (The same goes
for most corporate networks which are locally secure - but mail
needs to be secured for outgoing.)

Only if the platforms have been compromised *and* the compromise
inserts some trojan that scans for unencrypted keys would there
be any issue here.  Although this is highly unlikely, it is a
plausible issue:  it should be dealt with in the first instance
by warnings and/or advices, not by not permitting this activity.

For the most part, users are far more adept at making these
sorts of security decisions than developers give them credit
for.  They are also far more adept at ignoring crypto that
is too hard to use that we want...

And, when they do get it wrong, then they start to learn.  But,
at least they had the chance to be wrong, and be protected for
those parts of the activity where an unencrypted key can still
protect.

iang
0
Ian
8/28/2004 10:25:30 PM
Ian Grigg wrote:

> If users find that dealing with mozilla products is difficult,
> they are far more likely to either not deal with the product,
> or not set it up to use keys at all.  Hence, they have lost
> any security benefit, and only the very few who go through
> the trouble and jump through all the security hoops to use
> the more difficult tools will enjoy any protection.

But this is a double edge sword, the easier you make security the less 
likely good security will be used defeating potentially all benefit in 
having it in the first place. Good security isn't about making things as 
easy as possible, this merely has the effect of making people 
complacent, what's most needed is good documentation on why things are 
done the way they are done, good flow in the user interface so as to 
reduce confusion. Make education easier, not necessarily the technical 
side of security or you make it almost as useless as not having it.

This was more a comment in general.

As for openssl private keys, my understanding was you could still have 
the key encrypted with rsa encryption, but yet stored in 7bit ascii 
instead of binary.
0
Duane
8/29/2004 2:36:47 AM
Duane wrote:
> Ian Grigg wrote:
> 
>> If users find that dealing with mozilla products is difficult,
>> they are far more likely to either not deal with the product,
>> or not set it up to use keys at all.  Hence, they have lost
>> any security benefit, and only the very few who go through
>> the trouble and jump through all the security hoops to use
>> the more difficult tools will enjoy any protection.
> 
> 
> But this is a double edge sword, the easier you make security the less 
> likely good security will be used defeating potentially all benefit in 
> having it in the first place.

Duane, this is simply not the case.  People use security,
but only when it doesn't interfere.  Marketing studies and
our own experience have consistently shown that people will
choose convenience over security every time.  So much so
that almost all pure security companies go broke eventually.
(If you look at the examples that succeeded in pure crypto,
they are not security companies, but sellers of franchises.)

Making available a product has little bearing on whether
people will use it.  Only whether it does good stuff for
people will people use it - and when it comes to security,
that is almost always defined as "does what I want to do
anyway with insecure tools but without interfering."

The SSL security model got *that* part right with the notion
of the browser accepting anything signed by a pre-ordained
list of root certs.  Unfortunately, that model doesn't always
translate outside browsing (and has unfortunate implications
within browsing as well).

When it comes to email, it's impossible to get people to
engage in that horribly messy certificate business.  It's
hard enough getting merchants to do it, which is why the
cert franchise had to be limited to credit card protection
only.

So you end up with a perfectly secure system - S/MIME and
so forth - that simply isn't being used.  How can you call
that "delivering security?"  Call it a piece of art, sure.
But a system that delivers strong security to the users of
products like Thunderbird?  No way.

Kirckhoffs' 6th principle is "it is necessary, given the
circumstances that command its application, that the system
be easy to use, requiring neither mental strain nor the
knowledge of a long series of rules to observe."  Kirckhoffs
was studying soldiers, who in respect of communications are
quite similar to Internet users:  they have a job to do and
if the communications security system slows that job down,
they bypass it in an instant.

http://www.financialcryptography.com/mt/archives/000195.html

Just like email users.

 > Good security isn't about making things as
> easy as possible, this merely has the effect of making people 
> complacent,

Duane, you are assuming that you can make people "be good"
about security.  No such pertains - people *are* by
definition complacent about security.  The challenge is
to give them security that works *even* when they are
complacent.

 > what's most needed is good documentation on why things are
> done the way they are done, good flow in the user interface so as to 
> reduce confusion. Make education easier, not necessarily the technical 
> side of security or you make it almost as useless as not having it.

No amount of documentation is going to help, only the
dedicated read documentation.  Yes, a good flow is
important, but the challenge is to have an equivalent
experience to what they already use.

Later on, those that really need the security will
find out and spread knowledge amongst themselves
about the weaknesses and how to improve things.  But
they only get the opporunity if they've been tricked
into using the security infrastructure in the first
place, generally by its transparency.

> This was more a comment in general.

Sure!

> As for openssl private keys, my understanding was you could still have 
> the key encrypted with rsa encryption, but yet stored in 7bit ascii 
> instead of binary.

Apparently this is the case - but because it is possible
to deliver them unencrypted, the PEM format is deemed
"not acceptable".  If PEM format is used frequently, or
is generated by a popular tool, this is generally going
to lower security by reducing opportunities far more than
it will ever increase security by avoiding attacks.

You only get security if the system is used.

iang
0
Ian
8/29/2004 10:11:02 AM
Ian Grigg wrote:

> Duane, this is simply not the case.  People use security,
> but only when it doesn't interfere.  Marketing studies and
> our own experience have consistently shown that people will
> choose convenience over security every time.  So much so
> that almost all pure security companies go broke eventually.
> (If you look at the examples that succeeded in pure crypto,
> they are not security companies, but sellers of franchises.)

But it is the case, lowering the barrier to entry will do one thing, 
make it easier for people with scams to get private keys and then the 
whole digital identity thing is a waste of time because they won't care 
enough to revoke, or even worst trojans get in and they're none the 
wiser... This is the sort of thing that should be taught at school in 
computing classes and I believe some of it is, good common sense when 
dealing with the internet and people trying to do anything they can to 
make a buck no matter what it does to others... Making it easier for 
users makes it easier for those trying to exploit others as well...
0
Duane
8/29/2004 10:42:43 AM
Duane wrote:
> Ian Grigg wrote:
> 
>> Duane, this is simply not the case.  People use security,
>> but only when it doesn't interfere.  Marketing studies and
>> our own experience have consistently shown that people will
>> choose convenience over security every time.  So much so
>> that almost all pure security companies go broke eventually.
>> (If you look at the examples that succeeded in pure crypto,
>> they are not security companies, but sellers of franchises.)
> 
> 
> But it is the case, lowering the barrier to entry will do one thing, 
> make it easier for people with scams to get private keys and then the 
> whole digital identity thing is a waste of time because they won't care 
> enough to revoke, or even worst trojans get in and they're none the 
> wiser...

"people with scams to get private keys" ????

Scammers who want keys can get them anytime they want!
The reason that keys are not scarfed up by viruses
and trojans is almost certainly because they are of
no use and are not deployed widely enough to be
interesting.  Also, scammers can generate bona fide
keys with strong chains of authenticity as fast as
they need them.

There is no chance that a "strong" identity system such
as envisaged by client or S/MIME certs will ever slow
down scammers, whether we are talking about spam,
phishing, hyips, ponzis, or bogus issuers.

Almost all scams ignore the crypto because both
the scammer and the scammee both agree that it is
irrelevant.  (For some time now, trojans and viruses
have been scarfing up passwords and user details
for banking sites.  This has been going on for a long
time, but it's only now starting to reach the mainstream
awareness - so much so that I have no clue how prevalent
it is.  If scammers want keys, they could go in and get
them, there is only the mildly technical challenge of
how they get past the encryption to deal with.)

Until there is really substantial use of crypto - I
mean numbers like 1-10% of normal activity, there is
no real need to worry about scammers even noticing the
crypto.  And at the point where we have substantial
numbers of people really being protected, then there
might be some interest in the scammers.  But not before.

It is a basic starting point that the whole digital
identity thing *is* a waste of time.  Ordinary People just
don't do that, naturally.  They establish identity not
by software means, but by context means - by establishing
a series of unbroken messages hopping over different
channels.  The only time that people - ordinary people
- use strong identity tokens is when they are forced
to by some higher power.  As there is no higher power
at work here, the notion that people want to establish
their identity strongly on the net is a non-starter as
a broad movement.

The p2p world is quite explanatory in this fashion:  some
young people go through chat handles like you and I go
through cups of coffee.  (Yes, teenagers have been
tracked doing 8 nyms a day.)  In order to make themselves
secure, they make themselves untraceable and non-persistent.
Making it easier for these people to generate crypto
keys on the fly and use them and dispose of them does
one thing and one thing alone:  it adds encryption to
their traffic, which is an absolute and net good in
security terms.

The same goes for email...  The more easily the crypto
infrastructure in place makes it easy to generate
encrypted email, the better.  With no downside that
I can see, including using unencrypted keys.

If the keys were unencrypted it would change this
security equation not one iota, because the keys are
disposed of within an hour anyway.  There are really
two worlds here:  what people use identity for, and
how the infrastructure postulates identity, and the
gulf between them is so severe that there is no real
commonality.

iang
0
Ian
8/29/2004 12:26:29 PM
Ian Grigg wrote:

> Nelson Bolyard wrote:
>> There is a certain tool that makes PEM files that contain unencrypted
>> private keys.  The tool can be made to encrypt them, but does not
>> require that, and many users simply choose to skip it.  [...]
> 
> If this tool is a popular tool, then the decision to not
> accept its output format may well do more security damage
> than good.

I have a strong feeling Nelson is talking about a perticular popular 
tool that use PEM has it's native format for everything, and that does 
output private keys encrypted by default.
This tools also has a command line option to make them unencrypted.

As the web server, this tool is often used to generate keys for can't 
start automatically if their private key is encrypted, many tutorials 
around tell to set the option to the value to unencrypt the key.

It's not that bad a decision, because if the server can start 
automatically, then that means that the password has to be stored 
somewhere where it can be compromised as easily as the private key itself.
0
Jean
8/30/2004 9:22:08 AM
Jean-Marc Desperrier wrote:

> As the web server, this tool is often used to generate keys for can't 
> start automatically if their private key is encrypted, many tutorials 
> around tell to set the option to the value to unencrypt the key.
> 
> It's not that bad a decision, because if the server can start 
> automatically, then that means that the password has to be stored 
> somewhere where it can be compromised as easily as the private key itself.

 From a web server pov, yes, most keys would be unencrypted.  I can't
see much of a case for leaving the server keys encrypted, as

    a) Ahere isn't much of a threat to stealing most keys.
    b) Ahe keys are unencrypted inside the running server anyway.
    c) Anyone who can hack into the machine can invent half a dozen
       strategies to acquire an unencrypted key before tea-time.
    d) Automatic or non-operator assisted restarts are an issue, and
    e) lost transactions are more important than lost keys.

Whether the unencrypted keys on server side have much to do with
encryption of keys for the browser, I don't know.  There doesn't
seem to be much of a relationship other than common sense.  (It's
a balance between achieving enough security and enough convenience
to do some good, but I think I covered that ad nauseum....)

iang
0
Ian
8/30/2004 3:28:24 PM
Ian Grigg wrote:

> If this tool is a popular tool, then the decision to not
> accept its output format may well do more security damage
> than good.
> 
> If users find that dealing with mozilla products is difficult,
> they are far more likely to either not deal with the product,
> or not set it up to use keys at all.  Hence, they have lost
> any security benefit, and only the very few who go through
> the trouble and jump through all the security hoops to use
> the more difficult tools will enjoy any protection.
> 
> In general, if Mozilla wants to provide people protection, it
> should bend over backwards to help.  Even to the extent of
> opening up weaknesses and apparent security holes - if it
> helps more people to use it.  It's much more useful to say
> that we have millions that are being protected, but there
> are weaknesses, than we have thousands that are being protected,
> and there are no weaknesses (that we admit to).
> 
> The notion that an unencrypted key is insecure is rather an
> unsupportable statement.  If the PEM-producing tool is on
> the same machine, and the machine hasn't been compromised,
> then it matters not if it is encrypted.  Such an unencrypted
> key is secure - leaving us with the bad situation that valid,
> secure activity is not permitted.  "Sometimes might be insecure"
> is generally weak security design, as the open source developer
> rarely has a way of measuring that "sometimes."  (The same goes
> for most corporate networks which are locally secure - but mail
> needs to be secured for outgoing.)
> 
> Only if the platforms have been compromised *and* the compromise
> inserts some trojan that scans for unencrypted keys would there
> be any issue here.  Although this is highly unlikely, it is a
> plausible issue:  it should be dealt with in the first instance
> by warnings and/or advices, not by not permitting this activity.
> 
> For the most part, users are far more adept at making these
> sorts of security decisions than developers give them credit
> for.  They are also far more adept at ignoring crypto that
> is too hard to use that we want...
> 
> And, when they do get it wrong, then they start to learn.  But,
> at least they had the chance to be wrong, and be protected for
> those parts of the activity where an unencrypted key can still
> protect.
> 
> iang

Token security is no security. Therefore I support the standpoint of the 
Mozilla development team.
-- 
Ulrich Boche
0
Ulrich
8/30/2004 7:00:20 PM
Ulrich Boche wrote:
> Token security is no security. Therefore I support the standpoint of the 
> Mozilla development team.

And ... Unused security is no security.

Security then exists somewhere between the extremes
of convenience and heavy duty.

Stretching an analogy here:  Discussions over the last
6 months led to a Mozilla policy that the the browser
should be delivered set up for the user that does not
fiddle with the settings.  That is, security should
be the best for that user, and experienced users can
be left to adjust any weaknesses.

That was for the browser, and its root list.  If the
team were to apply that logic to Thunderbird, the
situation is reversed:  Thunderbird is delivered with
no security for the default user.  They have to undergo
the same configuration nightmare that experienced users
do in order to use the crypto features.

So the question is:  is the policy one of general
application, and should it apply to Thunderbird?

Restated:

Should Mozilla's mission be to protect the default-
settings user?

And, how would one configure Thunderbird to protect
the basic user?

iang
0
Ian
8/30/2004 8:22:59 PM
Nelson Bolyard wrote:
> There is a certain tool that makes PEM files that contain unencrypted
> private keys.  The tool can be made to encrypt them, but does not
> require that, and many users simply choose to skip it.  Since we're trying
> to promote real security, and not the willy-nilly use of keys, we want 
> to discourage the use of files of plaintext private keys as a key 
> transport mechanism.  That, in a nutshell, is why mozilla only imports 
> private keys
> in PKCS12 format, which format does not define or allow the transport of 
> unencrypted private keys.

This seems like an extremist approach. Users can always find ways to 
shoot themselves (for example having the password in plain text file 
next to the password protected private key).

Why not enable importing in PEM format as well, and in case the PEM is 
not protected by a password, inform the user of this fact and require 
the user to set a password?

People who encrypt their stuff are happy, people who don't encrypt get a 
nag and maybe learn a little about security and in the end will be happy 
as well...

-- 
   Heikki Toivonen
0
Heikki
9/1/2004 4:27:00 AM
Reply:

Similar Artilces:

Using client certificates: "Require client certificates" is enabled on IIS
 Hey world, I have an application that works fine using SSL, but when I enable  "Require client certificates" on IIS it prompts the client for a certificate (behavior kind of expected) but I can't figure out how to create a "Client Certificate" so the client can access the application. I followed step by step this article with no luck:http://support.microsoft.com/kb/901183 (the WinHttpCertCfg.exe –i PfxFile -c LOCAL_MACHINE\MY -p Password  line just wouldn't work) I created a certificate on my test web server using "SelfSSL" and then I exported it as an .P...

Using a 'secret' SSL client certificate from Mozilla
Hi all, In our (mozilla/xulrunner-based) application, we're trying to set up a secure connection to a server that requires a client certificate. Rather than the normal case of a client certificate belonging to the user, and just added to the certificate store, we want to have a certificate that nominally belongs to the application, and is secret from the user (strange, but that's what I'm stuck with). The specific requirements are that we not store it unencrypted in the filesystem - and simply setting a password on the key db isn't an option, as that would interf...

Generate, client certificate for use with ASP.Net webapp, use for auth
I need to do the following: 1. Generate a client certificate that has a common name (CN) of "my.server.com:myappname". 2. Generate a CSR that I can send to a remote company in order for them to sign my certificate. I paste the CSR into the company's webform, hit submit, the remote company will then send me back a certificate for their CA, and a signed certificate for my app to use to communicate with their servers. 3. Import the CA certificate so that the signed certificate I was issued will be considered valid. 4. Import the signed certificate for my webapp. 5. Acc...

Client Authentication using certificates.
Hi! I am using libwwwperl to send a post request in HTTPS. I am using client authentication through certificates in Apache+mod_ssl. How to I send the certificate through LWP::UserAgent? any sample code will be of a great help. Thanks in Advance Tusar ===== Tusar K Nayak @Communicators http://tusar.netshooter.com Ph - 91-11-5528098(R) Fax:91-11-5613991 ************************************************* When in doubt, follow your heart. __________________________________________________ Do You Yahoo!? Get Yahoo! Mail � Free email you can access fr...

Using Client certificate with HTTPRIO
Hi, Working with XE2 now the THTTPRIO.HTTPWebnode has ClientCertificate properties. I can select a certificate from the store at design time but that's it. It seems to do nothing at all. Has anybody a working example for a THTTPRIO.HTTPWebnode with a clientcertificate? Thanks. Hello, > > Working with XE2 now the THTTPRIO.HTTPWebnode has ClientCertificate > properties. I can select a certificate from the store at design time but > that's it. It seems to do nothing at all. > > Has anybody a working example for a THTTPRIO.HTTPWebnode with a > c...

Client auth only sending client certificate, not sending intermediate CA certificates
[ moved to this list, per = https://groups.google.com/d/msg/mozilla.support.firefox/Ba4MzFQxqP8/DbmDU= CbJqxkJ ] I was trying to figure why some of the uses were not having a chain sent = to the server for their client certificate, and it turns out Firefox = does not send (by default?) the chaining certs. After reviewing https://wiki.mozilla.org/PSM:CertPrompt , it seems = Firefox will 'validate' that the client cert can be chained, before = allowing the user to select it. Here is a snippet of a diff of the TLS Certificate, Client Key Exchange, = and Certificate Verify ...

Client auth only sending client certificate, not sending intermediate CA certificates
I was trying to figure why some of the uses were not having a chain sent = to the server for their client certificate, and it turns out Firefox = does not send (by default?) the chaining certs. After reviewing https://wiki.mozilla.org/PSM:CertPrompt , it seems = Firefox will 'validate' that the client cert can be chained, before = allowing the user to select it. Here is a snippet of a diff of the TLS Certificate, Client Key Exchange, = and Certificate Verify packets of IE and FF. Full packets upon request. $ diff -u firefox-client-TLS.txt internetExplorer-client-TLS.txt ...

Using client-side certificates with Sunbird
Does anyone have any clue how to enable the use of client-authentication certificates with Sunbird? I'm trying to access a calendar on a WebDAV folder that requires client authentication. I can browse the folder with Firefox or IE if I've imported the client certificate into them, but Sunbird doesn't have the certificate management options that Firefox does. Is this something that it's easy to turn on in the XUL, or is there some more fundamental problem with me doing this in Sunbird? [Cross-posting and setting follow-ups to go to mozilla.support.calendar] ...

SSL-client auth. using certificate
Hi all, can anybody help me out to tell me howto authentificate to a SSL v3 server using a client certificate? TIA Tobias -- Sent through GMX FreeMail - http://www.gmx.net ...

Mozilla CA Certificate Policy
http://www.mozilla.org/projects/security/certs/policy From what I have seen on this list there has been a lot of talk about inclusion of various CA root certificates in the Mozilla distributions. IMO, most of these CAs are insignificant except for SSL certs. Why? Because the vast majority of organizations (in the rare situation that they use client-side PKI), actually issue their own client-certificates. BTW, I don't see that other providers of security software are particularly anxious extending their preconfigured trust lists. Some of the CAs like the recently discussed ...

Linux client and Encryption using certificates
Can anyone tell me when the linux client will have certificates for encryption - we are in the process of migrating users from pop/evolution to groupwise and of course we receive email from a government agency that is encrypted using a certificate - no problem with evolution or windows client (or thunderbird) but mid way in migration I discover that the Linux client doesn't do it and if my reading of this forum is correct - bonsai won't have it either. Web client doesn't have it as well so that's not a solution - at present work around is to leave evolution connecte...

using client SSL certificate with Firefox
------=_Part_3233_3369848.1142383177612 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, I generated a client SSL certificate (tried both by using openssl and certutil) converted it to PKCS#12 format. After that, I imported it into Firefox and can see the certificate of the "Your Certificates" tab in Edit = > Preferences > Advanced > View Certificates. However, when I do the TLS handshake, the client never sends a certificates - the certificate callback function always fails and the ...

Using THTTPRIO with client side certificate
Hi, I'm connecting with THTTPRIO to a server and using WebServices that i generate with WSDLImp.exe. There are a two types of authorization. Basic authorization with user name and password and the second with client side certificate and user name, password. For basic authorization I'm using: Rio.HTTPWebNode.OnBeforePost := EvHandler.OnBeforePost; .... procedure TEventHandlers.OnBeforePost(const HTTPReqResp: THTTPReqResp; Data:Pointer); begin if not InternetSetOption(Data, INTERNET_OPTION_USERNAME, PChar(UserName), Length(UserName))then ...

Using client certificate to identify user
hello, our users have their own client certificates instlled on machines and we would like to identify them by initializing/open user identification request window in browser. After selecting appropriate we want to process client certificate information (like id,...) in our IW application. ....any suggestions, how to implement identification in intraweb 14.0.25 Best regards, ...

Web resources about - Using client certificates for smtps - netscape.mozilla.crypto

Certificate of Entitlement - Wikipedia, the free encyclopedia
On 1 May 1990, the then transportation unit of Singapore's Public Works Department (PWD) instituted a quota limit to vehicles called the COE ...

December Patch Tuesday avalanche of patches includes leaked Xbox certificate
... of a security fumble by Microsoft's internal IT team—the inadvertent disclosure of the private encryption keys for a wildcard SSL/TLS certificate. ...

Dell responds to concerns over certificate vulnerability
... is less common. But, that's exactly what Dell has been doing, unintentionally of course. A problem has been discovered in the eDellroot certificate, ...

Protecting your site for free with Let's Encrypt SSL certificates and acmetool
... has been more elevated lately, due to their opening up their service as a public beta. If you don't know what Let's Encrypt is, it's a Certificate ...

MSNBC's Chris Matthews confronted Donald Trump about Obama's birth certificate after the debate
... , MSNBC host Chris Matthews confronted Donald Trump over the real-estate mogul's past questioning of President Barack Obama's birth certificate. ...

Microsoft zaps dodgy Dell digital certificates
Microsoft has updated several of its security tools to remove two digital certificates installed on some Dell computers that could compromise ...

Older Dell devices also affected by dangerous eDellRoot certificate
... laptops, desktops, tablets and other devices that were bought before August should check if their systems have the self-signed eDellRoot certificate ...

Google Pulls Trust for Symantec Root Certificate
For security reasons, Chrome, the Android OS and other Google products will no longer trust digital certificates from an old Symantec root certificate. ...

Dell Promises To Kill Dangerous Security Certificate It Shipped On PCs
Dell says it regrets the decision to install a dangerous "root certificate" for encrypted web use on its computers and promises to kill it for ...

Texas has only recently stepped up birth certificate enforcement for immigrants, records show
Texas has only recently stepped up birth certificate enforcement for immigrants, records show

Resources last updated: 12/17/2015 1:11:06 PM