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
>
> 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: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
Social Web Architect
http://bblfish.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
