On Sun, Oct 4, 2009 at 2:30 PM, Ian G <i...@iang.org> 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 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 of what happened, whether
>>>> his certificate has expired, is revoked, is false (bad signature), was
>>>> provided by a not trusted certificate authority, and so on.
>>>> This is very frustrating for non tec users as they don't know what to
>>>> do.
>>>> Is there a trick to display client certificate authentication failure
>>>> causes to the user in Sun One Web Server 6.1 ?
>
>
> 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?
If the actual alert can be made available, as well as (something) even
(better than) the descriptive text from the TLS RFC regarding which
reason the server returned. In this case, the alert is "handshake
failure".
Part of the configuration of the webserver is telling it which CAs it
will accept certificates chaining to. If it sends '*' as that list,
gets a certificate from a CA it doesn't trust, and then sends
"handshake failure" instead of "unknown ca", it's broken.
The _only_ way that the browser knows what's wrong with the
certificate is via the TLS alert that is sent by the server. The
things that can be sent by the server (that are related to
certificates and such):
handshake_failure
Reception of a handshake_failure alert message indicates that the
sender was unable to negotiate an acceptable set of security
parameters given the options available.
bad_certificate
A certificate was corrupt, contained signatures that did not
verify correctly, etc.
unsupported_certificate
A certificate was of an unsupported type.
certificate_revoked
A certificate was revoked by its signer.
certificate_expired
A certificate has expired or is not currently valid.
certificate_unknown
Some other (unspecified) issue arose in processing the
certificate, rendering it unacceptable.
unknown_ca
A valid certificate chain or partial chain was received, but the
certificate was not accepted because the CA certificate could not
be located or couldn't be matched with a known, trusted CA. This
message is always fatal.
access_denied
A valid certificate was received, but when access control was
applied, the sender decided not to proceed with negotiation. This
message is always fatal.
decrypt_error
A handshake cryptographic operation failed, including being unable
to correctly verify a signature or validate a Finished message.
This message is always fatal.
protocol_version
The protocol version the client has attempted to negotiate is
recognized but not supported. (For example, old protocol versions
might be avoided for security reasons.) This message is always
fatal.
The server needs to send more information to the client for the client
to be able to display the precise reason why the server decided not to
continue with the handshake.
Now, "ssl_error_handshake_failure_alert" says, to me, that it received
a "handshake failure". This is described above to mean that there are
no shared cipher suites between the server and the client. (if the
client doesn't want to have MD5 as its HMAC algorithm, and the server
only offers MD5 HMACs, there's going to be a handshake failure.) The
OP suggests that this isn't the case. I'd ask if the two types of
clients' profiles for ciphers and such are the same in about:config.
A question for Nelson: Can NSS be configured to return a generic
"handshake failure" on all errors, not just on being unable to
negotiate a cipher suite?
-Kyle H
>>> On 2009-10-03 22:45 PDT, Meena Vyas wrote:
>>>
>>>>> Please ask Sun Web Server related questions in forum
>>>>> http://forums.sun.com/forum.jspa?forumID=759
>>>>>
>>> On 2009-10-04 11:43 PDT, Eddy Nigg wrote:
>>>
>>>> This is a Firefox issue, not a server-side problem.
>>>>
>>> Eddy, Please re-read the original request above.
>>> It does not mention any particular browser. It does mention a particular
>>> server, namely, Sun Web Server, which uses NSS. The request is quite
>>> specific. It's how to change the content of the error page returned by
>>> the server when it receives a certificate that is not valid, so as to
>>> point out what is wrong with the certificate. NSS provides that detailed
>>> info to the web server, but the server does not pass it on to the client.
>>> Jereme wishes to change that.
>>>
>>
>> Nelson, there is no server-side error page ever displayed in case the
>> browser has no client certificate matching one from the list of accepted
>> issuers. All Firefox does it shows the error page with
>> *ssl_error_handshake_failure_alert*, on other browsers it's very
>> similar, like Explorer simple claims "Page not found". This is a
>> shortcoming of the browsers, not server. The mentioning of the Sun
>> Server above is purely a coincident and is pretty irrelevant regarding
>> the user experience when confronted with it.
>>
>> I wish I could control that on the server side, unfortunately this is
>> not the case. For example see https://www.startssl.com/?app=25#10 and
>> the item thereafter which can give you feeling about which struggles we
>> have there with client certificate authentication and the wonderful
>> handling at browsers.
>
>
> Agree with Eddy. This is a browser issue. It might not be the one that the
> poster was after, but it looks like it to me!
>
> 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 case, it is always the part closest to the user that has to do the
> mostest. Maybe it's not a browser-tech or client-side-TLS issue, but *it is
> a browser issue*.
>
> iang
>
> PS: Also, it is standard security doctrine in many places that when
> something isn't quite right that no information is returned. Something to
> do with security advice of not being an oracle.
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
