date:20090321


On 20/3/09 08:32, Anders Rundgren wrote:

This is a stupid discussion.

Authentication schemes in general begin with authenticating the user.
How long the authentication should be considered as valid is
not something the client-end has anything to do with unless it
has gotten some kind of expiration data from the server.




An awful lot depends on what we mean by authentication ...

I'm not sure how one would come up with an expiry on authentication that 
will please everyone.  It seems that at the low end, we are talking a 
few minutes, which seems to be a connection-oriented number.


At the high end, in the (new policy list), it is often mentioned that 
the expiry on a cert should be limited to 2 years, and some certs are 
issued for much longer.


Is there any difference between these authentication expiries?



It seems pretty clear that the real culprit is the TLS protocol itself.



:)  and all the rest.  After MITB surfaced (and scared the European 
bankers into action) people in finance circles started to realise that 
session authentication was a mistake from the beginning (and that SSL 
was the vector for that mistake).  Now they are heading towards 
transaction authorisation, which by was what the customer wanted in the 
first place.  The favourite is to do something like a transaction-level 
authentication over the mobile phone.  If it goes its full path, we'll 
eventually see authorisation of the transaction rather than 
authentication of the individual, and then things will be safer.


TLS plays no part in that, or, you are right that the part it plays is 
that of the culprit;  distracting attention from the real security needs 
by imposing its security model.




Fortunately a lot of people are working hard to establish schemes
that use the good part of TLS (server-auth) and leave the unwieldy
part to a community that won't be able fix it.



Getting back to the cheap end of the market, right, some of us are 
still trying to extract value by getting TLS to the always-on and 
dual-authentication status.  Only then can it deliver real value up to 
the application, rather than open up weaknesses in other areas.  For 
this, client certs seem to be useful, because the code is already 
written in the server side.


But it looks like the real issue here is going to be filled out by 
Johnathan's ideas for some more GUI control and the existing restart 
being constrained by user-driven policy.


iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSSSSL_VersionCheck Sigpipe with curl

2009-03-21 Thread Wan-Teh Chang

2009/3/20 John D cono...@gmail.com:

I have attempted this to the result of

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1810576496 (LWP 3177)]
0xb79e6547 in NL_VersionCheck () from /usr/lib/libssl3.so.1d
(gdb) where
#0 0xb79e6547 in NL_VersionCheck () from /usr/lib/libssl3.so.1d
#1 0xb79e212d in SSL_GetStatistics () from /usr/lib/libssl3.so.1d

I believe your program did receive SIGPIPE, which was reported
by gdb but ignored by your program because of the sigaction call.
(gdb reports all signals received.)

Then your program received SIGSEGV and crashed. So we
should now track down what caused the segmentation fault.
Again, I would not trust the SSL_GetStatistics and NL_VersionCheck
function names in the stack trace because of the lack of debug
symbols for /usr/lib/libssl3.so.1d. I suggest that you build
debug versions of NSPR and NSS libraries and use them
with your program to get a stack trace with useful debug info.

You can build NSPR and NSS libraries by following the NSS
build instructions at
https://developer.mozilla.org/en/NSS_reference/Building_and_installing_NSS/Build_instructions

You should only need to set the CVSROOT environment
variable, and USE_64=1 if you build 64-bit x86_64 binaries.

When the build completes, the NSPR and NSS libraries will
reside in the .../mozilla/dist/Linux2.6DBG.OBJ/lib directory
in your NSS build tree.

You can just add the .../mozilla/dist/Linux2.6DBG.OBJ/lib
directory from your NSS build tree to the LD_LIBRARY_PATH
environment variable, and then run your program to reproduce
the crash.

Wan-Teh
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: client certificates unusable?


On 20/3/09 22:30, Kyle Hamilton wrote:

'since you obviously shouldn't have different PKI UIs for signatures
and authentication'?  What crack are you smoking?



Hey Kyle, I think you are thinking way to far ahead here...



In the Real World, we have a different UI for authentication -- the
principal presenting an ID card -- than the UI for signatures -- a
piece of paper, a pen, and a unique mark made by the principal.

Having the same UI would be akin to having a post-it (or other
temporarily-adhered piece of paper) covering the upper part of the
page stating I'm authenticating myself to this person, while the
lower part of the page doesn't have that.  Then, the post-it's peeled
off to reveal that that it's a limited power of attorney that states
that it's in the signer's interest to transfer all of his assets into
the name of the person holding the document, and granting authority to
do so.



Your technical point may be correct, but it looks to me like a case of 
your perfect being the enemy of Ander's good.


Right now we are discussing the presence of a single UI, and not the 
separateness of the functions that the UI might handle.  Right now, 
Firefox has practically no or minimal user management for client 
authentication *or* client signing at either level.


From this point of view, having at least a single UI for the purposes 
of managing the certificates in a client authentication *and* any client 
signing purposes ... would be a significant win for the user, and for 
client certificates.  Once we get that, we might obviously see that 
doing a user-signing act is different and needs to be different.  But we 
will never get that far if we don't have the basic certificate 
management interface.


The perfect is the enemy of the good...  At least, let's start with the 
easy tasks, client auth, and see how far that gets us towards 
user-signing actions.



iang




PS:  BTW/IMHO, we don't need to worry about any wrong user interface 
for the user-signing act.  We already have a decade ++ of experience 
that if the UI isn't done properly, and indeed if the entire process 
isn't done completely utterly properly, users will refuse it.  It's the 
lawyers who have ploughed this ground ahead of us:  users know not to 
sign anything they don't understand, and that includes any wierdo crypto 
blah blah.




There are many people who think differently; I, for one, think that
server-auth is the *worse* part of TLS (because there's no branding of
what CA is responsible for the certification, there's no way to
identify when a session is re-used versus renegotiated, there's no way
to figure out what CAs are available on the client for
multiple-certification strategies,



PS2:  Hmmm On that last point, does this mean that if Firefox is set 
to automatically restart any request to client-auth to the server ... 
and there are TWO certificates it could use, we would (at least in 
principle, theoretically...) not know which certificate was used?


And therefore, if there is a problem, we would not know which CA was 
responsible for that problem?


H sounds like an auth bug?



This means that there's a problem with these assumptions -- being made
and implemented as they are without any real documented input from the
most important people of all: the users.



Yup!  That's why they don't adopt.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: NSSSSL_VersionCheck Sigpipe with curl

2009-03-21 Thread Daniel Stenberg


On Sat, 21 Mar 2009, John D wrote:

I wonder how thread safe NSS' integration with libcurl actually is. No 
offense Daniel but after switching to gnutils with their macros all problems 
related to this matter are resolved.  So be it.


I'm absolutely sure on how we use NSS in libcurl, and the nss.c code is not 
even particularly big or complicated so basically everyone who wants to can 
go see.


To the best of my knowledge, libcurl is using NSS as it is documented but as 
I've whined before on this very mailing list: the NSS API documentation is not 
exactly crystal clear in all aspects so of course things might not be 
perfectly done.


I think it can be helpful to the NSS project and to libcurl's NSS-interfacing 
code if you'd follow Wan-Teh's advice and help us get some further details on 
those problems and thus possibly improve things. Even if you obviously can 
avoid them by switching to another lib.


I don't understand why I would take offense but no, I didn't.

--

 / daniel.haxx.se
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: client certificates unusable?


On 21/3/09 16:54, Eddy Nigg wrote:


Huu? No outcry about rudeness in mailing lists here?



Eddy, I agree that rudeness was carrying us away from the problem and on 
to the personalities.  Indeed, it's up to all of us to be be minded of 
this.  For reasons that are too wordy to be worth the bytes, I didn't do 
it, so thanks!




Now, to the problem.  It seems that we have a consensus that client 
certificates (in a client authentication role at least) are unusable 
with the current system.  Approximately, for many reasons.


And, the way forward is more UI support [1], as suggested by Johnathan. 
 Specifically, to me at least, it seems that it would look like this:


a. For every request for a client-cert, there would be a request from 
low-level code to intermediate-level code for a key/certificate.


b. In the intermediate layer, that request would be matched against a 
list of pre-established tuples like {domain name, certificate, action, 
status}.


c.  If the typle isn't found (which means the domain name wasn't 
indexed) then the intermediate level code would pass the request up to 
the higher-layer code to ask the user (pop-up?) :


