Open Bug 419069 Opened 16 years ago Updated 2 years ago

SSL client authentication with no installed certificate gives a bad error message

Categories

(Core :: Security: PSM, defect, P3)

x86
Linux
defect

Tracking

()

People

(Reporter: johan.ferner, Unassigned)

References

(Blocks 1 open bug, )

Details

(Whiteboard: [psm-auth][psm-backlog])

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; sv-SE; rv:1.9b3) Gecko/2008020513 Firefox/3.0b3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; sv-SE; rv:1.9b3) Gecko/2008020513 Firefox/3.0b3

The URL https://login-ssl2.lantmateriet.se requires a two way SSL connection. This is very common in my country (Sweden) where we use certificates to access personal information on government sites.

If you don't have a certificate installed on your firefox and request a login you get a message indicating that the website is at fault and that the user should contact the website. This is simply not true and will be annoying for our first line support team.

The errorcode is ssl_error_handshake_failure_alert.

This is actually a regression from Firefox 2 that displayed an alert box with the very interesting message: Errorcode: -12227

Although that error code could use some polishing as well... :)

Reproducible: Always

Steps to Reproduce:
1.Have no personal certificates installed.
2.Surf to https://minfastighet.lantmateriet.se/minfastighet
3.click the link: (Nordea, SEB, Telia eller Posten)
Actual Results:  
An internal error page displaying a Bad error message.

Expected Results:  
An internal error page that asks the user if a certificate was needed to complete the request.
Assignee: nobody → kengert
Component: Security → Security: PSM
Product: Firefox → Core
QA Contact: firefox → psm
ssl_error_handshake_failure_alert is actually the human readable name for NSS error -12227
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9?
I get error message
  An error occurred during a connection to login-ssl2.lantmateriet.se.
  SSL peer was unable to negotiate an acceptable set of security parameters.
  (Error code: ssl_error_handshake_failure_alert)

I think you're proposing that Firefox should give a better error message, maybe like this?
  "This server requires that you identify with a personal certificate, 
   but you don't have one that this server accepts.
   The server terminated the connection."


Nelson, is there an error code that clearly identifies the scenario "no suitable client auth cert"?

I found SSL_ERROR_NO_TRUSTED_SSL_CLIENT_CA.

Should NSS return this error code for the given server?


I suspect it might be too late to improve the error message, because we are now beyond the string freeze deadline for Firefox 3.
The error message in itself is as good/bad as the previous one -12227...
What I really don't like is the concluding:

"Please contact the web site owners to inform them of this problem."

Although I do prefer your error message.


As far as I understand, I think that the error -12227 (or ssl_error_handshake_failure_alert) means : "the TLS server refuses to talk to you, for reasons that only the TLS server can explain". Firefox or the NSS library in particular can't know why this is the case - it's the responsibility of the TLS owners to explain more." We don't even know if it's due to your missing or incorrect certificate (it could be for a totally different reasons !!!) - it's the website that needs to explain this.
Kai, The SSL and TLS specifications define a large number of "alert" (error)
messages that the client and server can send to each other explaining why
they are not continuing.  You can see the list at 
http://lxr.mozilla.org/security/source/security/nss/lib/ssl/ssl3prot.h#107
Some of those are very specific, and others are very general.  Many products
elect to never send any of the specific alerts, and only send the most general
alert, which is "handshake_failure".  That alert code tells us NOTHING about
the reason for the failure.  It's just "it didn't work".  The NSS error code 
cited above is the one that means "the server send us a handshake_failure alert".  

Now, I suppose that we COULD keep track of whether we've been asked to send
client authentication, and then if the handshake fails with handshake_failure,
we could INFER that the cause was that the server disliked whatever the 
client sent for authentication, but that inference would not always be true.

The reason that the error message for ssl_error_handshake_failure_alert tells
the user to contact the server admin is that the ONLY way for the user to 
find out what exactly caused the failure is to check the server logs.  
Presumably the server knows why it discontinued the connection, and hopefully
it logged the reason.  But the server chose to NOT tell the client why, and
so the client can only guess.  The message is saying, in effect, if you want
to know WHY it failed, you'll have to contact someone who can examine the 
server logs".

