Auth by client's certificate

8 messages

Auth by client's certificate

Reply Threaded

Hello,

I'm using Jetty as restlet HTTP engine with SSL enabled and client's
certificate auth.
Probabaly it's more related to Jetty but is this possible to make server
only ask
for certificates only for certain URL.

I'm NOT USING needClientAuthentication, so certificate is not mandatory,
but
what i want is following

- for certain resources still use HTTPS, but never let browser to ask for
client's certificate.

Only way i сan see now - is creating 2 HTTPS connectors and run 2 server
sockets within restlet app.

--
Regards,
Evgeny Shepelyuk

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2384794

Bruno Harbulot

Re: Auth by client's certificate

Reply Threaded

Hi Evgeny,

Evgeny Shepelyuk wrote:

> Hello,
>
> I'm using Jetty as restlet HTTP engine with SSL enabled and client's
> certificate auth.
> Probabaly it's more related to Jetty but is this possible to make server
> only ask
> for certificates only for certain URL.
>
> I'm NOT USING needClientAuthentication, so certificate is not mandatory,
> but
> what i want is following
>
> - for certain resources still use HTTPS, but never let browser to ask for
> client's certificate.
>
> Only way i сan see now - is creating 2 HTTPS connectors and run 2 server
> sockets within restlet app.
>

In principle, this can be achieved by re-negotiating the handshake.

This is something that Tomcat supports if the listening socket isn't
configured to want or need authentication but CLIENT-CERT is used within
the webapp.
As far as I know, Jetty (as a container) doesn't support it. I don't
think its API supports it either. The Grizzly library has some support
for this mechanism.
The Restlet API doesn't support it at the moment. Currently, the client
certificate is populated when the handler is set up (when the socket is
connected), after that, the upper layers (Application/Resource/...)
can't talk back to the socket to tell it to re-negotiate.

This is not impossible, but it would require some changes in the API, in
particular HttpServerCall and the way the client certificate is then
passed to the request attributes.

I also reported a bug about this using Glassfish/Grizzly (nothing
Restlet-specific) a few months ago; I haven't tried more recently.
https://grizzly.dev.java.net/issues/show_bug.cgi?id=416
This would definitely be a problem to implement this feature in Restlet
if the libraries used by the connectors don't support it.

A possible workaround might be to use Restlet within Tomcat and to use
CLIENT-CERT for the URI patterns (defined in web.xml) that you know will
want client-certificate authentication.

Best wishes,

Bruno.

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2385222

eshepelyuk

Re: Auth by client's certificate

Reply Threaded

Hi
Thnx for this answert
I have one small request
Can you point to Grizzly classes how this goal can be achieved ?

> Hi Evgeny,
>
> Evgeny Shepelyuk wrote:
>> Hello,
>>
>> I'm using Jetty as restlet HTTP engine with SSL enabled and client's
>> certificate auth.
>> Probabaly it's more related to Jetty but is this possible to make server
>> only ask
>> for certificates only for certain URL.
>>
>> I'm NOT USING needClientAuthentication, so certificate is not mandatory,
>> but
>> what i want is following
>>
>> - for certain resources still use HTTPS, but never let browser to ask
>> for
>> client's certificate.
>>
>> Only way i сan see now - is creating 2 HTTPS connectors and run 2 server
>> sockets within restlet app.
>>
>
>
> In principle, this can be achieved by re-negotiating the handshake.
>
> This is something that Tomcat supports if the listening socket isn't
> configured to want or need authentication but CLIENT-CERT is used within
> the webapp.
> As far as I know, Jetty (as a container) doesn't support it. I don't
> think its API supports it either. The Grizzly library has some support
> for this mechanism.
> The Restlet API doesn't support it at the moment. Currently, the client
> certificate is populated when the handler is set up (when the socket is
> connected), after that, the upper layers (Application/Resource/...)
> can't talk back to the socket to tell it to re-negotiate.
>
> This is not impossible, but it would require some changes in the API, in
> particular HttpServerCall and the way the client certificate is then
> passed to the request attributes.
>
> I also reported a bug about this using Glassfish/Grizzly (nothing
> Restlet-specific) a few months ago; I haven't tried more recently.
> https://grizzly.dev.java.net/issues/show_bug.cgi?id=416
> This would definitely be a problem to implement this feature in Restlet
> if the libraries used by the connectors don't support it.
>
>
> A possible workaround might be to use Restlet within Tomcat and to use
> CLIENT-CERT for the URI patterns (defined in web.xml) that you know will
> want client-certificate authentication.
>
>
> Best wishes,
>
> Bruno.
>
> ------------------------------------------------------
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2385222
>