* which certificate to use (if more than one available)
* whether to accept this choice:
  + once
  + for minutes (say 30 minutes, but configurable)
  + for now (in memory, not saved to disk) [2]
  + forever (save tuple to disk).
* whether to display the client identity in use

d. The intermediate layer returns the key/cert to be used via either 
tuple matching or via user interface.  Then, once the tuple is 
set/saved, we have a good chance of transparent session restart.


How does that sound?



iang

[1] Yes, we noted that servers may be misconfigured.  But, waiting for 
the servers to be properly configured looks implausible, we might be 
waiting for a long time, and even then we won't have solved the full 
problem.  It seems fairly clear that clients will *always* have to deal 
with it, regardless.


[2] For my money, I want the for now option because I want to be 
re-asked in a few days of what's going on ... and be forced to rethink 
whether I want a long term relationship here or not.  I don't want the 
browser to store any relationship in any permanent store until I tell 
it.  That's just me...

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: client certificates unusable?


On 20/3/09 19:29, Anders Rundgren wrote:

This is a stupid comment.


Pardon me.  I just don't agree with the majority of this list since
many governments and banks in the EU are working in another
direction.  This may be due to ignorance



Folks, Anders is right about this worldview difference.  But it's not 
easy to see unless you've spent some time on the other side of the 
fence.  It is somewhat but not compeltely a cultural difference that 
derives from different attitudes to finance, regulation and trust 
whatever that is.


Having worked on both sides of the fence, I can see both perspectives, 
but it is beyond me to explain it all.  Unfortunately, the conclusions 
often end up being completely different and contradictory, so it is 
somewhat head-spinning to figure out how the different sides of the 
atlantic figured out their opposing conclusions.




but I insists that there
is a problem having *two* competing session mechanisms in
web-apps; one [IMO] may have to go.



I wonder if the point might be that only one form of auth matters, and 
once we decide which it is, the other(s) should allow itself to go passive?




The other problem is that the signature stuff that the Mozilla
community continuously downplays actually lives and this thingy



An example of this is qualified certificates.  For those on the western 
side of the Atlantic (which includes Britain :) ) these are *a big deal* 
in Europe, and they more or less set the emotional standard for where 
everything is going.  E.g., ETSI standards are written assuming QCs are 
the standard which makes them somewhat odd when considered from a 
server-auth viewpoint.




also works contra TLS-c-c-a as since you obviously shouldn't
have different PKI UIs for signatures and authentication.
We are talking about investments in the range of $100M/Y.



Pass some our way and you've got our attention ;-)

iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: client certificates unusable?

Kyle Hamilton wrote, On 2009-03-20 02:15:
 This is a stupid comment.

Then why post it?

 There are many people who think differently; I, for one, think that
 server-auth is the *worse* part of TLS (because there's no branding of
 what CA is responsible for the certification, there's no way to
 identify when a session is re-used versus renegotiated, 

Once again, you are complaining about browser UI, but you blame the TLS
protocol for your issues with browser UI.

 there's no way to figure out what CAs are available on the client for 
 multiple-certification strategies,

But it is possible to tell the client which CAs are acceptable.  The
server doesn't need to know more about the client than that it can be
authenticated with a cert acceptable to the server.

 and there's no way -- unlike IPSEC -- to require that a connecting client
 authenticate itself before the server decides to let its identity be
 known, among others).

Even if there was, I believe most browsers would refuse to implement it.
Surely I need not explain why.

 It seems pretty clear that the common case for authentication, as
 implemented by banks, utility companies, phone companies, PayPal, etc
 is to authenticate once and then let that authentication continue for
 as long as the session holds -- and by 'session' I mean a cookie
 either as a separate header or as a part of the URL -- and expire
 those sessions after 10 or 15 minutes of inactivity.

Right.  That's a session at the application layer, not a session at the
transport layer.  You're trying to bind/couple the two.  You're applying
design goals and requirements of one to the other.  You're trying to make
TLS sessions serve double duty as also being application sessions.

Doctor, it hurts when I do this.

 The most important part to remember is that *ALL OF THIS CAN BE
 CONFIGURED ON THE SERVER AT THE TLS LAYER WITHOUT THE CLIENT KNOWING
 OR SUGGESTING ANYTHING ABOUT IT*.  Sessions can be reset to 0-seconds
 idle when they're used, or not, at the server security configurator's
 whim.

Both the client and the server can impose their requirements on transport
session duration.  Either one is free to terminate the session at any time,
at will.

-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: client certificates unusable?

Ian G wrote, On 2009-03-21 12:32:
 It seems that we have a consensus that client 
 certificates (in a client authentication role at least) are unusable 
 with the current system.  Approximately, for many reasons.

Sorry, I disagree.  There are many places (companies, governments) that
use client auth every day for most of their SSL connections without any
problem.  They would not agree that it is unusable.  They do not file
bugs and they do not participate in this newsgroup.

Then, there are a set of server products that have misunderstood and
misused TLS client auth, and with those products, client auth is unusable.
Those are (mostly) freebies, so they tend to be used by amateur web site
(and mail server) admins.  Having no experience with any other products,
those folks tend to assume that the problems they have are fundamental
problems with TLS client auth, rather than bugs or poor design in the
particular free server products they've chosen to use.

The consensus of which you speak is actually a consensus among users of
those crappy servers that, with those servers, client auth is unusable.
I am part of that consensus.  But I do not agree that changing the
client to reward crappy servers is any part of the solution.  And I
vote with my wallet on all those crappy servers.  I won't use them.

 And, the way forward is more UI support [1], as suggested by Johnathan. 

And regardless of the real cause, most browser users want the browser to
change to accommodate them.  They don't want to fix the problem, they want
to fix the browser.  The browser is always the problem, in their opinion.

Servers that do not reuse TLS sessions, and force doing client auth the hard
(expensive, in CPU cost) way on every connection will never take off.
You'll recall that, for many years, the complaint about SSL/TLS was that
it was too slow, too CPU intensive, and that a server using SSL/TLS would
reach saturation at a lower transaction rate than servers that don't use
SSL/TLS.  That perception is now much less widely held, in part due to
intelligent use of SSL/TLS session caches.

Doing client auth the hard way on every connection is MUCH WORSE in CPU
cost than ordinary SSL/TLS without session reuse.  If people perceive (as
some do now) that using SSL/TLS client auth means doing a full handshake
with TWO RSA computations on every connection, they will never adopt it.
And that what some STUPID CRAPPY servers do now.  But it's unnecessary.

