[prev in list] [next in list] [prev in thread] [next in thread] 

List:       httpclient-users
Subject:    Re: https client with TLS renegotiating server
From:       Oleg Kalnichevski <olegk () apache ! org>
Date:       2011-10-28 15:17:34
Message-ID: 20111028151734.GA12736 () ok2cons2 ! nine ! ch
[Download RAW message or body]

On Fri, Oct 28, 2011 at 04:44:59PM +0200, Henry Story wrote:
> 
> On 28 Oct 2011, at 16:01, Oleg Kalnichevski wrote:
> 
> > On Fri, Oct 28, 2011 at 10:21:42AM +0200, Henry Story wrote:
> > > I have a bit more support now in thinking that this is an issue with lack of \
> > > support for TLS renegotiation.  I added the following code to my test, which \
> > > calls a non TLS renegotiating server 
> > > "testing client certs" should {
> > > "connect to foafssl.org and ask for cert" in {
> > > 	   keyManager.setId("JoeLambda")
> > > 	   val foafssl = :/("foafssl.org",443)/"test/WebId" secure
> > > val model = Http(foafssl as_model(baseURI(foafssl),TURTLE) )
> > > model.write(System.out,TURTLE.jenaLang)
> > > model.size() must_==10 //should be greater than, but anyway
> > > }
> > > }
> > > 
> > > When I connect to foafssl.org - but any non TLS renegotiating server would do I \
> > > believe - then the methods in my FlexiKeyManager get called in the order \
> > > expected: namely first it gets asked for the aliases, then for a certificate \
> > > for that alias, and finally for the private key for that alias. This does not \
> > > happen when connecting to the server that does renegotiation. 
> > > class FlexiKeyManager extends X509ExtendedKeyManager {
> > > val keys = mutable.Map[String, Pair[Array[X509Certificate],PrivateKey]]()
> > > 
> > > def addClientCert(alias: String,certs: Array[X509Certificate], privateKey: \
> > > PrivateKey) { keys.put(alias,Pair(certs,privateKey))
> > > }
> > > 
> > > var currentId: String = null
> > > 
> > > def setId(alias: String) { currentId = if (keys.contains(alias)) alias else \
> > > null } def getClientAliases(keyType: String, issuers: Array[Principal]) = 
> > > if (currentId!=null) Array(currentId) else null
> > > def chooseClientAlias(keyType: Array[String], issuers: Array[Principal], \
> > > socket: Socket) =  currentId
> > > def getServerAliases(keyType: String, issuers: Array[Principal]) = null
> > > def chooseServerAlias(keyType: String, issuers: Array[Principal], socket: \
> > > Socket) = "" def getCertificateChain(alias: String) = keys.get(alias) match { 
> > > case Some(certNKey) => certNKey._1; 
> > > case None => null
> > > }
> > > def getPrivateKey(alias: String) = \
> > > keys.get(alias).map(ck=>ck._2).getOrElse(null) 
> > > override def chooseEngineClientAlias(keyType: Array[String], issuers: \
> > > Array[Principal], engine: SSLEngine): String = currentId }
> > > 
> > > 
> > 
> > Hi Henry
> > 
> > HttpClient has absolutely no control over TLS protocol aspects. It merely \
> > leverages TLS/SSL capabilities provided by Java JSSE. As far as I know the latest \
> > Java releases ship with support for the TLS renegotiation disabled. You can try \
> > enabling it using instructions below or consider using an alternative JSSE \
> > implementation. 
> > http://download.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html#tlsRenegotiation
> >  http://java.sun.com/javase/javaseforbusiness/docs/TLSReadme.html
> 
> Thanks Oleg,
> 
> I am already running with those following properties
> 
> -Dsun.security.ssl.allowUnsafeRenegotiation=true
> -Dsun.security.ssl.allowLegacyHelloMessages=true
> 
> set. I know I am doing this because I am also running the server in the same VM as \
> the client here: the testing engine. I also just printed out all the system \
> properties in the client code just to make sure, and they were still there. 
> Btw, on the latest JVMs TLS renegotiation is back on by default
> 
> http://download.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#descPhase2
>  
> So could it be that there is a bug in the Java code? That would be interesting, \
> because it would show that they had not tested their server  with their own client \
> libraries, which would be somewhat odd in fact. Perhaps I'll post a bug report then \
> on the oracle web site. 
> Henry
> 
> 

I think that with SSL debug one one should be able to see whether or not the TLS \
renegotiation is enabled and whether or not the client attempts to renegotiate in \
case the support for renegotiation is active.

Oleg



> > 
> > Oleg
> > 
> > > 
> > > 
> > > On 28 Oct 2011, at 00:49, Henry Story wrote:
> > > 
> > > > Hello,
> > > > 
> > > > I am working on a server that tries to ask the client for his X509 \
> > > > certificate only when it is sure that it will be needed. This can be done \
> > > > very neatly using TLS renegotiation:  the server can analysing the HTTP \
> > > > request to see if action requested on the resource needs authentication at \
> > > > all. If so it requests a TLS renegotiations as show in this mini netty server \
> > > > written in one page of Scala [1]. 
> > > > I am now trying to test this. Most desktop browsers accept some form of TLS \
> > > > renegotiation - except  Opera 11 I think. But I am not sure that java http \
> > > > client does. I am using the dispatch scala wrapping of the httpclient, and so \
> > > > I am cling them this too. 
> > > > The code for these tests is here:
> > > > 
> > > > https://dvcs.w3.org/hg/read-write-web/file/c0bf9b280888/src/test/scala/auth/CreateWebIDSpec.scala
> > > >  
> > > > The test after line 234 does not return the right result. After a lot of \
> > > > stepping through code it occurred to me that perhaps httpclient does not do \
> > > > renegotiation. Perhaps I have not set it up properly to do this. But it could \
> > > > also be another issue. As it is late, I thought I'd ask before going to \
> > > > sleep.  
> > > > Thanks in advance,
> > > > 
> > > > 	Henry
> > > > 
> > > > 
> > > > [1]  in the webid branch of the read-write-web project around line 64
> > > > https://dvcs.w3.org/hg/read-write-web/file/9ca474c333e8/src/main/scala/netty/SslLoginTest.scala
> > > >  [2] http://dispatch.databinder.net/Dispatch.html
> > > > 
> > > > 
> > > > Social Web Architect
> > > > http://bblfish.net/
> > > > 
> > > 
> > > Social Web Architect
> > > http://bblfish.net/
> > > 
> > > 
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> > > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> > 
> 
> Social Web Architect
> http://bblfish.net/
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]