--
Regards,
Evgeny Shepelyuk

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2385290

Bruno Harbulot

Re: Auth by client's certificate

Reply Threaded

Hi,

I'm not sure. If GrizzlyServerCall is running from the same thread the
SSLReadFilter is used, SSLReadFilter.doPeerCertificateChain(...), with
the selection key in the GrizzlyServerCall should work.

What you need ultimately is to get hold of the SSLSession (via SSLEngine
or SSLSocket), invalidate this session, re-set the want/need parameter,
re-start the handshake (and make sure it has completed before proceeding).

I think the biggest problem, from the Restlet point of view, is that the
higher level classes (Restlet/Resource/...) would need somehow to be
able to get hold of the HttpServerCall to trigger this (and supporting
this feature would also depend on the connector implementation).
This would be something unusual compared with the rest of the
architecture of the Restlet framework. I'm not sure what the rest of the
community (in particular Jerome and Thierry) would think about that. I'd
be happy to assist, but I'm not sure how big the modifications in the
API and Restlet architecture would be.

Best wishes,

Bruno.

Evgeny Shepelyuk wrote:

> Hi
> Thnx for this answert
> I have one small request
> Can you point to Grizzly classes how this goal can be achieved ?
>
>
>> Hi Evgeny,
>>
>> Evgeny Shepelyuk wrote:
>>> Hello,
>>>
>>> I'm using Jetty as restlet HTTP engine with SSL enabled and client's
>>> certificate auth.
>>> Probabaly it's more related to Jetty but is this possible to make server
>>> only ask
>>> for certificates only for certain URL.
>>>
>>> I'm NOT USING needClientAuthentication, so certificate is not mandatory,
>>> but
>>> what i want is following
>>>
>>> - for certain resources still use HTTPS, but never let browser to ask
>>> for
>>> client's certificate.
>>>
>>> Only way i сan see now - is creating 2 HTTPS connectors and run 2 server
>>> sockets within restlet app.
>>>
>>
>> In principle, this can be achieved by re-negotiating the handshake.
>>
>> This is something that Tomcat supports if the listening socket isn't
>> configured to want or need authentication but CLIENT-CERT is used within
>> the webapp.
>> As far as I know, Jetty (as a container) doesn't support it. I don't
>> think its API supports it either. The Grizzly library has some support
>> for this mechanism.
>> The Restlet API doesn't support it at the moment. Currently, the client
>> certificate is populated when the handler is set up (when the socket is
>> connected), after that, the upper layers (Application/Resource/...)
>> can't talk back to the socket to tell it to re-negotiate.
>>
>> This is not impossible, but it would require some changes in the API, in
>> particular HttpServerCall and the way the client certificate is then
>> passed to the request attributes.
>>
>> I also reported a bug about this using Glassfish/Grizzly (nothing
>> Restlet-specific) a few months ago; I haven't tried more recently.
>> https://grizzly.dev.java.net/issues/show_bug.cgi?id=416
>> This would definitely be a problem to implement this feature in Restlet
>> if the libraries used by the connectors don't support it.
>>
>>
>> A possible workaround might be to use Restlet within Tomcat and to use
>> CLIENT-CERT for the URI patterns (defined in web.xml) that you know will
>> want client-certificate authentication.
>>
>>
>> Best wishes,
>>
>> Bruno.
>>
>> ------------------------------------------------------
>> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2385222
>>
>
>
>

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2385695

eshepelyuk

Re: Auth by client's certificate

Reply Threaded