We've been advising server programmers, server administrators, and anyone 
who will listen (:-) for YEARS, that the best thing for an https server to
do, when it is dissatisfied with the client's authentication, is NOT to 
drop the connection with some SSL/TLS error alert code, but rather it so 
complete the handshake successfully, and then return an error page that says
"Sorry, you didn't provide acceptable user authentication credentials" in 
the user's language.  

Any way you look at it, the solution to this reporter's problem is to change 
the server to either
a) return a meaningful detailed SSL alert code, or 
b) return an html error page that tells the user what's wrong and how best 
to correct it.  

IMO, there is no browser bug here.
minusing per comment 5, also the behavior sounds better than Firefox 2 per comment 0. I wouldn't call that a regression, sounds like an improvement. Either way, there's no loss of functionality here.
Flags: blocking1.9? → blocking1.9-
All SSL is "two way".  We're talking about client authentication here.
Summary: Two-way SSL with no installed certificate gives a bad error message → SSL client authentication with no installed certificate gives a bad error message
Since the original bug was raised in 2001 at least its more than a little disengenuous to say that there's no loss of functionality.  There is no functionality in telling the user something which makes no sense.

The error shouldn't simply be propagated up as a text message it should be explained because it is an SSL handshaking fault.  There are few likely causes, there is no cert on the client machine or the cert has expired or there's a CRL.  Transmission errors are unlikely to cause handshaking errors.

Trying to fix an application's error messaging by fixing the rest of the world is, I'm afraid to say, just wrong headed. Expecting all administrators to do it in one particular way is just going to perpetuate the problem for users.
"This is actually a regression from Firefox 2 that displayed an alert box with
the very interesting message: Errorcode: -12227"

I am saying that our current error message is not a regression from the Firefox 2 behavior in this case, where you get an alert with a non-readable error code. There is no loss of functionality versus the previous version. I am not making a judgement on whether this behavior is ideal.

I don't know what original bug you're referring to, I don't see any links to an older bug here.
Sorry, as I got directed here I thought it was already linked...

https://bugzilla.mozilla.org/show_bug.cgi?id=107491
Simon, I'll tell you something else that's wrong headed.  It's assuming that
all problems are the browser's fault, and that the browser must be changed
any time there is a problem.  As I explained above, the server has chosen
to send us an error message that says nothing more than "it didn't work".
There are MANY possible reasons for it.  The few reasons you listed in 
comment 8 are only a few of the possibilities.  We would display an error 
message that lists all the possible things that could go wrong in a 
handshake, and that would be of no help to the user whatsoever.  

If some server administrator is unhappy that mozilla browsers point his
web site's users to him, he should plan to change his server so that it 
better informs his users of the real problem cause.  That's entirely 
within his control.  
That's the nature of being the client software in the transaction.  Even if the fault is at the server end, its the client's responsibility to explain it in as cogent and straightforward a way as possible.

Fault in this context is irrelevant, the functionality is the relevance.

Of course that doesn't mean its simple to determine an exact cause and it may well be too difficult to do the following:

Connect with a cert, handshake fails check cert, if expired then give that as the primary cause, otherwise give a general message.

If that does prove too difficult then a redirect to a page which explains the whole scenario including the possibility that a certificate might be expired or invalid would be a reasonable thing to do.  This is similar to IE, which is not perfect but it gives slightly more of a clue even if it could be worded in a way that's understandable to a general user.

It is the browser's responsibility to deliver a coherent experience, this error message fails that test.
Simon, the server terminates the connection and doesn't tell us why.
Even though the SSL protocol allows it, the server doesn't care.

I agree with Nelson's arguments in this bug.
I don't like the idea to have the client attempt with multiple connections. (Not to mention that this would be risky whenever there is POST data and transactions involved.)

Change your SSL server to tell us why you disconnected, and we'll make firefox display that information. Deal?
Not following this bug for now, we're string frozen now, so this is not going to impact me for a while.
I think this issue is the same as the bug that is reported here because the main issue seems to be on how security warnings should be presented to the user.

Mozilla Firefox displays a big fat error page when an invalid certificate is used, if it has either expired or not signed by a "trusted" party.

This seems to be breaking a lot of websites and many people are complaining about it. One of the articles that describes this problem in detail can be found here:

http://royal.pingdom.com/?p=339

After giving it some thought I think the approach of Firefox 3 is wrong. Access to page should not be blocked when it has an invalid certificate, such a page is by no means less secure than a page that is sent over HTTP unencrypted, like most pages are sent. It is in fact still more secure than most pages because the connection itself is still encrypted. 

