ks in advance.
--
View this message in context:
http://old.nabble.com/Detect-SSL-client-authentication-tp32642873p32642873.html
Sent from the Mozilla - Cryptography mailing list archive at Nabble.com.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinf
"Konstantin Andreev" wrote in message
news:qvgdnspmvaho3hvrnz2dnuvz_jsdn...@mozilla.org...
On 08/28/10 02:36, Michael Smith wrote:
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
On Sep 7, 6:55 am, Konstantin Andreev wrote:
> On 08/28/10 02:36, Michael Smith wrote:
>
> > 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
On Sep 3, 11:53 am, Nelson B Bolyard wrote:
> On 2010-08-30 11:04 PDT, Michael Smith wrote:
>
> > On Aug 28, 10:08 am, Nelson Bolyard
> > wrote:
> >> What is the real underlying objective of this?
> >> Is it to authenticate the individual user of the product to the servers?
> >> Is it to ensure t
On 08/28/10 02:36, Michael Smith wrote:
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 w
On 2010-08-30 11:04 PDT, Michael Smith wrote:
> On Aug 28, 10:08 am, Nelson Bolyard
> wrote:
>> What is the real underlying objective of this?
>> Is it to authenticate the individual user of the product to the servers?
>> Is it to ensure that the client applications of the network service are
>>
cation, and to prevent others (even if the _user_ is
appropriately authenticated with username/password) from accessing the
servers.
i.e. Standard HTTP authentication is used to authenticate the user,
and an SSL client certificate is used to authenticate the application
binary. This is why I
On 2010-08-27 16:48 PDT, Michael Smith wrote:
> We're not really looking for a "couldn't be compromised" solutions -
> this is a requirement from a company we're partnering with, not our
> idea, and they basically just want it to not be "simple" (for some
> value of that) to compromise. So: serial
On Aug 27, 4:30 pm, John Dennis wrote:
> On 08/27/2010 06:36 PM, Michael Smith wrote:
>
>
>
> > 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 c
On 08/27/2010 06:36 PM, Michael Smith wrote:
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 certific
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 n
On 26/03/10 19:04, Kai Engert wrote:
thanks a lot for your feedback. I've created a graphical presentation
for the client authentication part:
http://kuix.de/mozilla/sslauth/cli-v1-pres/
I still haven't had a chance to look at this :-(( I'm very sorry.
(I do have a good excuse, though:
http:/
On 26.03.2010 13:44, Gervase Markham wrote:
The basic idea is to show an indicator in chrome whenever a site asks
for client authentication, and give the user full control over using a
personal certificate for authentication (or not using one). The
interface should also support persistent confi
, March 28, 2010 15:16
Subject: Re: Improving SSL client auth and bad certificate reporting
innon-browser applications
On 28.03.2010 06:19, Nelson B Bolyard wrote:
> The sequence of events in the dialog is likely, IMO, to give the users the
> impression that client authentication is a us
On 28.03.2010 06:19, Nelson B Bolyard wrote:
The sequence of events in the dialog is likely, IMO, to give the users the
impression that client authentication is a user-initiated act, rather than
a server initiated act. It seems to say to the user, "if you want to
authenticate to this server with
On 2010-03-26 12:04 PST, Kai Engert wrote:
> On 26.03.2010 13:44, Gervase Markham wrote:
>> I've been looking at your documents, but I do think this is a case where
>> a picture is worth a thousand words. Do you have any plans to provide UI
>> mockups?
>
> Hi Gerv,
>
> thanks a lot for your feedb
On 03/26/2010 10:04 PM, Kai Engert:
On 26.03.2010 13:44, Gervase Markham wrote:
I've been looking at your documents, but I do think this is a case where
a picture is worth a thousand words. Do you have any plans to provide UI
mockups?
Hi Gerv,
thanks a lot for your feedback. I've created a g
On 26.03.2010 13:44, Gervase Markham wrote:
I've been looking at your documents, but I do think this is a case where
a picture is worth a thousand words. Do you have any plans to provide UI
mockups?
Hi Gerv,
thanks a lot for your feedback. I've created a graphical presentation
for the client
Hi Kai,
I've been looking at your documents, but I do think this is a case where
a picture is worth a thousand words. Do you have any plans to provide UI
mockups?
On 16/03/10 23:12, Kai Engert wrote:
In short, we'd like to stop the current prompts and implement a better
user interface.
I t
uot; I'm not proposing any new protocols.
My proposal covers user interface enhancements and application behavior,
related to the existing SSL client auth and server auth protocols.
(Should "foaf+ssl" require that a user actively manages and selects
personal client auth certs whe
Kai,
Is your proposal or Aza Raskin's proposal similar to the proposal that
Henry Story of the "foaf" project has been advocating?
Wan-Teh
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
On 03/17/2010 01:12 AM, Kai Engert:
I'd like to announce two design documents.
The primary intention is to improve the functionality of SSL client
authentication in Mozilla software.
In short, we'd like to stop the current prompts and implement a better
user interface.
Excellent
I'd like to announce two design documents.
The primary intention is to improve the functionality of SSL client
authentication in Mozilla software.
In short, we'd like to stop the current prompts and implement a better
user interface.
The basic idea is to show an indicator in chrom
On 07/10/2009 13:24, Eddy Nigg wrote:
On 10/07/2009 07:25 AM, Kyle Hamilton:
Your comments suggest to me that NSS (and Firefox) *should not* be
enforcing any checks on the certificates, other than noting that
they're expired or revoked to the user in the certificate selection
dialog. If it has o
On 10/07/2009 01:24 PM, Eddy Nigg:
Most funny is, when you don't want to chose any of the certificates
for authentication and you hit "Cancel" Firefox nevertheless decides
to sent a "Go new cert" message. But it's so brain-dead today, when
you want to try it again and you had by mistake the d
On 10/07/2009 07:25 AM, Kyle Hamilton:
Your comments suggest to me that NSS (and Firefox) *should not* be
enforcing any checks on the certificates, other than noting that
they're expired or revoked to the user in the certificate selection
dialog. If it has only one certificate that matches the i
My apologies, I thought we were discussing the alert protocol in
general, as relates to TLS and how to tell the client what's going on,
not specifically Firefox's/NSS's behavior. It's important to get an
understanding of what's going on before trying to decide whether any
change is necessary. I'm
On 10/07/2009 02:04 AM, Kyle Hamilton:
There is absolutely *NO*
requirement that the client send a currently-valid certificate, and
it's up to the server to detect that.
E, btw, that's not entirely correct because the client does perform
many checks. Obviously SHOULD the client send so
Kyle, what you apparently don't seem to get here is, that users of
Firefox (but also other browsers) experience the most difficulties
BEFORE the browser even tries to send anything. The browser doesn't say
"Hey listen buddy, this server wants that you authenticate with a
client certificat
If there's no client certificate, either "access_denied",
"bad_certificate", or "certificate_unknown". (I'd suggest the first,
since without a certificate you won't grant access.)
Your TLS implementation *can* check the status of the certificate
before it's even ever passed to the application lay
On 10/06/2009 08:44 PM, Kyle Hamilton:
On Mon, Oct 5, 2009 at 11:38 AM, Eddy Nigg wrote:
I don't think anyone is doubting that both FF and IE have some problems
with the way they handle client auth. Most of these problems can be
worked around on the server (use request, not require, throug
On Mon, Oct 5, 2009 at 11:38 AM, Eddy Nigg wrote:
>> I don't think anyone is doubting that both FF and IE have some problems
>> with the way they handle client auth. Most of these problems can be
>> worked around on the server (use request, not require, through an error
>> page if the cert you wa
On 10/06/2009 12:48 AM, Robert Relyea:
This is the default settings.
Hasn't been for over a year now...
https://bugzilla.mozilla.org/show_bug.cgi?id=295922
Oh, sorry, that's my mistake, I meant the remember flag.
It's not an unreasonable work around, and probably your best choice i
On 10/05/2009 11:38 AM, Eddy Nigg wrote:
> Thanks Bob,
>
> On 10/05/2009 07:39 PM, Robert Relyea:
>> FF does not just resend the same certificate unless you have 'Select
>> Automatically' turned on.
>>
>
> This is the default settings.
Hasn't been for over a year now...
https://bugzilla.mozill
Thanks Bob,
On 10/05/2009 07:39 PM, Robert Relyea:
FF does not just resend the same certificate unless you have 'Select
Automatically' turned on.
This is the default settings.
I don't think anyone is doubting that both FF and IE have some problems
with the way they handle client auth. Mo
On 10/04/2009 08:57 PM, Eddy Nigg wrote:
> On 10/05/2009 05:49 AM, Eddy Nigg:
>>
>> So the server sent a nice error page as you say, most browsers
>> including Firefox and Explorer will have to be completly restarted in
>> order to authenticate again. Or the servers session is set to a very
>> shor
On 05/10/2009 01:24, Peter Djalaliev wrote:
It is our standard security nightmare. Side A thinks it is Side B's
problem. Side B thinks it is Side A's problem. In the meantime the
user doesn't use the tech because it doesn't work, and the sides are too
busy arguing to solve the problem. So z
On 10/05/2009 05:49 AM, Eddy Nigg:
So the server sent a nice error page as you say, most browsers
including Firefox and Explorer will have to be completly restarted in
order to authenticate again. Or the servers session is set to a very
short time like 10 seconds, which has other drawback's p
On 10/05/2009 05:40 AM, Eddy Nigg:
If the browser has no cert to send,
it sends a "I have no cert" message.
And what exactly do you expect the server should return in that case?
Probably that you can't authenticate without a certificate...it's
about as lame
It's entirely up to the
On 10/05/2009 05:13 AM, Nelson B Bolyard:
Eddy,
We're talking about the status of the client cert, not the server cert.
Yes, exactly!
The client doesn't do a validity check on its own cert before using it.
Really? Do me a favor and perform a few tests against the StartSSL
authentic
On 2009-10-04 19:55 PDT, Eddy Nigg wrote:
> On 10/05/2009 03:41 AM, Nelson B Bolyard:
>> That's not true. It's likely true for some servers, but not for SWS.
>>
>> And, in any case, the case where the browser has no cert to send is not
>> one of the cases described by the original poster.
>
> Wel
On 10/05/2009 03:41 AM, Nelson B Bolyard:
That's not true. It's likely true for some servers, but not for SWS.
And, in any case, the case where the browser has no cert to send is not
one of the cases described by the original poster.
Well, there is no difference in the reporting by Firefo
On 2009-10-04 13:37 PDT, Eddy Nigg wrote:
> On 10/04/2009 09:23 PM, Nelson B Bolyard:
>> On 2009-10-03 15:52 PDT, Jereme Bulzor wrote:
>>
>>> I've enabled client authentication in Sun One Web Server 6.1 and it does
>>> work fine when the client certificate is valid.
>>> I would like to present t
On Sun, Oct 4, 2009 at 2:30 PM, Ian G wrote:
> On 04/10/2009 22:37, Eddy Nigg wrote:
>>
>> On 10/04/2009 09:23 PM, Nelson B Bolyard:
>>>
>>> On 2009-10-03 15:52 PDT, Jereme Bulzor wrote:
>>>
I've enabled client authentication in Sun One Web Server 6.1 and it does
work fine when the clien
> It is our standard security nightmare. Side A thinks it is Side B's
> problem. Side B thinks it is Side A's problem. In the meantime the
> user doesn't use the tech because it doesn't work, and the sides are too
> busy arguing to solve the problem. So zero security is delivered.
>
> In this
> So this could be re-written: Is there something we can do for browsers
> to show something more enlightening than
> "ssl_error_handshake_failure_alert" when seeing this common error?
>
Yes. The bad news is that the "something we can do" is very browser
specific.
In the case of Mozilla Firefo
On 04/10/2009 22:37, Eddy Nigg wrote:
On 10/04/2009 09:23 PM, Nelson B Bolyard:
On 2009-10-03 15:52 PDT, Jereme Bulzor wrote:
I've enabled client authentication in Sun One Web Server 6.1 and it does
work fine when the client certificate is valid.
I would like to present the user with a good er
On 10/04/2009 09:23 PM, Nelson B Bolyard:
On 2009-10-03 15:52 PDT, Jereme Bulzor wrote:
I've enabled client authentication in Sun One Web Server 6.1 and it does
work fine when the client certificate is valid.
I would like to present the user with a good error message instead of the
generic o
On 2009-10-03 15:52 PDT, Jereme Bulzor wrote:
> I've enabled client authentication in Sun One Web Server 6.1 and it does
> work fine when the client certificate is valid.
> I would like to present the user with a good error message instead of the
> generic one when his certificate is not valid.
> I
On 10/04/2009 07:45 AM, Meena Vyas:
Please ask Sun Web Server related questions in forum
http://forums.sun.com/forum.jspa?forumID=759
This is a Firefox issue, not a server-side problem. Here is a tracking
bug with many different bugs regarding client authentication:
https://bugzilla.mozill
Please ask Sun Web Server related questions in forum
http://forums.sun.com/forum.jspa?forumID=759
Subject:
How to display the cause of an SSL client authentication failure
From:
"Jereme Bulzor"
Date:
Sun, 4 O
Hi all,
I've enabled client authentication in Sun One Web Server 6.1 and it does
work fine when the client certificate is valid.
I would like to present the user with a good error message instead of the
generic one when his certificate is not valid.
In this case, the user has currently no clue o
Nelson B Bolyard wrote:
tstclnt is able to support protocols in which the client speaks first,
and protocols in which the server speaks first. By default, it supports
protocols in which the server speaks first. To make it support protocols
in which the client speaks first, use the -f command li
David Stutzman wrote, On 2009-02-23 08:00:
> Using NSS 3.12.2 RTM or NSS 3.11.4 RTM, I get:
> org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed:
> (-12286) Cannot communicate securely with peer: no common encryption
> algorithm(s).
> Stepping back and eliminating JSS, I get simi
I'm scratching my head here...I'm trying to connect to an SSL server
with a full EC chain using a JSS SSLSocket.
Using NSS 3.12.2 libs taken from my Firefox 3.0.6 install I get:
org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed:
(-5978) Network file descriptor is not connected.
Anders Rundgren wrote:
> on the URL http://demo.webpki.org/mozkeygen
> you can get yourself a certificate by clicking a single button.
>
> What is a bit hard to understand is why the test-service at
> https://www.apache-ssl.org/cgi/cert-export
> often (but not always!) asks the user multiple times
l 01, 2008 22:39
Subject: Re: Erratic SSL client-cert-auth in FireFox
Anders Rundgren wrote:
> on the URL http://demo.webpki.org/mozkeygen
> you can get yourself a certificate by clicking a single button.
>
> What is a bit hard to understand is why the test-service at
> https://www.ap
Anders Rundgren wrote:
on the URL http://demo.webpki.org/mozkeygen
you can get yourself a certificate by clicking a single button.
What is a bit hard to understand is why the test-service at
https://www.apache-ssl.org/cgi/cert-export
often (but not always!) asks the user multiple times to OK the
Anders Rundgren:
> on the URL http://demo.webpki.org/mozkeygen
> you can get yourself a certificate by clicking a single button.
>
> What is a bit hard to understand is why the test-service at
> https://www.apache-ssl.org/cgi/cert-export
> often (but not always!) asks the user multiple times to OK
on the URL http://demo.webpki.org/mozkeygen
you can get yourself a certificate by clicking a single button.
What is a bit hard to understand is why the test-service at
https://www.apache-ssl.org/cgi/cert-export
often (but not always!) asks the user multiple times to OK the
certificate selection di
On Nov 13, 8:38 pm, David Stutzman wrote:
> D3!$ wrote:
> > No, I needed the source code, not the NSS functions: I have already
> > checked all the links on Mozilla site. I'd be glad if somebody were
> > willing to share their source code :-)
> > Warm Regards,
> > D3|\||\|!$
>
> You will r
On Nov 13, 8:38 pm, David Stutzman wrote:
> D3!$ wrote:
> > No, I needed the source code, not the NSS functions: I have already
> > checked all the links on Mozilla site. I'd be glad if somebody were
> > willing to share their source code :-)
> > Warm Regards,
> > D3|\||\|!$
>
> You will r
D3!$ wrote:
> No, I needed the source code, not the NSS functions: I have already
> checked all the links on Mozilla site. I'd be glad if somebody were
> willing to share their source code :-)
> Warm Regards,
> D3|\||\|!$
You will receive much better responses here if you show that you hav
Hi!!!
I have been using the SSL client-server executables bundled with the
binaries of NSS package to test SSL packet sending and recieving.
However, these applications do not provide the decoding of the message
sent by the client to the server. I therefore need the source code of
these .exes so
On Nov 13, 6:16 pm, [EMAIL PROTECTED] wrote:
> http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslfnc.html
> should help, I guess.
>
> Umesh.
>
>
>
> > Hi!!!
> > I have been using the SSL client-server executables bundled with the
> > binaries of NSS
http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslfnc.html
should help, I guess.
Umesh.
> Hi!!!
> I have been using the SSL client-server executables bundled with the
> binaries of NSS package to test SSL packet sending and recieving.
> However, these applications do not
Hi!!!
I have been using the SSL client-server executables bundled with the
binaries of NSS package to test SSL packet sending and recieving.
However, these applications do not provide the decoding of the message
sent by the client to the server. I therefore need the source code of
these .exes so
I could solve it. SSL_OptionSet(socket, SSL_ENABLE_SSL3, PR_TRUE) does
the trick.
Best Regards.
Umesh.
- Original Message -
From: "Umesh Bywar" <[EMAIL PROTECTED]>
To:
Cc:
Sent: Tuesday, April 03, 2007 6:41 PM
Subject: SSL Client
> Hi all:
>
>
follows. To effectively do a
handshake with the target server when there is another proxy chained with my
proxy, I have written an SSL Client. The client code is similar to what is
described in the SSLSample in mozilla code base
(http://lxr.mozilla.org/seamonkey/source/security/nss/cmd
John Smith wrote:
I'm a little bit confused with "Ask me every time" option (Tools ->
Options -> Advanced -> Security tab). During each SSL handshaking, it asks
me _twice_ to select certificate for SSL. Why?
I've seen that myself over several versions of Mozilla browser and
Firefox. I don't
I'm a little bit confused with "Ask me every time" option (Tools ->
Options -> Advanced -> Security tab). During each SSL handshaking, it asks
me _twice_ to select certificate for SSL. Why?
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozi
>Kyle wrote
>> As for Firefox, the only thing which can be used via JavaScript is
>> signtext. If there were a crypto object in the DOM which could
>> support more than just signtext, it would be quite nice -- but there
>> isn't one as far as I've been able to tell. (I have not looked that
>> clo
Hello Kyle,
1) The terminal must have its own keypair (in AD, it's a preshared
machine password hash) which must be used to authenticate the
terminal.
In this example, are you referring to platform authentication or to an
attestation of the software stack loaded on the platform? What I mean b
To get such an attestation to TLS, there are really two
authentications that must be done (and this is, btw, akin to the model
that MS Active Directory takes):
1) The terminal must have its own keypair (in AD, it's a preshared
machine password hash) which must be used to authenticate the
terminal
Hi Anders,
Thanks for your reply.
As you say TPMs may be used in a bad way. It is really up to
the "market" to decide what to use TPMs for. This includes us
as well :)
I completely agree with you here. Especially since the TPM-enablied
technologies haven't been widely implemented yet into
From: "Peter Djalaliev" <[EMAIL PROTECTED]>
To:
Sent: Thursday, July 20, 2006 15:19
Subject: Re: Platform Attestation. was:To SSL-client-auth or
nottoSSL-client-auth, that is the question(?)
Hello all,
I believe that TPM-generated platform attestation is a powerful mechanism
th
Hello all,
I believe that TPM-generated platform attestation is a powerful mechanism
that can be used to augment user authentication, but it has its issues, some
of which were mentioned above:
- TPM attestation is based on attestation quotes which are digitally signed
attestation logs. Attestat
Spam are other examples of PITAs that thrive due to SMTP
deficiencies.
>Information security is certainly necessary, but demanding a platform
>attestation is non-viable (keyloggers? network sniffers? debugging
>privileges? Ability to run arbitrary programs?).
Compared to securing S
On 7/17/06, Anders Rundgren <[EMAIL PROTECTED]> wrote:
Hi Julien,
My posting MAY be considered as a "speculation" since this has not
happened yet. The reason why this *could* become a reality is
the success of web-based services including outsourced dittos.
The latter seriously limits the appli
from spreading). Lock
everything else down.
Information security is certainly necessary, but demanding a platform
attestation is non-viable (keyloggers? network sniffers? debugging
privileges? Ability to run arbitrary programs?).
-Kyle H
On 7/17/06, Julien Pierre <[EMAIL PROTECTED]
Re: Platform Attestation. was:To SSL-client-auth or not to
SSL-client-auth, that is the question(?)
Anders,
Anders Rundgren wrote:
> Another reason why SSL client authentication may go bust is that it does not
> support the inclusion of platform attestations,
something that may be require
Anders,
Anders Rundgren wrote:
Another reason why SSL client authentication may go bust is that it does not support the inclusion
of platform attestations, something that may be required when TPMs become standard. That is, you
may [in the future] not be able to access corporate web-mail (or
Another reason why SSL client authentication may go bust is that it does not
support the inclusion of platform attestations, something that may be required
when TPMs become standard. That is, you may [in the future] not be able to
access corporate web-mail (or other sensitive web apps), from a
uld take all weaknesses and solve them one by one, but
>you'd end up having implemented a new secure channel on top
>of the HTTP connexion.
Yes, that is the goal. I believe this is what CardSpace (InfoCards)
does as well. Although I like standards, SSL-client-authentication
Anders Rundgren wrote:
[...]
There is though a general weakness in schemes that do not terminate
the client-side in the SSL channel [...]
this deficiency is eliminated by
"targeting" the client-side operation for the site and certificate in
the server-end. By doing that the receiver (server), can
l if there is any suitable available)?
I think you misunderstood my statement or that I was very unclear. I was
referring to SSL-client-auth versus the methods used in [the growing number of]
"competing" authentication schemes that works on top of an
SSL-server(only)-authenticated cha
Anders Rundgren wrote:
Security-wise there are no differences, assuming appropriate methods are used.
Well there is a form drop down to create client certs, why can't there
be something similar for choosing client certs to auth inside the form
(and some kind of hint method to tell if there i
Hi,
In theory SSL-client-authentication ought to be the only way to authenticate to
web-servers using PKI.
I reality this is not the case in many large-scale PKIs.
In addition, things have been complicated by the introduction of Microsoft's
CardSpace (formerly InfoCards) system,
88 matches
Mail list logo