Well, maybe it's reasonable to create RFE for this and try to impelment
extenstion prototype ?

> Hi,
>
> I'm not sure. If GrizzlyServerCall is running from the same thread the
> SSLReadFilter is used, SSLReadFilter.doPeerCertificateChain(...), with
> the selection key in the GrizzlyServerCall should work.
>
> What you need ultimately is to get hold of the SSLSession (via SSLEngine
> or SSLSocket), invalidate this session, re-set the want/need parameter,
> re-start the handshake (and make sure it has completed before
> proceeding).
>
> I think the biggest problem, from the Restlet point of view, is that the
> higher level classes (Restlet/Resource/...) would need somehow to be
> able to get hold of the HttpServerCall to trigger this (and supporting
> this feature would also depend on the connector implementation).
> This would be something unusual compared with the rest of the
> architecture of the Restlet framework. I'm not sure what the rest of the
> community (in particular Jerome and Thierry) would think about that. I'd
> be happy to assist, but I'm not sure how big the modifications in the
> API and Restlet architecture would be.
>
>
> Best wishes,
>
> Bruno.
>
> Evgeny Shepelyuk wrote:
>> Hi
>> Thnx for this answert
>> I have one small request
>> Can you point to Grizzly classes how this goal can be achieved ?
>>
>>
>>> Hi Evgeny,
>>>
>>> Evgeny Shepelyuk wrote:
>>>> Hello,
>>>>
>>>> I'm using Jetty as restlet HTTP engine with SSL enabled and client's
>>>> certificate auth.
>>>> Probabaly it's more related to Jetty but is this possible to make
>>>> server
>>>> only ask
>>>> for certificates only for certain URL.
>>>>
>>>> I'm NOT USING needClientAuthentication, so certificate is not
>>>> mandatory,
>>>> but
>>>> what i want is following
>>>>
>>>> - for certain resources still use HTTPS, but never let browser to ask
>>>> for
>>>> client's certificate.
>>>>
>>>> Only way i сan see now - is creating 2 HTTPS connectors and run 2
>>>> server
>>>> sockets within restlet app.
>>>>
>>>
>>> In principle, this can be achieved by re-negotiating the handshake.
>>>
>>> This is something that Tomcat supports if the listening socket isn't
>>> configured to want or need authentication but CLIENT-CERT is used
>>> within
>>> the webapp.
>>> As far as I know, Jetty (as a container) doesn't support it. I don't
>>> think its API supports it either. The Grizzly library has some support
>>> for this mechanism.
>>> The Restlet API doesn't support it at the moment. Currently, the client
>>> certificate is populated when the handler is set up (when the socket is
>>> connected), after that, the upper layers (Application/Resource/...)
>>> can't talk back to the socket to tell it to re-negotiate.
>>>
>>> This is not impossible, but it would require some changes in the API,
>>> in
>>> particular HttpServerCall and the way the client certificate is then
>>> passed to the request attributes.
>>>
>>> I also reported a bug about this using Glassfish/Grizzly (nothing
>>> Restlet-specific) a few months ago; I haven't tried more recently.
>>> https://grizzly.dev.java.net/issues/show_bug.cgi?id=416
>>> This would definitely be a problem to implement this feature in Restlet
>>> if the libraries used by the connectors don't support it.
>>>
>>>
>>> A possible workaround might be to use Restlet within Tomcat and to use
>>> CLIENT-CERT for the URI patterns (defined in web.xml) that you know
>>> will
>>> want client-certificate authentication.
>>>
>>>
>>> Best wishes,
>>>
>>> Bruno.
>>>
>>> ------------------------------------------------------
>>> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2385222
>>>
>>
>>
>>
>
> ------------------------------------------------------
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2385695
>

--
Regards,
Evgeny Shepelyuk

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2385928

jlouvel

RE: Auth by client's certificate

Reply Threaded

Hi Evgeny,

I think it is a good idea to create a RFE summarizing this discussion. Do you want to take care of it?