If the clients go along and make this crap invisible, silently causing
the servers to spend that extra CPU cost, that will GUARANTEE that SSL/TLS
client auth is forever branded as too slow and too expensive.

BTW, as I've documented before, many of these flawed servers request that
client's authenticate with a cert, but then ALWAYS drop the connection
abruptly if the client actually does try to authenticate with any cert.
It's actually impossible to use them if you attempt client auth.  So, for
them, having the client automatically and silently do client auth will
merely assure that users cannot access those crappy servers at all.
That will lead to more user complaints against the browser.

Any server problem is always blamed on the browser.  That's the oldest
lesson of the web, bar none.  But that doesn't mean that the browser
should change for every crappy server that comes along.  It's fine for
Darwinian selection to let those servers die out.  There's no need for
browsers to try to keep those crappy servers live longer.

 [ big design proposal snipped ]

 How does that sound?

Do you really imagine that those ideas have not already been considered by
the browser folks, many times, long ago?
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: client certificates unusable?

On Sat, Mar 21, 2009 at 1:11 PM, Nelson B Bolyard nel...@bolyard.me wrote:
 Kyle Hamilton wrote, On 2009-03-20 02:15:
 This is a stupid comment.

 Then why post it?

Because Anders was referring to the argument as stupid, and I was
referring to his comment as stupid.  (Sometimes, just sometimes, it
helps to mirror someone's attitudes and behaviors to get them to
realize just how inappropriate they are.  Obviously, it hasn't worked
in this case, and I apologize.)

 There are many people who think differently; I, for one, think that
 server-auth is the *worse* part of TLS (because there's no branding of
 what CA is responsible for the certification, there's no way to
 identify when a session is re-used versus renegotiated,

 Once again, you are complaining about browser UI, but you blame the TLS
 protocol for your issues with browser UI.

No, I blame the browser UI for not exposing useful details of the TLS
protocol.  The TLS protocol explicitly does not call out the handling
of server certificates: this is the realm of PKIX.  The TLS protocol
allows for re-use of a session, but there's no UI for identifying when
a session is re-used (as opposed to renegotiated).

 there's no way to figure out what CAs are available on the client for
 multiple-certification strategies,

 But it is possible to tell the client which CAs are acceptable.  The
 server doesn't need to know more about the client than that it can be
 authenticated with a cert acceptable to the server.

It's possible for the server to tell the client -- *once the server
has authenticated to the client* -- what CAs are acceptable.  It's not
possible for a client to tell a server what CAs it finds acceptable.
This perpetuates the all or nothing trust problem which has
historically prevented CAs from being removed from the root store:
there's no way for a business owner to mitigate the risk by having
multiple CA certificates, choosing which one based on what the client
states it is willing to accept.

 and there's no way -- unlike IPSEC -- to require that a connecting client
 authenticate itself before the server decides to let its identity be
 known, among others).

 Even if there was, I believe most browsers would refuse to implement it.
 Surely I need not explain why.

You are also making the assumption that TLS is *only* useful for
browsers, and *only* under the current paradigm of authentication.
IPsec requires that the client authenticate itself before the server
is required to make any reply at all; unfortunately, Comcast (and
other ISPs) filter IPsec.  This means that there's no current protocol
means to support the use-case where the client is requesting services
from a server that doesn't want to provide anonymous services, or even
announce its identity.

 It seems pretty clear that the common case for authentication, as
 implemented by banks, utility companies, phone companies, PayPal, etc
 is to authenticate once and then let that authentication continue for
 as long as the session holds -- and by 'session' I mean a cookie
 either as a separate header or as a part of the URL -- and expire
 those sessions after 10 or 15 minutes of inactivity.

 Right.  That's a session at the application layer, not a session at the
 transport layer.  You're trying to bind/couple the two.  You're applying
 design goals and requirements of one to the other.  You're trying to make
 TLS sessions serve double duty as also being application sessions.

 Doctor, it hurts when I do this.

No, the fact that client certificates are used and re-prompted for
whenever the session expires -- interrupting the user's workflow -- is
what makes this completely unsuitable.

SSL transport sessions *are a service which is provided to the upper
clients of the protocol*.  TLS session authentication was designed to
make it possible to have a secure authentication mechanism that the
upper layer could then use without having to rely on its own
username/password application authentication.  ALL services of the
lower layers are supposed to be presented as capabilities which upper
layers can exploit, otherwise what's the reason for having them?

(Even ICMP uses the services provided by IP, even though in the OSI
model IP and ICMP are supposed to be at the same layer.)

 The most important part to remember is that *ALL OF THIS CAN BE
 CONFIGURED ON THE SERVER AT THE TLS LAYER WITHOUT THE CLIENT KNOWING
 OR SUGGESTING ANYTHING ABOUT IT*.  Sessions can be reset to 0-seconds
 idle when they're used, or not, at the server security configurator's
 whim.

 Both the client and the server can impose their requirements on transport
 session duration.  Either one is free to terminate the session at any time,
 at will.

Yes.  It's just the fact that die-hard This Is The Way The Standard
Is And This Is The Way The Standard Shall Always Be
viewpoint-holders, like you, insist on relying on a paradigm which has
been shown to be fundamentally useless in the every-day usage of the
protocol.

Fifteen

Re: client certificates unusable?

I should also add:

