hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henry Story <henry.st...@bblfish.net>
Subject Re: https client with TLS renegotiating server
Date Fri, 28 Oct 2011 14:44:59 GMT

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
>> 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


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


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.


> 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

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

View raw message