As a solution, I was thinking about passing the SSLSession as a special request attribute ("org.restlet.https.sslSession" for example). Then you could retrieve it in your application, call the SSLSession#invalidate() method. However, I'm less clear about the next steps and how they could be supported in a connector independent way... Maybe we should introduce some kind of façade class, like SslContextFactory abstract class that you contributed Bruno?

Another case where it is necessary to interact with the lower-level connections from the upper Restlet layer is for connection tunneling via the HTTPS CONNECT method. Maybe there is a common pattern that will emerge. See related RFE:

"Support HTTP proxies and gateways"
http://restlet.tigris.org/issues/show_bug.cgi?id=207

Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com

-----Message d'origine-----
De : news [mailto:[hidden email]] De la part de Evgeny Shepelyuk
Envoyé : vendredi 21 août 2009 10:56
À : [hidden email]
Objet : Re: Auth by client's certificate

Well, maybe it's reasonable to create RFE for this and try to impelment
extenstion prototype ?

--
Regards,
Evgeny Shepelyuk

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2385928

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2386463

eshepelyuk

Re: Auth by client's certificate

Reply Threaded

In reply to this post by eshepelyuk

Hello, Jerome

Unfortunately i dont have enought knowledge on how htis SSL things are
working.
So taking care of such RFE is out of my possibilities :)

> Hi Evgeny,
>
> I think it is a good idea to create a RFE summarizing this discussion.
> Do you want to take care of it?
>
> As a solution, I was thinking about passing the SSLSession as a special
> request attribute ("org.restlet.https.sslSession" for example). Then you
> could retrieve it in your application, call the SSLSession#invalidate()
> method. However, I'm less clear about the next steps and how they could
> be supported in a connector independent way... Maybe we should introduce
> some kind of façade class, like SslContextFactory abstract class that
> you contributed Bruno?
>
> Another case where it is necessary to interact with the lower-level
> connections from the upper Restlet layer is for connection tunneling via
> the HTTPS CONNECT method. Maybe there is a common pattern that will
> emerge. See related RFE:
>
> "Support HTTP proxies and gateways"
> http://restlet.tigris.org/issues/show_bug.cgi?id=207
>
> Best regards,
> Jerome Louvel
> --
> Restlet ~ Founder and Lead developer ~ http://www.restlet.org
> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>
>
> -----Message d'origine-----
> De : news [mailto:[hidden email]] De la part de Evgeny Shepelyuk
> Envoyé : vendredi 21 août 2009 10:56
> À : [hidden email]
> Objet : Re: Auth by client's certificate
>
> Well, maybe it's reasonable to create RFE for this and try to impelment
> extenstion prototype ?
>
>> Hi,
>>
>> I'm not sure. If GrizzlyServerCall is running from the same thread the
>> SSLReadFilter is used, SSLReadFilter.doPeerCertificateChain(...), with
>> the selection key in the GrizzlyServerCall should work.
>>
>> What you need ultimately is to get hold of the SSLSession (via SSLEngine
>> or SSLSocket), invalidate this session, re-set the want/need parameter,
>> re-start the handshake (and make sure it has completed before
>> proceeding).
>>
>> I think the biggest problem, from the Restlet point of view, is that the
>> higher level classes (Restlet/Resource/...) would need somehow to be
>> able to get hold of the HttpServerCall to trigger this (and supporting
>> this feature would also depend on the connector implementation).
>> This would be something unusual compared with the rest of the
>> architecture of the Restlet framework. I'm not sure what the rest of the
>> community (in particular Jerome and Thierry) would think about that. I'd
>> be happy to assist, but I'm not sure how big the modifications in the
>> API and Restlet architecture would be.
>>
>>
>> Best wishes,
>>
>> Bruno.
>>
>> Evgeny Shepelyuk wrote:
>>> Hi
>>> Thnx for this answert
>>> I have one small request
>>> Can you point to Grizzly classes how this goal can be achieved ?
>>>
>>>
>>>> Hi Evgeny,
>>>>
>>>> Evgeny Shepelyuk wrote:
>>>>> Hello,
>>>>>
>>>>> I'm using Jetty as restlet HTTP engine with SSL enabled and client's
>>>>> certificate auth.
>>>>> Probabaly it's more related to Jetty but is this possible to make
>>>>> server
>>>>> only ask
>>>>> for certificates only for certain URL.
>>>>>
>>>>> I'm NOT USING needClientAuthentication, so certificate is not
>>>>> mandatory,
>>>>> but
>>>>> what i want is following
>>>>>
>>>>> - for certain resources still use HTTPS, but never let browser to ask
>>>>> for
>>>>> client's certificate.
>>>>>
>>>>> Only way i сan see now - is creating 2 HTTPS connectors and run 2
>>>>> server
>>>>> sockets within restlet app.
>>>>>
>>>>
>>>> In principle, this can be achieved by re-negotiating the handshake.
>>>>
>>>> This is something that Tomcat supports if the listening socket isn't
>>>> configured to want or need authentication but CLIENT-CERT is used
>>>> within
>>>> the webapp.
>>>> As far as I know, Jetty (as a container) doesn't support it. I don't
>>>> think its API supports it either. The Grizzly library has some support
>>>> for this mechanism.
>>>> The Restlet API doesn't support it at the moment. Currently, the
>>>> client
>>>> certificate is populated when the handler is set up (when the socket
>>>> is
>>>> connected), after that, the upper layers (Application/Resource/...)
>>>> can't talk back to the socket to tell it to re-negotiate.
>>>>
>>>> This is not impossible, but it would require some changes in the API,
>>>> in
>>>> particular HttpServerCall and the way the client certificate is then
>>>> passed to the request attributes.
>>>>
>>>> I also reported a bug about this using Glassfish/Grizzly (nothing
>>>> Restlet-specific) a few months ago; I haven't tried more recently.
>>>> https://grizzly.dev.java.net/issues/show_bug.cgi?id=416
>>>> This would definitely be a problem to implement this feature in
>>>> Restlet
>>>> if the libraries used by the connectors don't support it.
>>>>
>>>>
>>>> A possible workaround might be to use Restlet within Tomcat and to use
>>>> CLIENT-CERT for the URI patterns (defined in web.xml) that you know
>>>> will
>>>> want client-certificate authentication.
>>>>
>>>>
>>>> Best wishes,
>>>>
>>>> Bruno.
>>>>
>>>> ------------------------------------------------------
>>>> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2385222
>>>>
>>>
>>>
>>>
>>
>> ------------------------------------------------------
>> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2385695
>>
>
>
>

