New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 10 users

Issue metadata

Status: Verified
Owner:
Email to this user bounced
Closed: Mar 2010
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment

[Mac] Ignoring optional client-cert requests from server

Reported by henry.st...@gmail.com, Mar 9 2010

Issue description

Chrome Version       : 5.0.348.0 (40885)
URLs (if applicable) : https://foafssl.org/srv/idp
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 4: FAIL
  Firefox 3x, 4x: OK
  Opera: OK
         IE 7: OK
         IE 8: OK

What steps will reproduce the problem?
1. Create yourself a certificate 
   ( Any certificate will do - and it is easy to get one using one of the site:     
     http://esw.w3.org/topic/foaf+Bssl/IDP )
2. go to http://foaf.me/ and click login
    ( that just points you to  https://foafssl.org/srv/idp )
  
What is the expected result?

3. the browser should ask for a certificate
4. that certificate should be sent

( 5. this has nothing to do with this bug, but if your cert contains a valid subject alternative name 
you will be logged in)

What happens instead?

The server asks for the client certificate with

   Server Hello, Certificate, Certificate Request, Server Hello Done

(this server does ask for any certificates in the client)
But the client does not send a certificate.

Please provide any additional information below. Attach a screenshot if
possible.

-attached: A libpcap of the exact negotiation process going on.
-the server is apache-tomcat-6.0.24
  and the setup is described here
  http://blogs.sun.com/bblfish/entry/how_to_setup_tomcat_as
 
foafssl.org-using-chrome.libpcap
34.8 KB Download
This issues is a continuation of  issue 16831  .It was also reported with more detail in  issue 36207  . 

Comment 2 by snej@chromium.org, Mar 9 2010

Labels: -Area-Undefined Area-Internals Internals-Network OS-Mac
Status: Started
Summary: [Mac] Ignoring optional client-cert requests from server
Thanks Henry and Bruno for the great comments/explanations in 36207. (Yay open source!) I'm fairly new at SSL 
and don't know all the ins and outs of the protocol yet. I'll look into this issue today.

Comment 3 by snej@chromium.org, Mar 9 2010

In the email thread with Apple that Bruno referred to 
<http://lists.apple.com/archives/apple-cdsa/2009/Apr/msg00038.html>
the missing API Ken McLeod referred to is the kSSLSessionOptionBreakOnCertRequested flag, which was added in 
10.5.7. I'm using that option in the client-cert support, but it causes some problems with renegotiation so I have 
to disable it in some circumstances. I'll see if that's what's going wrong here.
I think this particular e-mail from Ken McLeod on the Apple-CDSA list might be of
interest. (If I guess correctly, senj/Jens was involved in this discussion.)
http://lists.apple.com/archives/Apple-cdsa/2010/Feb/msg00023.html

I don't know in details the Apple CDSA/CFNetwork API, but it seems the optional
certificate feature is only possible since Snow Leopard (OSX 10.6). I'm assuming that
the build I've tried yesterday (from the nightly build repo) was using the 10.5 API
(or under), even if it was running on 10.6.
(It also appears that even Safari doesn't make use on this feature yet.)

Comment 5 by snej@chromium.org, Mar 9 2010

The problem with optional certificate requests seems to have been just a logic error on my part. When 
receiving a cert request during the handshake (errSSLClientCertRequested) I forgot to return 
ERR_SSL_CLIENT_AUTH_CERT_NEEDED, which is needed to get the UI to ask the user to pick a cert. WIth that in 
place, I now get prompted for a cert at the Cheese Lover's Club site. And if I cancel that dialog, it proceeds 
with no cert, as it should.

I'm having further trouble with the foaf.me login page. Perhaps due to timing, we're getting the cert request in 
response to the first call to SSLHandshake (in DoHandshakeStart), which I wasn't expecting, so it just treated it 
as an 'unknown error'. I've added code to handle this case now — I had to add an instance variable 
client_cert_requested_ to remember the request, because we don't want to send the client cert until after the 
server cert's been (asynchronously) verified.
were you having a problem with the link to https://foafssl.org/srv/idp ? Let us know if it gets into tomorrow's 
build, so we can test it.

Comment 7 by snej@chromium.org, Mar 9 2010

After those fixes, I still can't get foaf.me to create a certificate. The two problems I see:
(1) The server response to the keygen (the POST to https://foaf.me/keygen.php) first asks for a client cert 
during the initial handshake. But I haven't gotten the client cert yet: that's what's in the response! So I have to 
cancel the dialog box.
(2) Once I do that, I get the cert back. But Chrome rejects it as invalid because it doesn't have any key-usage 
metadata stating it's suitable for SSL client identification. My code looks for either an ExtendedKeyUsage 
extension containing a 'ClientAuth' entry, or the old NetscapeCertType extension with the SSL_Client bit set. 
(See the method X509Certificate::SupportsSSLClientAuth.)
Both of these seem like issues with the server, not the client.

Comment 8 by snej@chromium.org, Mar 9 2010

Patch is out for review: http://codereview.chromium.org/746002

Comment 9 by bharbu...@gmail.com, Mar 10 2010

About point (1), I guess it would make sense, when the client doesn't have any
potential cert it can send, not to prompt the user for a choice (and thus not to send
any certificate).


About point (2), as far as I'm aware, the key usage extension isn't mandatory. It's
only if it's present that it should be acted upon (or must be, if marked as critical,
which is recommended when it's present). That's at least my interpretation of this:
http://tools.ietf.org/html/rfc5280#section-4.2.1.3

As far as I'm aware the certificates generated by foaf.me don't have any usage
extension, so they're acceptable for any usage, including client certificates.


Here are just a few extra notes on the topic of what list of client certificates to
let the user choose from (I've noticed something about issuers in the patch, but I
haven't read it in depth).

- TLS 1.0 was silent on the topic of CertificateRequest with an empty
certificate_authorities list. TLS 1.1 and 1.2 allow such a list, but doesn't say what
to do with it. (In our experience with FOAF+SSL work, browsers seem to be happy to
let the users choose from their entire list of client certificates (all issuers) if
the server sends such an empty list; servers written in Java or Apache Httpd can
already send an empty list, even with SSLv3 or TLS 1.0.)

- If the certificate_authorities list isn't empty, it doesn't mean that the client
certificate to be sent must be issued by a certificate on this list. It's not really
specified in TLS 1.0 and TLS 1.1. TLS 1.2 (RFC 5246) says:
  "If the certificate_authorities list in the certificate request
   message was non-empty, one of the certificates in the certificate
   chain SHOULD be issued by one of the listed CAs."
The problem here is that, even if clients implement this "SHOULD", there may be
intermediate certificates between the issuer and the client certificate.

(I realise this may be a different topic, so I'd put this information in a different
issue if required.)
Well spotted Snej and Bruno! Concerning point 1 in comment 7 this is indeed a bug on foaf.me . I posted a bug 
report concerning this on their mailing list:

    http://groups.google.com/group/foafme/browse_frm/thread/c4d147372dab1f5e

Even though it is a good idea to create a WebId enabled cert over https, to avoid a man in the middle cert 
substitution, it should not be asking for a client cert at that point.

If you want to try another service where, with one account, you can get as many certificates as you want, try
http://webid.myxwiki.org/ . 

That service creates keys with key usage extensions as shown by the code here:
http://tinyurl.com/yj5aw9n  (starting line 215)

So you can use that as another test case of your implementation :-)

Great work.


I don't think it's a bug in foaf.me.

If https://foaf.me/ is configured for asking for a certificate during the initial
negotiation (which it's entitled to do, and which is probably better pending
implementation of the re-negotiation security fix), it's going to ask for it, even if
the client doesn't have a certificate.

In this case, it turns out it's a service that also emits certificate so the content
it delivers is the certificate that will be imported into the browser.

The two issues are not incompatible: the service that provides the browser with a new
certificate also request certificate-based optional authentication (which it can
ignore for this particular subset of URIs).
Yes Bruno, the bug on foaf.me is not relevant to this issue, in fact it is useful as a test case. So I asked them not 
to fix it until this issue is fixed.

It is nevertheless a user interface bug, because someone could already have a certificate, and would for no 
reason be asked to login before creating the certificate that they really wanted. Whether or not that user interface 
bug is difficult or not to fix due to the rengotiation issue in TLS, is yet another issue...

But let's not tie up this thread with those issues - though it is good to see how these things tie together...
To avoid this issue getting tied up with the odd problem of certificate creation on http://foaf.me/ I suggest 
that to test this issue we use http://webid.myxwiki.org/ to create a key . Key creation there avoids the https 
issue as it is all http based (and so somewhat insecure)

The key created on webid.myxwiki.org can then be used to login to http://nanoblog.me/ using the "login to 
your account" link that points to https://foafssl.org/srv/idp .

foafssl.org is the service which uses Tomcat, and which requests a certificate using the standard compliant 
method described on wikipedia TLS page http://en.wikipedia.org/wiki/Transport_Layer_Security as "Client-
authenticated TLS handshake". 

Comment 14 by snej@chromium.org, Mar 10 2010

Re#9: Bruno, I do think it's a bug. The client may have other unrelated client certs that could be used, so (as in 
my case) the choose-cert panel comes up. Also, there's no need for client auth when generating a cert if the new 
cert's not going to be based on some pre-existing identity.

Re#13: Henry, I'll try the other sites you suggested. Thanks again for these links, they're invaluable.

Comment 15 by snej@chromium.org, Mar 10 2010

I've generated a cert at myxwiki, and Chrome accepts it. When I try to use it to log in at nanoblog.me, at the SSL 
level everything goes great, but the response redirects to <http://nanoblog.me/index.php?
error=noVerifiedWebID>, which looks just like the original page (there's no error message displayed; the only 
clue anything happened is the different in the URL.)
So I _think_ everything is going fine on Chrome's part now — it sent the CSR, accepted and saved the cert, let me 
choose it, and sent it to the server. Is it just a server bug that it didn't like the cert?

Comment 16 by snej@chromium.org, Mar 10 2010

If I use Firefox 3.7/Mac (after I import the identity into it), nanoblog.me also rejects the certificate.
I'm able to use Chromium 5.0.351.0 (41153) to access create and install a client 
certificate via our internal CA.
ok, I think this is a bug, with the rdfa parser used by foafssl.org .

What foafssl.org does is fetch the WebId you have in the subject alternative name of the X509 certificate you 
send, then it does an HTTP GET on that URL, and then query it using a SPARQL query. 

You can see the query on line 260 of
http://tinyurl.com/ykzh9u4

It looks like the rdfa I wrote recently messes up the parser foafssl is using, though it works with another one.

I'll get back to you later on it, see how I can fix this, and then test it again. It will take a bit of time. 

Thanks for getting me to notice this.
Re#14: OK, so it might be a "usability lack of feature".

It's true it's not ideal, but it's (a) a matter of finer configuration of the foaf.me
server and (b) having client and server implementations that support the fix for
CVE-2009-3555, since it relies on renegotiation.
I've sent more details here:
  http://groups.google.com/group/foafme/browse_thread/thread/5e1e82fc956ed68a

There are currently two problems with foaf.me:
  - Client cert authentication is configured on its root; this should be done only on
for the locations that need client cert authentication to improve the user experience.
  - It uses renegotiation, without CVE-2009-3555 fix (RFC 5746) as far as I've been
able to see.
It's a double problem since:
  - if it wants to keep ignoring CVE-2009-3555, it might as well implement
renegotiation at a finer grain;
  - if it wants to disable renegotiation (to protect against CVE-2009-3555, pending
deployment of the fixed version), it might as well have the client cert request sent
during the initial handshake (and use a version of OpenSSL that has renegotiation
disabled, these ones were available a few days after the vulnerability disclosure as
security fixes on a few distributions).

I guess it's ultimately a "double-RFE": having RFC 5746 supported in Apache Httpd
(OpenSSL 0.9.8m doesn't seem to have made its way into many distributions yet, not
sure how many may have backported the patch) and supported in Chrome.
  http://lists.apple.com/archives/apple-cdsa/2010/Feb/msg00042.html
  http://lists.apple.com/archives/apple-cdsa/2010/Feb/msg00044.html

(Fixing CVE-2009-3555 should probably be in a separate issue.)
So I found a band aid solution to  the issue on foafssl.org, while waiting for the parser to be fixed. Essentially I 
have simplified the SPARQL query to not check that the node is a rsa:RSAPublicKey, since it is implied by the 
rsa:modulus and rsa:public_exponent relations as defined at their namespace:

$ curl -H "Accept: text/n3" http://www.w3.org/ns/auth/rsa 

This bypasses the parser bug for the time being.

I mentioned RDFa above, and forgot to link to the spec. RDFa is a microformaty like way to add RDF to html
   http://www.w3.org/TR/xhtml-rdfa-primer/

So I downloaded today's nightly build, but it did not ask me for my key, so I suppose this patch has not yet 
made it into the build...
I opened up  issue 38082  for the TLS CVE-2009-3555 issue and the RFC 5746 proposed protocol fix.

As it is taking some time for the patch to get accepted, I wonder if it may not be good to split it into a 2, so that 
the reviewer can have an easier time understanding it. The patch seems to cover two distinct issues.
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=41742 

------------------------------------------------------------------------
r41742 | snej@chromium.org | 2010-03-16 11:49:04 -0700 (Tue, 16 Mar 2010) | 5 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/ssl_client_socket_mac.cc?r1=41742&r2=41741

Mac: Ignoring optional client-cert requests from server
BUG= 37765 
TEST=none

Review URL: http://codereview.chromium.org/746002
------------------------------------------------------------------------

Comment 24 by snej@chromium.org, Mar 16 2010

Status: Fixed
OK, it's finally in. Henry and Bruno, if you could test this out and let me know if it fixes the problems, I'd be much 
obliged. Thanks!
Yep, it Works! At least on all the sites I have tried! And now I am finding a lot of bugs on their side.  I will be 
testing this a lot, as I use it everyday, ...

So the key remaining issue that needs to be solved is the user interface  issue 29784  . 
This is an issue that is valid across browsers, so I also put out a call for help there http://bit.ly/cQ5f48 .
Status: Verified
Chrome version: 5.0.356.0 r41818
Project Member

Comment 27 by bugdroid1@chromium.org, Oct 12 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 28 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-Internals -Internals-Network Cr-Internals Cr-Internals-Network

Sign in to add a comment