The problem is not simply on the server's end, Nelson.  You've been
pointing at them for years.  (The DoD also doesn't use Firefox, so
they don't end up filing bugs against it anyway.)

The client was built around the same paradigm as the server.  The
client paradigm is what keeps the CAs in business, and the client
paradigm and its unwillingness to change is part of what's preventing
the adoption of client certificates on the global internet.

-Kyle H

On Sat, Mar 21, 2009 at 2:07 PM, Kyle Hamilton aerow...@gmail.com wrote:
 On Sat, Mar 21, 2009 at 1:11 PM, Nelson B Bolyard nel...@bolyard.me wrote:
 Kyle Hamilton wrote, On 2009-03-20 02:15:
 This is a stupid comment.

 Then why post it?

 Because Anders was referring to the argument as stupid, and I was
 referring to his comment as stupid.  (Sometimes, just sometimes, it
 helps to mirror someone's attitudes and behaviors to get them to
 realize just how inappropriate they are.  Obviously, it hasn't worked
 in this case, and I apologize.)

 There are many people who think differently; I, for one, think that
 server-auth is the *worse* part of TLS (because there's no branding of
 what CA is responsible for the certification, there's no way to
 identify when a session is re-used versus renegotiated,

 Once again, you are complaining about browser UI, but you blame the TLS
 protocol for your issues with browser UI.

 No, I blame the browser UI for not exposing useful details of the TLS
 protocol.  The TLS protocol explicitly does not call out the handling
 of server certificates: this is the realm of PKIX.  The TLS protocol
 allows for re-use of a session, but there's no UI for identifying when
 a session is re-used (as opposed to renegotiated).

 there's no way to figure out what CAs are available on the client for
 multiple-certification strategies,

 But it is possible to tell the client which CAs are acceptable.  The
 server doesn't need to know more about the client than that it can be
 authenticated with a cert acceptable to the server.

 It's possible for the server to tell the client -- *once the server
 has authenticated to the client* -- what CAs are acceptable.  It's not
 possible for a client to tell a server what CAs it finds acceptable.
 This perpetuates the all or nothing trust problem which has
 historically prevented CAs from being removed from the root store:
 there's no way for a business owner to mitigate the risk by having
 multiple CA certificates, choosing which one based on what the client
 states it is willing to accept.

 and there's no way -- unlike IPSEC -- to require that a connecting client
 authenticate itself before the server decides to let its identity be
 known, among others).

 Even if there was, I believe most browsers would refuse to implement it.
 Surely I need not explain why.

 You are also making the assumption that TLS is *only* useful for
 browsers, and *only* under the current paradigm of authentication.
 IPsec requires that the client authenticate itself before the server
 is required to make any reply at all; unfortunately, Comcast (and
 other ISPs) filter IPsec.  This means that there's no current protocol
 means to support the use-case where the client is requesting services
 from a server that doesn't want to provide anonymous services, or even
 announce its identity.

 It seems pretty clear that the common case for authentication, as
 implemented by banks, utility companies, phone companies, PayPal, etc
 is to authenticate once and then let that authentication continue for
 as long as the session holds -- and by 'session' I mean a cookie
 either as a separate header or as a part of the URL -- and expire
 those sessions after 10 or 15 minutes of inactivity.

 Right.  That's a session at the application layer, not a session at the
 transport layer.  You're trying to bind/couple the two.  You're applying
 design goals and requirements of one to the other.  You're trying to make
 TLS sessions serve double duty as also being application sessions.

 Doctor, it hurts when I do this.

 No, the fact that client certificates are used and re-prompted for
 whenever the session expires -- interrupting the user's workflow -- is
 what makes this completely unsuitable.

 SSL transport sessions *are a service which is provided to the upper
 clients of the protocol*.  TLS session authentication was designed to
 make it possible to have a secure authentication mechanism that the
 upper layer could then use without having to rely on its own
 username/password application authentication.  ALL services of the
 lower layers are supposed to be presented as capabilities which upper
 layers can exploit, otherwise what's the reason for having them?

 (Even ICMP uses the services provided by IP, even though in the OSI
 model IP and ICMP are supposed to be at the same layer.)

 The most important part to remember is that *ALL OF THIS CAN BE
 CONFIGURED ON THE SERVER AT THE TLS LAYER WITHOUT THE CLIENT KNOWING
 OR

Re: client certificates unusable?

2009-03-21 Thread Eddy Nigg


On 03/21/2009 09:32 PM, Ian G:

On 21/3/09 16:54, Eddy Nigg wrote:


Huu? No outcry about rudeness in mailing lists here?



Eddy, I agree that rudeness was carrying us away from the problem and 
on to the personalities.  Indeed, it's up to all of us to be be minded 
of this.  For reasons that are too wordy to be worth the bytes, I 
didn't do it, so thanks!


Well, I just thought that I'd remind you about how outraged you were 
when I said the same thingbesides that such comments were seen 
allover many times and I think it's just a funny expression. Perhaps you 
should offer to both of us some of your stuff so we'll have some fun 
together ;-)




Now, to the problem.  It seems that we have a consensus that client 
certificates (in a client authentication role at least) are unusable 
with the current system.


I think that the word unusable is far too strong. See, there are 
improvements possible and most likely should be made at various levels, 
but unusable? I can claim tens of thousands of active accounts  using 
nothing else than client certificate authentication. In the OpenID space 
I know about Verisign and some other providers offering them too - with 
StartSSL being a provider based solemnly on client cert authentication.



And, the way forward is more UI support [1], as suggested by Johnathan.


Yes, I think Johnath has a few ideas to make the UI better...

Now - long pause, deep breath - everything below which you mention 
sounds to me as if you are trying to invent client certificate 
authentication once again from scratch...well, it already exists and 
mostly works fairly well...most of it below works more or less the way 
you would like it to be...not sure what I'm missing or if you are 
missing something here...


...or perhaps indeed learn to configure your servers properly and get 
some advice on application programming, middle-ware, protocol layers and 
sessions...




a. For every request for a client-cert, there would be a request from 
low-level code to intermediate-level code for a key/certificate.


b. In the intermediate layer, that request would be matched against a 
list of pre-established tuples like {domain name, certificate, action, 
status}.


c.  If the typle isn't found (which means the domain name wasn't 
indexed) then the intermediate level code would pass the request up to 
the higher-layer code to ask the user (pop-up?) :


* which certificate to use (if more than one available)
* whether to accept this choice:
  + once
  + for minutes (say 30 minutes, but configurable)
  + for now (in memory, not saved to disk) [2]
  + forever (save tuple to disk).
* whether to display the client identity in use

d. The intermediate layer returns the key/cert to be used via either 
tuple matching or via user interface.  Then, once the tuple is 
set/saved, we have a good chance of transparent session restart.


How does that sound?



iang

[1] Yes, we noted that servers may be misconfigured.  But, waiting for 
the servers to be properly configured looks implausible, we might be 
waiting for a long time, and even then we won't have solved the full 
problem.  It seems fairly clear that clients will *always* have to 
deal with it, regardless.


[2] For my money, I want the for now option because I want to be 
re-asked in a few days of what's going on ... and be forced to rethink 
whether I want a long term relationship here or not.  I don't want the 
browser to store any relationship in any permanent store until I tell 
it.  That's just me...



--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

JSS: How to load symmetric key from NSS DB?

2009-03-21 Thread alex . agranov

I wonder how is it possible to load symmetric key that is stored
inside the NSS DB via JSS API? I tried using KeyStore JCA class (as in
org.mozilla.jss.tests.KeyStoreTest example):

  KeyStore ks = KeyStore.getInstance(Mozilla-JSS);

but it turns out that JSSProvider doesn't register JSSKeyStoreSpi
class at all and therefore Mozilla-JSS instance of KeyStore doesn't
exist.
I tried fixing this by adding the following line to JSSProvider class:

  put(KeyStore.Mozilla-JSS,
org.mozilla.jss.provider.java.security.JSSKeyStoreSpi);

But even though getKey API seemed to work fine, I got the following
exception when trying to use this key to init the cipher:

  encryptCipher.init(Cipher.ENCRYPT_MODE, key, params);

  # An unexpected error has been detected by Java Runtime Environment:
  #
  #  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x19ea4930,
pid=17900, tid=10928
  #
  # Java VM: Java HotSpot(TM) Client VM (11.2-b01 mixed mode windows-
x86)
  # Problematic frame:
  # C  [nss3.dll+0x34930]
  #
  # An error report file with more information is saved as:
  # D:\projects\yevgeniyg_EMS_5.8\TG1000\EMS\hs_err_pid17900.log
  #
  # If you would like to submit a bug report, please visit:
  #   http://java.sun.com/webapps/bugreport/crash.jsp
  # The crash happened outside the Java Virtual Machine in native
code.
  # See problematic frame for where to report the bug.
  #

So I wonder if there is some way to load symmetric key stored in the
NSS DB via JCA API?

I found the similar question in this newsgroup that is almost 2 years
old:
http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/3102368d651d5cb1/92b48da59a16a2cc?lnk=gstq=jss+keystore#92b48da59a16a2cc
- and it seems to suggest using Sun PKCS11 provider with NSS instead.
Unfortunately AFAIK one can not mix Sun PKCS11 NSS provider with JSS
in the same code - and I'm using JSS API for the rest of my
application (due to the limitations in Sun PKCS11 NSS provider) - so
this doesn't seem to be a valid alternative to me...

Thank you in advance,
Alex Agranov
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: client certificates unusable?