--
Regards,
Evgeny Shepelyuk

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2386988

Bruno Harbulot

Re: Auth by client's certificate

Reply Threaded

In reply to this post by eshepelyuk

Hello,

I haven't had time to look into this further yet. However,
re-negotiation is currently considered a security-hole:
http://extendedsubset.com/?p=8

I haven't studied the attack in detail, but I think it might be avoided
if the server is able to check that the method during which the
re-negotiation happens doesn't have side effects (i.e.
GET/HEAD/OPTIONS), therefore avoiding to do "bad things" in the name of
the legitimate client. Implementing such a verification may be tricky.

Best wishes,

Bruno.

Jerome Louvel wrote:

> Hi Evgeny,
>
> I think it is a good idea to create a RFE summarizing this discussion. Do you want to take care of it?
>
> As a solution, I was thinking about passing the SSLSession as a special request attribute ("org.restlet.https.sslSession" for example). Then you could retrieve it in your application, call the SSLSession#invalidate() method. However, I'm less clear about the next steps and how they could be supported in a connector independent way... Maybe we should introduce some kind of façade class, like SslContextFactory abstract class that you contributed Bruno?
>
> Another case where it is necessary to interact with the lower-level connections from the upper Restlet layer is for connection tunneling via the HTTPS CONNECT method. Maybe there is a common pattern that will emerge. See related RFE:
>
> "Support HTTP proxies and gateways"
> http://restlet.tigris.org/issues/show_bug.cgi?id=207
>
> Best regards,
> Jerome Louvel
> --
> Restlet ~ Founder and Lead developer ~ http://www.restlet.org
> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>

------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2414747