Pages with an invalid certificate should just be displayed, but without any of the fancy stuff in the location bar that indicates that it is secure. Possibly a warning in the status bar as well.
This is a different problem (ssl_error_handshake_failure_alert), caused by the webserver itself - there's no way to accept this as an exception, temporary or not. And it didn't work in Firefox 2 either, although with a more obscure error message.
I'd be really happy if the text from comment #2 was used. CAcert's support gets a few requests per week with user's trying to understand the error message.

Comment #5 on being a server side problem it a good ideal. Giving a good helpful error message is also good. I did a Apache configuration like follows that can be retrofitted to existing services without a single code change:

Set SSLVerifyClient" to "optional:

And in the VirtualHost setting.

RewriteEngine        on
RewriteCond     %{SSL:SSL_CLIENT_VERIFY} !=SUCCESS
RewriteRule     .? - [F]
ErrorDocument 403 "You need a client side certificate to access this site"

Don't use this for when the config is serving http otherwise the error will display then too.
Kai, here's a thought.  The choice of error message to be displayed for
certain error codes (such as ssl_error_handshake_failure_alert and possibly
others) could be stateful.  PSM could remember whether it has seen a client
auth cert request on this connection, and if so, it could display a different
or additional message, such as the one your suggested in comment 2 (when no
cert was sent) or one like the following if a cert was sent:

  "This server requires that you identify with a personal certificate, 
   but it apparently did not accept the certificate you selected.
   The server terminated the connection."
I think the error shows up also in case no certificate is available and no list is presented because of that. In that case no selection happens by the user.
It is true that lousy servers are not telling clients what's going on.  So helpful browsers can only make some vague handwaving statements.  But this is better than sticking head in sand!  How about making an informative but vague, handwaving statement.  

"The webserver closed the SSL connection and did not say why.  This is often because the server is misconfigured, _read more here_.

The most common causes are:

   * the server requested a client certificate, and your browser did not supply one!
   * ...

If these causes aren't it, you will have to ask the website operator what the reason is."
Assignee: kaie → nobody
Blocks: clientauth
Whiteboard: [psm-auth]
According to http://www.ietf.org/rfc/rfc2246.txt (The TLS Protocol Version 1.0), para 7.4.6, Client certificate:

"If no suitable certificate is
available, the client should send a certificate message
containing no certificates. If client authentication is _required_
by the server for the handshake to continue, it may respond with
a fatal handshake failure alert."

Handshake failure has code 40, according to [1] we do: case handshake_failure: error = SSL_ERROR_HANDSHAKE_FAILURE_ALERT, its description is shown by the error page.  So the reaction of the server is in accordance with the RFC and we display the error correctly.

However, if:
1. the server _requests_ a client cert
2. we don't send any (certificate length = 0)
3. server responds with fatal alert 40

we MAY _ASSUME_ the alert was reported because we didn't provide a certificate but it was actually _required_ by the server.  The server doesn't have a different way to tell the client it is required to provide a valid cert then to throw an alert and close the connection.

What about to display the general message for alert 40 and, under the  conditions above, prepend it with a message like "You may not be able to connect to this server because it requires you to provide a certificate, but you don't have any Firefox/SeaMonkey/Thunderbird could send to the server."

[1] http://mxr.mozilla.org/mozilla-central/source/security/nss/lib/ssl/ssl3con.c#2624
The conditions from comment 21 are exactly what I can see in Whireshark output when connecting the server from comment 0 with no certificate, by the way.
Honza: I agree your proposal at the end of comment 21 is the
best we can do.  I think the error reporting will need to be
done inside NSS because only NSS has all the info to infer that
this handshake failure alert most likely means the server
requires a client certificate.
On the contrary, Wan-Teh,
NSS has called PSM's callback to ask for a client auth cert, and PSM has said 
"I don't have one".  PSM can remember that, and when NSS subsequently reports
Handshake Failure, PSM can infer from the fact that it previously told NSS
that it has no client auth cert that that was the problem.  

IMO, no NSS change is needed here.  This bug is rightfully placed in PSM.
I agree with Nelson.  I cannot see a reference to "handshake failure" in the RFC on a different place then in response to Client hello or Client certificate.  So we should be safe here.
Whiteboard: [psm-auth] → [psm-auth][psm-backlog]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.