Kyle Hamilton wrote, On 2009-03-21 14:07:
 On Sat, Mar 21, 2009 at 1:11 PM, Nelson B Bolyard nel...@bolyard.me wrote:
 Kyle Hamilton wrote, On 2009-03-20 02:15:

 There are many people who think differently; I, for one, think that
 server-auth is the *worse* part of TLS (because there's no branding of
 what CA is responsible for the certification, there's no way to
 identify when a session is re-used versus renegotiated,

 Once again, you are complaining about browser UI, but you blame the TLS
 protocol for your issues with browser UI.
 
 No, I blame the browser UI for not exposing useful details of the TLS
 protocol.  The TLS protocol explicitly does not call out the handling
 of server certificates: this is the realm of PKIX.  The TLS protocol
 allows for re-use of a session, but there's no UI for identifying when
 a session is re-used (as opposed to renegotiated).

OK, so you've confirmed that your complaint is really about browser UI.
But above, you did not write server-auth is the worst part of the browser
UI nor browser UI for server auth is the worst part of the browser
experience with https.  You wrote that it was the worst part of *TLS*.
You're blaming TLS for browser UI.  Please try hard to write what you mean.

 [...] unfortunately, Comcast (and other ISPs) filter IPsec.  

I use IPSec through Comcast daily.

 SSL transport sessions *are a service which is provided to the upper
 clients of the protocol*.  TLS session authentication was designed to
 make it possible to have a secure authentication mechanism that the
 upper layer could then use without having to rely on its own
 username/password application authentication.  ALL services of the
 lower layers are supposed to be presented as capabilities which upper
 layers can exploit, otherwise what's the reason for having them?

Yes, I agree.  But you seem to wish that TLS implement ONE application's
idea of good session management as its sole means.  What TLS does is
define a scheme that has a configurable upper limit for session lifetime,
regardless of (in)activity, and the ability for the application at either
end to terminate any session at will, according to its own criteria.

So, the obvious way to use it is to leave the TLS session lifetime limit set
up to some high value, and have the application code terminate it
earlier, if it so desires (e.g. at the end of an application session).

The problem here is that people so desperately (or ignorantly) want the
TLS sessions to be application sessions, that they configure the TLS
sessions as if they WERE application sessions.  They configure TLS
sessions with an upper bound of a few minutes (or seconds), thinking
(or wishing) that TLS sessions are based on inactivity times.  The
solution is not to change TLS to work the way that some single application
wants its sessions to work, and it is not to misconfigure TLS sessions
with absurdly short maximum lifetimes.  That is a server problem, perhaps
a server admin problem.  It is not a browser problem.

Configuring TLS session lifetimes in the server with absurdly short maximum
lifetimes (including zero lifetimes) is THE SOLE CAUSE of all that
re-prompting for TLS client auth.  It's stupid.  To all the admins who do
that, and then whine that the browser prompts often, I repeat: Doctor,
it hurts when I do this.

 Yes.  It's just the fact that die-hard This Is The Way The Standard Is
 And This Is The Way The Standard Shall Always Be viewpoint-holders, like
 you, insist on relying on a paradigm which has been shown to be
 fundamentally useless in the every-day usage of the protocol.

Except for all those users, servers and enterprises that use it all day
every day without complaint.

 The problem is not simply on the server's end, Nelson.  You've been
 pointing at them for years.  (The DoD also doesn't use Firefox, so
 they don't end up filing bugs against it anyway.)

Actually, they do.  That's a big reason why NSS gets the funding it does.
Why do you think Suite B support went into NSS for FF2?
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: client certificates unusable?

Eddy Nigg wrote, On 2009-03-21 15:08:
 On 03/21/2009 10:43 PM, Nelson B Bolyard:
 The consensus of which you speak is actually a consensus among users of
 those crappy servers that, with those servers, client auth is unusable.
 I am part of that consensus.  But I do not agree that changing the
 client to reward crappy servers is any part of the solution.  And I
 vote with my wallet on all those crappy servers.  I won't use them.
   
 
 Wowowow.slow down a bit my dear friend. As I would defend Mr.
 Bolyard and this team elsewhere I'm going to defend Mr. Engelschall and
 his crew here...interestingly both are serving a similar community and
 work in a similar eco-system.
 
 Just for your knowledge, those crappy servers you are attacking here are
 serving the majority of web sites. The crappy server, aka A-Patchy
 server is very well tested and in use at millions of service and content
 providers.

I don't think we have a generic problem with Apache, Eddy.  Apache can be
configured to work well with client auth.  It often is not, but that's an
admin problem.

The servers of which I wrote that are configured by default to request
client auth, with server session cache disabled, and dropping all
connections that actually do client auth, are not Apache servers, AFAIK.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: client certificates unusable?

On Sat, Mar 21, 2009 at 2:58 PM, Nelson B Bolyard nel...@bolyard.me wrote:
 Kyle Hamilton wrote, On 2009-03-21 14:07:
 No, I blame the browser UI for not exposing useful details of the TLS
 protocol.  The TLS protocol explicitly does not call out the handling
 of server certificates: this is the realm of PKIX.  The TLS protocol
 allows for re-use of a session, but there's no UI for identifying when
 a session is re-used (as opposed to renegotiated).

 OK, so you've confirmed that your complaint is really about browser UI.
 But above, you did not write server-auth is the worst part of the browser
 UI nor browser UI for server auth is the worst part of the browser
 experience with https.  You wrote that it was the worst part of *TLS*.

For the sake of advancing the argument before us (and not something
personal), I will acquiesce, and simplify:

I blame TLS for some of its requirements (such as it is always a
fatal protocol_error alert for an unauthenticated server to request
authentication of the client in the TLS specifications themselves --
not simply the HTTP-over-TLS informational RFC, which is where such a
statement should be made *in relation to the browser*).

I blame NSS for choosing not to adhere to certain aspects of the SSL
3.0 and TLS 1.0 standards (accepting a ClientCertificateRequest with a
zero-length list of identifiers of acceptable CAs), enforcing others
(including the 'fatal protocol_error alert' I alluded to above) and
not exposing details (such as sessions) to its clients.  (My apology
if it does this last, and the upper-layer client just refuses to
access it.)  Since NSS is also responsible for authenticating against
the PKIX standards, and it does so, I do not have any issues with it
in that manner.  I *do*, however, blame NSS for requiring client keys
and certificates to be installed in the current user's certificate
store in order to use them.

I blame the browser UI for not usefully exposing useful details of
PKIX, TLS, and what it's doing with the users' keys and when.

I still, however, believe that server-auth is -- if not the the worst
feature of TLS -- certainly the most overhyped and misused.

 You're blaming TLS for browser UI.  Please try hard to write what you mean.

 [...] unfortunately, Comcast (and other ISPs) filter IPsec.

 I use IPSec through Comcast daily.

Interesting.  So my friend in Ann Arbor who has a 6-to-4 IPsec tunnel
should be able to use it without problems (and can't, as the tunnel
uses IPsec and is blocked), and my friend in San Jose who needed to
upgrade to a business account so that he could do work from home
(using the Cisco VPN utility) shouldn't have needed to?

Did you purchase a business account?  (This is an honest question, and
I have no political motivation to ask it -- I would simply like to
know so that I can help my friend figure out his issues.)

 SSL transport sessions *are a service which is provided to the upper
 clients of the protocol*.  TLS session authentication was designed to
 make it possible to have a secure authentication mechanism that the
 upper layer could then use without having to rely on its own
 username/password application authentication.  ALL services of the
 lower layers are supposed to be presented as capabilities which upper
 layers can exploit, otherwise what's the reason for having them?

 Yes, I agree.  But you seem to wish that TLS implement ONE application's
 idea of good session management as its sole means.  What TLS does is
 define a scheme that has a configurable upper limit for session lifetime,
 regardless of (in)activity, and the ability for the application at either
 end to terminate any session at will, according to its own criteria.

Alright, fair point.  I am (and have been) looking at it from the view
of a single webserver providing a single service.  I realize that
there are other implementations in production -- for example,
https://documents.google.com/a/domainnamethatusesit.com, with many
different domains that use that same hostname.

 So, the obvious way to use it is to leave the TLS session lifetime limit set
 up to some high value, and have the application code terminate it
 earlier, if it so desires (e.g. at the end of an application session).

This wouldn't particularly work in the Google case above, either.  (I
use both a private-domain google documents store and my public gmail
account for a google documents store.)  Particularly if the session
has to ask, every time it wants to switch credentials, what
certificate to use for it.

 The problem here is that people so desperately (or ignorantly) want the
 TLS sessions to be application sessions, that they configure the TLS
 sessions as if they WERE application sessions.  They configure TLS
 sessions with an upper bound of a few minutes (or seconds), thinking
 (or wishing) that TLS sessions are based on inactivity times.  The
 solution is not to change TLS to work the way that some single application
 wants its sessions to work, and it is

Re: client certificates unusable?


On 21/3/09 21:43, Nelson B Bolyard wrote:

Ian G wrote, On 2009-03-21 12:32:

It seems that we have a consensus that client
certificates (in a client authentication role at least) are unusable
with the current system.  Approximately, for many reasons.


Sorry, I disagree.  There are many places (companies, governments) that
use client auth every day for most of their SSL connections without any
problem.  They would not agree that it is unusable.  They do not file
bugs and they do not participate in this newsgroup.



I'm afraid I disagree with this, too!  Nor are they Mozilla's heartland. 
 I'm sure they do a good job 'n all, but I and most volunteers (I hope) 
are concerned about Mozilla delivering product for the world. 
Corporations  governments pay their sysadms to work long and hard to 
get it all up and going.  When they've got a real problem, they employ 
programmers to fix the code and submit patches.  Or they buy product 
from suppliers like Microsoft.


Ordinary users do not have that luxury.

Unless we can get the mission of Mozilla changed to ditch the end-user 
and concentrate on government  corporate markets, I'm of the opinion 
the corps and govts of the world are big enough and ugly enough to look 
after themselves.  Who speaks for the rest?




Then, there are a set of server products that have misunderstood and
misused TLS client auth, and with those products, client auth is unusable.
Those are (mostly) freebies, so they tend to be used by amateur web site
(and mail server) admins.  Having no experience with any other products,
those folks tend to assume that the problems they have are fundamental
problems with TLS client auth, rather than bugs or poor design in the
particular free server products they've chosen to use.

The consensus of which you speak is actually a consensus among users of
those crappy servers that, with those servers, client auth is unusable.
I am part of that consensus.  But I do not agree that changing the
client to reward crappy servers is any part of the solution.  And I
vote with my wallet on all those crappy servers.  I won't use them.



I don't know about these things, but I recognise that badly configured 
servers are a pain.  The servers I have experienced this with are 
Apache.  They may be misconfigured, but the sysadms aren't agreeing at 
the moment, and talking about the sysadms being bad isn't going to 
help;  they are no better nor worse than the other ones I've known.


And even when the Apache config is fixed, this is just the server-side 
workaround.  This only means I have to hit a pop-up once every day, it 
doesn't solve the fundamental problem:  I want to use cert X speaking to 
server Y.  And I want that written down, stuck in the browser's mind. 
Fixing the server does not make that so.


...


If the clients go along and make this crap invisible, silently causing
the servers to spend that extra CPU cost, that will GUARANTEE that SSL/TLS
client auth is forever branded as too slow and too expensive.



Surely that's perfect for us?   If the clients cause the server that 
pain, the server admins will ask around as to why their servers are so 
slow, and be told the obvious:  Just reconfig your server to have a 
longer timeout on session, Dude!


If they can't ask around about that, then I agree that we have big 
problems in server-land ... they certainly won't notice that the users 
are not using client certs because of all the popups.




Any server problem is always blamed on the browser.  That's the oldest
lesson of the web, bar none.



It's pre-web, and I'm afraid it's actually pre-computing.  The stuff 
that is closest to the user always takes the blame.  It's just a truism 
of all business.  Mozilla could easily solve this issue by getting out 
of browsers and into servers ;-)




