TLS renegotiation (was: Re: Re: https://foaf.me asks for a client cert)
Bruno Harbulot
The fact that foaf.me asks for a client certificate is not a bug. The
fact that it does it via re-negotiation probably is, at the moment.
There are a couple of ways to configure client authentication in Apache
Httpd:
1. Initial negotiation:
<VirtualHost ...>
SSLVerifyClient ........
</VirtualHost>
2. Re-negotiation, for some URLs:
<VirtualHost ...>
<Location (or Directory) ...>
SSLVerifyClient ........
</Location>
</VirtualHost>
The second option relies on TLS renegotiation and provides two features:
- The request for a client certificate can be specific to some URIs,
rather the the whole server,
- The client certificate is sent over the initially encrypted
channel, which prevents potential eavesdroppers to see that certificate.
Unfortunately, if the server doesn't support RFC 5746 (only published
last month), enabling renegotiation also introduces a potential MITM
attack, according to
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555
It seems, that, if foaf.me itself is configured according to [1], it
uses renegotiation (over /). That's actually probably a bad thing
considering it doesn't seem to support RFC 5746 (I'm not sure how many
clients support it at this stage anyway - One of the latest versions of
Opera does).
The points here are that:
(a) There's nothing wrong with asking for a client certificate in the
initial handshake. The problem is that it might not look as good,
depending on the browser UI (but it probably should not ask the user
which certificate to choose if there are none to choose from).
(b) Initial negotiation of the certificate (SSLVerifyClient directly
under VirtualHost but not under Location/Directory) is actually a good
thing pending CVE-2009-3555 fix.
As a side note, unless you want to prevent eavesdropper to see the
certificate that's issued by foaf.me, it could be imported via a plain
http link (since it will only be imported into the browser if the
browser has the private key for it anyway).
Best wishes,
Bruno.
[1] http://foaf.me/Enabling_SSL_Client_Certificates_on_Apache.php
Melvin Carvalho wrote:
>
>
> 2010/3/10 bblfish <henry.st...@gmail.com <mailto:henry.st...@gmail.com>>
>
> Oh yes, this is a usability bug on the side of foaf.me
> <http://foaf.me>. But it is
> useful, in that it is helping test Chromium, as Chromium should, on
> being asked a certificate, return none automatically when it does not
> have any.
>
> So don't fix this immediately :-) Wait for Chromium to close that bug.
>
>
> Thanks for the bug report. A ticket has been filed.
>
> See your reward here: http://reward.me/64
>
> :)
>
>
>
> Henry
>
> On Mar 10, 8:47 am, bblfish <henry.st...@gmail.com
> <mailto:henry.st...@gmail.com>> wrote:
> > So in more detail:
> >
> > After creating an account on foaf.me <http://foaf.me> the user
> ends up on a web page
> > where he can get his own certificate using keygen. The account
> > creation page
> > and the keygen page should be under https in a secure setup, but
> > neither of them
> > should be asking the user for a certificate.
> >
> > On Mar 10, 8:25 am, bblfish <henry.st...@gmail.com
> <mailto:henry.st...@gmail.com>> wrote:
> >
> >
> >
> > > Hi,
> >
> > > In the bug report below on Chrome the developer fixing his
> issue, came
> > > accross the problem I am describing here
> >
> > >http://code.google.com/p/chromium/issues/detail?id=37765
> >
> > > It is a good thing to be able to ask or a certificate over https,
> > > because that makes it impossible for a man in the middle to
> substitute
> > > his foaf+ssl certificate, but change the web id to point to one
> of his
> > > domains for example.
> >
> > > But of course you should not be asking for a client cert at
> that point
> > > - as the client may not have one yet. And even if it did, that
> is not
> > > required.
> >
> > > Henry
>
> --
> You received this message because you are subscribed to the Google
> Groups "foaf.me <http://foaf.me>" group.
> To post to this group, send email to foa...@googlegroups.com
> <mailto:foa...@googlegroups.com>.
> To unsubscribe from this group, send email to
> foafme+un...@googlegroups.com
> <mailto:foafme%2Bunsu...@googlegroups.com>.
> For more options, visit this group at
> http://groups.google.com/group/foafme?hl=en.
>
>
bblfish
On Mar 10, 1:27 pm, Bruno Harbulot <Bruno.Harbu...@manchester.ac.uk>
wrote:
> Hi Henri and Melvin,
>
> The fact that foaf.me asks for a client certificate is not a bug. The
> fact that it does it via re-negotiation probably is, at the moment.
>
> There are a couple of ways to configure client authentication in Apache
> Httpd:
>
> 1. Initial negotiation:
>
> <VirtualHost ...>
> SSLVerifyClient ........
> </VirtualHost>
>
> 2. Re-negotiation, for some URLs:
>
> <VirtualHost ...>
> <Location (or Directory) ...>
> SSLVerifyClient ........
> </Location>
> </VirtualHost>
>
> The second option relies on TLS renegotiation and provides two features:
> - The request for a client certificate can be specific to some URIs,
> rather the the whole server,
> - The client certificate is sent over the initially encrypted
> channel, which prevents potential eavesdroppers to see that certificate.
>
> Unfortunately, if the server doesn't support RFC 5746 (only published
> last month), enabling renegotiation also introduces a potential MITM
> attack, according tohttp://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555
>
> It seems, that, if foaf.me itself is configured according to [1], it
> uses renegotiation (over /). That's actually probably a bad thing
> considering it doesn't seem to support RFC 5746 (I'm not sure how many
> clients support it at this stage anyway - One of the latest versions of
> Opera does).
>
> The points here are that:
> (a) There's nothing wrong with asking for a client certificate in the
> initial handshake. The problem is that it might not look as good,
> depending on the browser UI (but it probably should not ask the user
> which certificate to choose if there are none to choose from).
But I suppose it could be confusing to a user who has a number of
certificates already
to select a certificate at the point at which he is about to create
one.
As foaf.me is asking for any certificate, a user that has a
certificate that is only intended for one other service would be asked
to choose one of his certs, even though these would be ignored by
foaf.me.
So I think there is an issue of things just being confusing here.
Which is why I think this is a User Interaction bug.
> (b) Initial negotiation of the certificate (SSLVerifyClient directly
> under VirtualHost but not under Location/Directory) is actually a good
> thing pending CVE-2009-3555 fix.
>
> As a side note, unless you want to prevent eavesdropper to see the
> certificate that's issued by foaf.me, it could be imported via a plain
> http link (since it will only be imported into the browser if the
> browser has the private key for it anyway).
Yes that is what I am doing at http://webid.myxwiki.org/
But the idea of sending the certificate over ssl is not a bad one: it
removes the possibility of a man in the middle who could capture the
certificate creation request, create his own certificate pointing to
another WebId he controls, and where he would put a duplicate of the
requested foaf file including the correct public key.
Many users receiving such a certificate might not check the WebId, and
it could be some time before they notice.
A clever attacker could make this even more difficult by buying a
domain such as faof.me, tricking thereby many human readers.
Akbar Hossain
Thanks for the advice.
I have changed this to ask for the certificate over the initial negotiation.
Thanks
You received this message because you are subscribed to the Google Groups "foaf.me" group.
To post to this group, send email to foa...@googlegroups.com.
To unsubscribe from this group, send email to foafme+un...@googlegroups.com.