Re: [jetty-dev] TLS connection Renegotiation

[Jesse McConnell <jesse.mcconnell@xxxxxxxxx>]

not directly addressing your mail, but the bit in [3] about lack of
configuration options, it was referencing jetty6 in that link but if
you update to recent versions of jetty you'll find a lot more
configurability on the ssl connector bits

7.5.0 is out tomorrow most likely, RC2 should be in central now.

cheers,
jesse

--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx



On Wed, Aug 31, 2011 at 06:29, Henry Story <henry.story@xxxxxxxxxxx> wrote:
> BACKGROUND
> ==========
>
> Perhaps it will help a bit if I explain the background. (There are different levels.) At the highest level, we are trying to build distributed secure social web. To do this we need global authentication. It happens that we can use TLS client certs to do this as explained in the W3C project http://webid.info/ .
>
> I am implementing this in http://clerezza.org Apache incubator groups, bblfish branch [1]. This project uses Felix, Apache's OSGI implementation.
>
> PROBLEM
> =======
>
> So currently we have this working with jetty's sslSocketConnector started in WANT mode. You can see this working here: http://foafssl.org/srv/idp (you need to get yourself a certificate - on http://webid.fcns.eu perhaps )
>
> There are essentially 3 modes for requesting client certificates: NONE, WANT, and NEED. The problem with Client certificates in needClientAuth mode is that they are not user-friendly: if the user mistakenly clicks the wrong button he gets a very ugly and unhelpful browser error. In wantClientAuth mode [2] the user can still access a resource (or be redirected to a friendly error page) if he does not have a certificate - and even if he has a broken certificate [4]. But this is still somewhat unfriendly: if the user has a certificate then he may be asked to show it even before he has ever seen the site he is trying to connect to! For many this may feel very uncomfortable. We are here trying to reach the ultimate in user-friendliness of client certificates.
>
> So we need a lot more flexibility. For this in fact it looks like we need client authentication turned off by default, and only have it requested in particular circumstances (say when someone clicks a login button). Apache allows this [5], and so do many other servers, though of course this has not been very much talked of recently due to the 2009 TLS renegotiation bug. But that feature may be just what we need to make things user-friendly - anyway, it is worth trying out.
>
>
> IDEA
> ====
>
> Because jetty is OSGI enabled in should be possible to have the ssl connector call another component with the HTTP header information and ask it if that request should be client auth enabled (if it is not already). Perhaps that component could by default have an implementation that does something simple like look up a file. A more advanced implementation could be moved by some database driven logic. In any case that component should be replaceable. If such a component says that client authentication is desired, then the jetty http component could at that point request this from the SSLEngine which it has access to. This would avoid the SSLEngine having to be leaked up to the servlet layer, which would be the other way to solve this problem.
>
>
> Does this seem reasonable? Any guiding thoughts? .
>
> Henry
>
> PS. Currently we are using jetty 7.0.1.v20091125
> PPS. This could help give a better answer to the stack overflow question [6]
>
>
> [1] https://github.com/bblfish/clerezza
> [2] This can be set at a low level using the SSLEngine
>     http://download.oracle.com/javase/7/docs/api/javax/net/ssl/SSLEngine.html
> [3] as described here:
>     http://fusesource.com/forums/message.jspa?messageID=2566
>    <bean id="jetty" class="org.apache.camel.component.jetty.JettyHttpComponent">
>    <property name="sslSocketConnector">
>      <bean class="org.mortbay.jetty.security.SslSocketConnector">
>        <property name="password" value="..."/>
>        <property name="keyPassword" value="..."/>
>        <property name="keystore" value="..."/>
>        <property name="needClientAuth" value="true"/>
>        <property name="truststore" value="..."/>
>      </bean>
>    </property>
>   </bean>
> [4] as we do in clerezza in the platform.security.foafssl module by replacing the X509TrustManager
> [5] http://www.vanemery.com/Linux/Apache/apache-SSL.html
>   <Directory /var/www/SSL/Certneeded>
>        SSLVerifyClient require
>        SSLVerifyDepth 1
>   </Directory>
> [6] http://stackoverflow.com/questions/4693534/jetty-require-ssl-client-certificate-by-url
>
>
> On 30 Aug 2011, at 14:20, Henry Story wrote:
>
>> Hi,
>>
>> I wanted to use TLS connection renegotiation. Java and many browsers have fixed the TLS Renegotiation bug  by implementing RFC 5746 [1], so this should be workable. (I am not sure exactly which browsers have fixed this. If anyone has a list please let me know).
>>
>> My question is how do I get the renegotiation to happen - programmatically would be best. Any ideas?
>>
>> Henry
>>
>>
>> [1] http://download.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#tlsRenegotiation
>>
>>
>> Social Web Architect
>> http://bblfish.net/
>>
>
> Social Web Architect
> http://bblfish.net/
>
> _______________________________________________
> jetty-dev mailing list
> jetty-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>