Do you really imagine that those ideas have not already been considered by
the browser folks, many times, long ago?



Hmmm, well, many questions abound:  why wasn't it done?  where was this 
discussed?  Why didn't client certs just happen?  Why are we still using 
passwords?




iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: client certificates unusable?

2009-03-21 Thread Eddy Nigg


On 03/22/2009 12:26 AM, Ian G:
Right, the problem perhaps is better expressed that some of these 
comments *aren't written with emoticons at the end* so it is not easy 
for those from diverse cultures to figure out the joke.  Oh, and I 
save my stuff for those that appreciate fine red wine ;-)


A, at last you are talking, men! :-)

I could offer you also a fine collection, but I'm on duty right now, so 
we have to do that later...




I agree that unusable is strong, even debatable.

I suspect those who have got it working have either clicked on the 
button that says present always, or they are working in a strict 
corporate or government environment where local solutions can develop 
(which Nelson pointed to).  Or perhaps it is OpenId and the answer is 
we must all adopt that?


No, nothing of the above (except that Firefox is now configured to 
always ask). But why don't you check it out yourself? I guess you don't 
need the specific URL from me to find the site I'm talking about ;-)


OpenID and client certs are a great combination. You can test it at the 
various StartSSL sites (they authenticate via OpenID to each other).




Either way, it seems as though all those caveats have problems: 
Clicking the button cannot be recommended because it is a privacy risk.


??? Except if you intend to do that, don't you? The issue was previously 
when a server asked for a cert and was willing to accept any cert and 
the browser just sent one over without notifying the user...this has 
been fixed by now...




Corporate/ government is fine, but that's not Mozilla, that's 
Microsoft;  wrong list, sorry.  OpenID?  What's that, and what's wrong 
with client certs *as client certs*?  Etc etc.


I'm willing to make an introduction, but this is the wrong list too...



Good.  Er, are you saying we should just let him get on with it, 
without discussion here?  If we're all cool with that, that's fine by 
me, we can take it offline ;-)


I think that once he is ready we should voice our opinion. So far he has 
produced some nice things IMO and I'm very interested to see what he's 
up to...besides that he's listening here too...




Super.  Point me to it.  Where in my UI do I get it to work mostly 
well ... as you say, it must be there, I just need the way to find it?


I am certainly missing this.  Please, tell us where it is?  How do I 
set the use cert X with site Y always feature?


Mmmhh, I don't want that feature (for myself) since I have to use 
different certs for different rules and tasks on the same sites 
sometimes...but in order to get a good feeling, why don't you heed my 
advice and check it out? Perhaps you'll see a good thing or two on the 
way ;-)




*I* don't have the servers, and therefore I can only follow Nelson's 
advice and complain.  Guess what, they ignore the complaints, coz it 
works for them.  Also, I want a solution for all of Mozilla's 150m 
users, not yet another hate campaign against the server people, who 
haven't forgiven me for the last one.  Some advice on application 
programming ... lol, gee, if that worked we wouldn't be where we are 
now:  99% dependent on the good old password.


Lets go step by step...tell me if what I have to offer works for you and 
then lets talk...(perhaps also off-list)


--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: client certificates unusable?

2009-03-21 Thread Eddy Nigg


On 03/22/2009 12:55 AM, Ian G:
I don't know about these things, but I recognise that badly configured 
servers are a pain.  The servers I have experienced this with are 
Apache.  They may be misconfigured, but the sysadms aren't agreeing at 
the moment, and talking about the sysadms being bad isn't going to 
help;  they are no better nor worse than the other ones I've known.


Now I have to disagree strongly with you. Servers must be configured no 
matter what. No server comes with a correctly installed server 
certificate for example, nor is a server tuned to serve your specific 
content. Server MUST be configured otherwise they don't 
workincluding client cert auth. Incidentally your sys admin must 
have configured the server in question to request client cert auth 
because NO server asks for client certificates in their default 
configuration...so give me a break and kick your sys admin... (most 
likely he doesn't have a clue about what he is doing, but that's another 
story I guess)




And even when the Apache config is fixed, this is just the 
server-side workaround.


LOL...a misconfiguration server will ALWAYS make you problems...any 
misconfigured software will. This is not a work-around, in your 
situation it's most likely THE solution.



  This only means I have to hit a pop-up once every day, it doesn't 
solve the fundamental problem:  I want to use cert X speaking to 
server Y. 


It's the other way around, but I can offer you support for a reasonable 
fee to have your server configured accordingly...


Do you really imagine that those ideas have not already been 
considered by

the browser folks, many times, long ago?



Hmmm, well, many questions abound:  why wasn't it done?  where was 
this discussed?  Why didn't client certs just happen?  Why are we 
still using passwords?




Good questionit's because it's so much more convenient and everybody 
is doing it...but guess what, some thought leaders and some leading 
projects are working on having that changed.


But there is indeed no logic to defend Paypal and your bank with XYZ 
measures as long as they use useless user/pass pairs. But in the end of 
the day it's all a question of risk assessment and the price you are 
willing to pay and that of the insurance. Once that price goes up there 
are viable solutions like client certs...


--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: client certificates unusable?

Ian G wrote, On 2009-03-21 15:55:

 I don't know about these things, but I recognise that badly configured 
 servers are a pain.  The servers I have experienced this with are 
 Apache.  They may be misconfigured, but the sysadms aren't agreeing at 
 the moment, and talking about the sysadms being bad isn't going to 
 help;  they are no better nor worse than the other ones I've known.

There are many web pages out there that are cookbooks for how to set up
servers to do this and that.  Many of them are full of errors, but to
other server admins, these cookbooks are treated like Gospels.  When the
cookbook formula doesn't work well, the admins don't say Dude, your
cookbook sucks.  They say those browsers sure suck.

 And even when the Apache config is fixed, this is just the server-side 
 workaround.  This only means I have to hit a pop-up once every day, it 
 doesn't solve the fundamental problem:  I want to use cert X speaking to 
 server Y.  And I want that written down, stuck in the browser's mind. 
 Fixing the server does not make that so.

I agree that the user should not need to make that choice every day.
He should be able to do so, and should be able to change his configuration
easily any day, but he should not need to do that daily.  There are RFEs
about this, some for browsers, some for Thunderbird.

Here's the TB RFE: https://bugzilla.mozilla.org/show_bug.cgi?id=437683
BTW, this client auth problem is MUCH MUCH worse for Thunderbird users than
for browser users, because evidently a higher percentage of free email
servers are crap.

I'll have to dig a bit more for the FF one.  I think there's more than one
for FF.

 If the clients go along and make this crap invisible, silently causing
 the servers to spend that extra CPU cost, that will GUARANTEE that SSL/TLS
 client auth is forever branded as too slow and too expensive.
 
 Surely that's perfect for us?   

Uh, N...

 If the clients cause the server that pain, the server admins will ask
 around as to why their servers are so slow, and be told the obvious:
 Just reconfig your server to have a longer timeout on session, Dude!

No, they'll ask around and hear I don't know, Dude, we're following the
cookbook so those browsers must be crap.  Group think.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: client certificates unusable?

On Sat, Mar 21, 2009 at 4:32 PM, Eddy Nigg eddy_n...@startcom.org wrote:
 On 03/22/2009 12:55 AM, Ian G:
 Hmmm, well, many questions abound:  why wasn't it done?  where was this
 discussed?  Why didn't client certs just happen?  Why are we still using
 passwords?


 Good questionit's because it's so much more convenient and everybody is
 doing it...but guess what, some thought leaders and some leading projects
 are working on having that changed.

Because the means of configuration isn't easy on the server side.
Because it means having to manually put the certs that one wants to
allow to authenticate other certs in the server configuration
directories.  (Note that various versions of TLS allow for sub-CAs to
be explicitly named in the ClientCertificateRequest, rather than their
roots.  I am going to assume that Nelson knows more on this topic than
I do, because I've been wrong with which versions allowed for what.)
Because the server is hard to configure to do CRLs and/or OCSP.
Because the CRL still needs to be fetched, usually as a cron job.
Because the server still needs to maintain its own local database of
accepted/trusted users.
Because there's no guarantee that a Subject will remain the same
Subject, so there's no easy way to map a Subject to a local user.
Because there's no guarantee that a Subject is the same as another
Subject based on CN or any other individual part of a Subject, so
there's no easy way to protect privacy using only portions of the
Subject.

The problem isn't just on the server side, it's not just on the client
side, it's also on the CA side.  The CA/B forum should have brought
Server vendors into the mix, too, to explain their plights.

-Kyle H
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: client certificates unusable?

Kyle Hamilton wrote, On 2009-03-21 15:49:
 On Sat, Mar 21, 2009 at 2:58 PM, Nelson B Bolyard nel...@bolyard.me wrote:

 I blame NSS for choosing not to adhere to certain aspects of the SSL
 3.0 and TLS 1.0 standards (accepting a ClientCertificateRequest with a
 zero-length list of identifiers of acceptable CAs), enforcing others
 (including the 'fatal protocol_error alert' I alluded to above) 

NSS did enforce that for a long time, but then certain misconfigured servers
began, in large numbers, to request client auth without sending
and issuer names, and browsers simply stopped working with those servers.
So, NSS was changed to forgive that error.  There seemed to be no down
side to doing so.  On behalf of the NSS team, I supported the change in
TLS 1.1 to allow zero length lists of issuer names.

 I *do*, however, blame NSS for requiring client keys and certificates to
 be installed in the current user's certificate store in order to use
 them.

NSS requires them to be in some (any) device (could be virtual) that is
accessible through the PKCS#11 API.  Remember that NSS can use certs and
keys from ANY PKCS#11 software module, including those that make the OS's
native cert/key store appear to be a PKCS#11 token.  There's a PKCS#11
module that looks in the computer's on-board TPM chip.  There's even a
PKCS#11 module that looks in a directory of PEM files.

NSS offers a capable and secure means of storage of keys and certs, and
offers an extensible API through which any other scheme you can name can be
plugged in.

Now, is your complaint still valid?  Or have you merely not yet availed
yourself of the available solutions?

 I still, however, believe that server-auth is -- if not the the worst
 feature of TLS -- certainly the most overhyped and misused.

You mean, most ignored by users?  Absolutely.  Most users always blindly
assume that they're connected to the server they want to be connected to.
They have no CONCEPT of MITM in their heads.  They cannot imagine that the
server to which they're talking would be an attacker's.  They're the ones
who say I don't need authentication, only encryption. They'll type their
user name and password into any screen from any server, which is exactly why
phishing exists.

That's also why user identification and authentication schemes -- wherein
the info that the user presents to the remote server CANNOT be used by that
server to impersonate the user -- are SO important.
SSL client auth is such a scheme.

 Interesting.  So my friend in Ann Arbor who has a 6-to-4 IPsec tunnel
 should be able to use it without problems (and can't, as the tunnel
 uses IPsec and is blocked), and my friend in San Jose who needed to
 upgrade to a business account so that he could do work from home
 (using the Cisco VPN utility) shouldn't have needed to?

I suspect so.  I use the Cisco VPN utility from home on my ordinary home
Comcast cable modem in a suburb of San Jose.  I think Comcast customer
service reps may be too quick to up sell users who have problems to the
more expensive accounts.  It's also possible that Comcast doesn't operate
uniformly in all markets.

 Alright, fair point.  I am (and have been) looking at it from the view
 of a single webserver providing a single service.  

Didn't you recently accuse me of that?

 I realize that there are other implementations in production 

If one looks at the number of different products that use SSL/TLS, and
counts each product as one (counting products, not instances of products)
browsers and web servers are a small percentage of the total applications
that use SSL/TLS.  That's also true of the products that use NSS.
It's very common to use SSL/TLS between servers, acting as clients, and
other servers.  In such applications of SSL, (in)activity based session
lifetimes are unwanted.  NSS is useful to all of those classes of products.

 This wouldn't particularly work  [...] Particularly if the session
 has to ask, every time it wants to switch credentials, what
 certificate to use for it.

NSS supports having multiple simultaneous sessions between a client and
a server, each bearing different credentials.

 The problem here is that people so desperately (or ignorantly) want the
 TLS sessions to be application sessions, that they configure the TLS
 sessions as if they WERE application sessions.  They configure TLS
 sessions with an upper bound of a few minutes (or seconds), thinking
 (or wishing) that TLS sessions are based on inactivity times.  The
 solution is not to change TLS to work the way that some single application
 wants its sessions to work, and it is not to misconfigure TLS sessions
 with absurdly short maximum lifetimes.  That is a server problem, perhaps
 a server admin problem.  It is not a browser problem.
 
 Is it?  Or is it something that, like the CA/B forum, needs a S/B forum?  

If TLS was a standard only for browsers and web servers, then browsers and
web server representatives could get together and define to work just

Re: client certificates unusable?

Ian G wrote, On 2009-03-21 07:00:
 After MITB surfaced (and scared the European bankers into action) 

What is that?  Man In The Bank?
I suppose you meant MITM, but if not, please clarify.

 people in finance circles started to realise that session authentication
 was a mistake from the beginning 

I would say there is not consensus on that view, but maybe I don't hang
out with enough European bankers.

 (and that SSL was the vector for that mistake).

I think that paradigm goes back much farther than SSL.  Certainly SSL
continues it.

 TLS plays no part in that, or, you are right that the part it plays is 
 that of the culprit;  distracting attention from the real security needs 
 by imposing its security model.

Where does TLS impose on anyone?
Who says Use TLS and nothing else or you'll be sorry ?
TLS offers something that is much more secure than plain text.  If some
group wants something else, they're free to design and implement it.

The problem has been that people who wanted a different model kept
wishing SSL had the model they wanted, and hating SSL for not having
the model they wanted, rather than inventing the thing they wanted.
TLS does not hold them back, except perhaps psychologically.

 Getting back to the cheap end of the market, right, some of us are 
 still trying to extract value by getting TLS to the always-on and 
 dual-authentication status.  Only then can it deliver real value up to 
 the application, rather than open up weaknesses in other areas.  For 
 this, client certs seem to be useful, because the code is already 
 written in the server side.

And the bad ones remind us of that, every minute or two.  :)

-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: client certificates unusable?

Kyle Hamilton wrote, On 2009-03-21 16:51:
 On Sat, Mar 21, 2009 at 4:32 PM, Eddy Nigg eddy_n...@startcom.org wrote:
 On 03/22/2009 12:55 AM, Ian G:
 Hmmm, well, many questions abound:  why wasn't it done?  where was
 this discussed?  Why didn't client certs just happen?  Why are we
 still using passwords?

 Good questionit's because it's so much more convenient and
 everybody is doing it...but guess what, some thought leaders and some
 leading projects are working on having that changed.
 
 Because the means of configuration isn't easy on the server side.

That's largely up to the server's admin tools right?
Some make it much easier than others.

 Because it means having to manually put the certs that one wants to
 allow to authenticate other certs in the server configuration
 directories.  

Yes, the server needs to be configured to know which issuers it should
trust as issuers for client certs.  Putting those trusted issuer certs
in a directory is actually one of the easier ways to do it.

 (Note that various versions of TLS allow for sub-CAs to
 be explicitly named in the ClientCertificateRequest, rather than their
 roots.  I am going to assume that Nelson knows more on this topic than
 I do, because I've been wrong with which versions allowed for what.)

There are client implementations that will only send a client cert if the
issuer name in the client cert itself is one of the issuer names in the
CertificateRequest message.   These tend to be found in small devices
like cell phones. With those, the CertificateRequest message must specify
the immediate issuer of the client cert, and not a higher level root,
unless that root is the immediate issuer.

There are client implementations that will send a client cert if the name
of any issuer in that client cert's chain is found in the CertificateRequest
message.  With those, the server can specify the names
of intermediate CAs and/or roots, as it wishes.  NSS is like that.

I don't know of any implementation that requires that the issuer name sent
in the CertificateRequest message must be a root.

 Because the server is hard to configure to do CRLs and/or OCSP.
 Because the CRL still needs to be fetched, usually as a cron job.

Some NSS-based server products handle automatic periodic downloading
of CRLs from the trusted client cert issuers.

 Because the server still needs to maintain its own local database of
 accepted/trusted users.

But that's no different with SSL client auth than with name+password auth.
Any way you do it, the server has to know who is authorized and who isn't
and that info has to be stored somewhere somehow.

 Because there's no guarantee that a Subject will remain the same
 Subject, so there's no easy way to map a Subject to a local user.

I'd say that, whether the subject name changes or not, there is
typically a need to map cert subject names to local identities.

Some server products have all that mapping built in and offer admin
tools to ease that administration.

 Because there's no guarantee that a Subject is the same as another
 Subject based on CN or any other individual part of a Subject, so
 there's no easy way to protect privacy using only portions of the
 Subject.

Well, if you accept all certs from all well known CAs as client certs,
and allow your users to change CAs as they wish, then yes, that's true.

In most corporate environments, there is just one CA that is used for
issuing client certs (typically run in house) and they have an agreement
with that CA which specifies a particular attribute in the subject name that
will be used as the short hand identity, such as (say) employee number.

But generalized cert mapping solves this.

 The problem isn't just on the server side, it's not just on the client
 side, it's also on the CA side.  The CA/B forum should have brought
 Server vendors into the mix, too, to explain their plights.

Each server is likely to have its own definitions of all these things.
There isn't one single schema that will satisfy everyone.  That's true
even outside of SSL client auth.  Just look at OpenID.

 -Kyle H
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: client certificates unusable?