SSL & Tomcat

[markt-2]

All,

I was thinking about this on my way back from ApacheCon and we probably
need to get some advice out to users early next week.

My current understanding is that the MITM attack is triggered by a
renegotiation.

On this basis I suggest something along the following lines:

SSL using JSSE (BIO and NIO connectors)
- Don't use SSL configs that require renegotiation. i.e. SSL config
should be the same for the entire host. Sites that require SSL in some
places and SSL + CLIENT-CERT in others will require reconfiguration.
Sites that require SSL for some parts should be OK.
- Keep watch for a Sun update to the JDK that may help address the issue

SSL using tc Native
- tcnative does not support renegotiation
(https://issues.apache.org/bugzilla/show_bug.cgi?id=46950) so for now
users of tc native with SSL should be OK


We also need to think about what to do with tc native. Maybe something like:
- release 1.1.17 with binaries built with 0.9.8l (so renegotiation is
disabled)
- keep an eye on httpd and if they find a work-around, copy it and
release 1.1.18 with renegotiation enabled

For now, I'm not proposing any changes to the docs although we may want
to put a summary of the advice - once agreed - on the security pages.

Thoughts?

Mark



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Costin Manolache-2]

On Sat, Nov 7, 2009 at 8:59 AM, Mark Thomas <markt@...> wrote:

> All,
>
> I was thinking about this on my way back from ApacheCon and we probably
> need to get some advice out to users early next week.
>
> My current understanding is that the MITM attack is triggered by a
> renegotiation.
>
> On this basis I suggest something along the following lines:
>
> SSL using JSSE (BIO and NIO connectors)
> - Don't use SSL configs that require renegotiation. i.e. SSL config
> should be the same for the entire host. Sites that require SSL in some
> places and SSL + CLIENT-CERT in others will require reconfiguration.
> Sites that require SSL for some parts should be OK.
>

IMO we could disable ACTION_REQ_SSL_CERTIFICATE ( with a flag
"allowManInMiddle" or completely ).


- Keep watch for a Sun update to the JDK that may help address the issue
>
>
Or ask people to switch to tcNative ( i.e. openSSL ) or stop using client
cert auth.

> SSL using tc Native
> - tcnative does not support renegotiation
> (https://issues.apache.org/bugzilla/show_bug.cgi?id=46950) so for now
> users of tc native with SSL should be OK
>
>
> We also need to think about what to do with tc native. Maybe something
> like:
> - release 1.1.17 with binaries built with 0.9.8l (so renegotiation is
> disabled)
> - keep an eye on httpd and if they find a work-around, copy it and
> release 1.1.18 with renegotiation enabled
>
>

> For now, I'm not proposing any changes to the docs although we may want
> to put a summary of the advice - once agreed - on the security pages.
>
> Thoughts?
>
>
How about the cypher suites - I don't think we allow per-context config of
allowed cyphers.

Also not sure about client-initiated re-negotiation - I guess using a fixed
openssl ( do they have
a fix ? ) and native would avoid this, otherwise we need to wait for a jsse
fix ?

Costin

[Bill Barker]

"Mark Thomas" <markt@...> wrote in message
news:4AF5A776.70104@......

> All,
>
> I was thinking about this on my way back from ApacheCon and we probably
> need to get some advice out to users early next week.
>
> My current understanding is that the MITM attack is triggered by a
> renegotiation.
>
> On this basis I suggest something along the following lines:
>
> SSL using JSSE (BIO and NIO connectors)
> - Don't use SSL configs that require renegotiation. i.e. SSL config
> should be the same for the entire host. Sites that require SSL in some
> places and SSL + CLIENT-CERT in others will require reconfiguration.
> Sites that require SSL for some parts should be OK.
> - Keep watch for a Sun update to the JDK that may help address the issue
>

IMHO, we will have to add an option to the <Connector/> that allows the user
to have the current renegotiation behavior.  It can even print out an
annoying warning in the log file if you set it.  But without this option,
what will happen is that users that are using CLIENT-CERT simply won't
upgrade.

And there a plenty of use cases where the user really isn't to worried about
MITM.  For example, if I am running an intranet server that uses CLIENT-CERT
to identify employees, then if a black-hat can get in a position to exploit
this, MITM is the least of my worries.

> SSL using tc Native
> - tcnative does not support renegotiation
> (https://issues.apache.org/bugzilla/show_bug.cgi?id=46950) so for now
> users of tc native with SSL should be OK
>
>
> We also need to think about what to do with tc native. Maybe something
> like:
> - release 1.1.17 with binaries built with 0.9.8l (so renegotiation is
> disabled)
> - keep an eye on httpd and if they find a work-around, copy it and
> release 1.1.18 with renegotiation enabled
>

At the moment, https seems to be going for rejecting attempts by the client
to renegotiate, but server renegotiation is unchanged (i.e. there is no
configuration change necessary to force CLIENT-CERT for a specific
directory).  Perhaps tc-native could do something along the lines of r833582
(the httpd patch).

> For now, I'm not proposing any changes to the docs although we may want
> to put a summary of the advice - once agreed - on the security pages.
>
> Thoughts?
>
> Mark




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Henri Yandell]

On Sat, Nov 7, 2009 at 8:59 AM, Mark Thomas <markt@...> wrote:

> All,
>
> I was thinking about this on my way back from ApacheCon and we probably
> need to get some advice out to users early next week.
>
> My current understanding is that the MITM attack is triggered by a
> renegotiation.
>
> On this basis I suggest something along the following lines:
>
> SSL using JSSE (BIO and NIO connectors)
> - Don't use SSL configs that require renegotiation. i.e. SSL config
> should be the same for the entire host. Sites that require SSL in some
> places and SSL + CLIENT-CERT in others will require reconfiguration.
> Sites that require SSL for some parts should be OK.
> - Keep watch for a Sun update to the JDK that may help address the issue

Also IBM, BEA, Apple etc. I'm not sure if JSSE is something Sun
license to everyone, or if other JVMs have their own implementation
(maybe OpenSSL based?). Harmony presumably does, though no idea if
it's OpenSSL or clean room (couldn't see anything on a vague browse
through their svn).

> SSL using tc Native
> - tcnative does not support renegotiation
> (https://issues.apache.org/bugzilla/show_bug.cgi?id=46950) so for now
> users of tc native with SSL should be OK

+1

> We also need to think about what to do with tc native. Maybe something like:
> - release 1.1.17 with binaries built with 0.9.8l (so renegotiation is
> disabled)
> - keep an eye on httpd and if they find a work-around, copy it and
> release 1.1.18 with renegotiation enabled

Plus keeping an eye on the next openssl version for
https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt
?

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Rainer Jung-3]

On 07.11.2009 17:59, Mark Thomas wrote:
> All,
>
> I was thinking about this on my way back from ApacheCon and we probably
> need to get some advice out to users early next week.
>
> My current understanding is that the MITM attack is triggered by a
> renegotiation.

Yes, client side initiated (AFAIK the client can decide to do this at
any time) and server initiated (most likely case is requiring client
certs for some parts of the content served by the host, or varying
cipher configuration on one site.

> On this basis I suggest something along the following lines:
>
> SSL using JSSE (BIO and NIO connectors)
> - Don't use SSL configs that require renegotiation. i.e. SSL config
> should be the same for the entire host. Sites that require SSL in some
> places and SSL + CLIENT-CERT in others will require reconfiguration.
> Sites that require SSL for some parts should be OK.

Except for client initiated renegotiation :(

> - Keep watch for a Sun update to the JDK that may help address the issue

Plus other vendors.

> SSL using tc Native
> - tcnative does not support renegotiation
> (https://issues.apache.org/bugzilla/show_bug.cgi?id=46950) so for now
> users of tc native with SSL should be OK

We need to test whether existing versions of Tomcat (with or without
tcnative) support client side initiated renegotiation. I can do it for
the tcnative case. The test (not a full MITM scenario but only a reneg
test) uses the openssl command s_client which can do reneg when typing "R".

My gut feeling says with tcnative we will support reneg and it will be
transparent to Tomcat. If that turns out to be true, we would need to
react w.r.t. tcnative (see below).

> We also need to think about what to do with tc native. Maybe something like:
> - release 1.1.17 with binaries built with 0.9.8l (so renegotiation is
> disabled)

Yes, disabling is fine for the moment, because it doesn't break existing
functionality. We should also add a comment about it in docs somewhere,
so that users building themselves using their OS supplied outdated
OpenSSL have been warned.

> - keep an eye on httpd and if they find a work-around, copy it and
> release 1.1.18 with renegotiation enabled

+1

and making 1.1.18 a dependency for 6.0.21 and 5.5.whatever.

> For now, I'm not proposing any changes to the docs although we may want
> to put a summary of the advice - once agreed - on the security pages.

+1

In summary the aspects for tcnative based SSL are

A) how to optionally fully disable all reneg
   - OpenSSL 0.9.8l
     - Breaks some future configs, but maxes on security
     - Users need to update binary tcnative to 1.1.17
       or rebuild their older version against new OpenSSL
B) how to disable client initiated reneg
   - Try porting httpd fix to tcnative
     - Will need new tcnative
C) how to fix config, so that there's no server initiated reneg
   - Needed in Addition to B)
D) how to fix reneg code, so that server initiated reneg gets safe
   - Might need proposed SSL extension, so newer
     OpenSSL version and possibly changes to tcnative

Regards,

Rainer

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Konstantin Kolinko]

2009/11/7 Mark Thomas <markt@...>:
>
> We also need to think about what to do with tc native. Maybe something like:

I think that we can
- recommend recompiling 1.1.16 with OpenSSL 0.9.8l for those who used
our sources
- for those architectures where binaries are available for 1.1.16
(windows 32/64-bit), rebuild them using OpenSSL 0.9.8l

My understanding is that 1.1.17 and later require TC 6.0.21 and 5.5.29
and later and vice versa, because of some API changes, and thus won't
be useful until those versions are released.

> - release 1.1.17 with binaries built with 0.9.8l (so renegotiation is
> disabled)

+1

> - keep an eye on httpd and if they find a work-around, copy it and
> release 1.1.18 with renegotiation enabled
>

+1

> For now, I'm not proposing any changes to the docs although we may want
> to put a summary of the advice - once agreed - on the security pages.
>
> Thoughts?
>
> Mark
>

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Mladen Turk-3]

On 09/11/09 11:34, Konstantin Kolinko wrote:

> 2009/11/7 Mark Thomas<markt@...>:
>>
>> We also need to think about what to do with tc native. Maybe something like:
>
> I think that we can
> - recommend recompiling 1.1.16 with OpenSSL 0.9.8l for those who used
> our sources
> - for those architectures where binaries are available for 1.1.16
> (windows 32/64-bit), rebuild them using OpenSSL 0.9.8l
>

Nope.
Use 1.1.17 and 0.9.8l

Just made binaries for 1.1.17 with APR 1.3.9 and OpenSSL 0.9.8l
(Well, 64-bit versions are on the way)

Regards
--
^TM


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[markt-2]

Konstantin Kolinko wrote:

> 2009/11/7 Mark Thomas <markt@...>:
>> We also need to think about what to do with tc native. Maybe something like:
>
> I think that we can
> - recommend recompiling 1.1.16 with OpenSSL 0.9.8l for those who used
> our sources
> - for those architectures where binaries are available for 1.1.16
> (windows 32/64-bit), rebuild them using OpenSSL 0.9.8l
>
> My understanding is that 1.1.17 and later require TC 6.0.21 and 5.5.29
> and later and vice versa, because of some API changes, and thus won't
> be useful until those versions are released.

That isn't my understanding. 6.0.21/5.5.29 requires 1.1.17 but not the
other way around (a method or two was added to the APR/native) libraries
but nothing was removed. 1.1.17 should work happily with 6.0.x and 5.5.x

Mark




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[markt-2]

Summarising the information gathered so far from various channels
(thanks to Bill B., Bill W. & Rainer who have done most of the actual
work to find the info below).

BIO/NIO connectors using JSSE.
Vulnerable when renegotiation is triggered by the client or server.
We could prevent server initiated renegotiation (and probably break the
majority of configurations using CLIENT-CERT).
We can't do anything to prevent client initiated renegotiation.

APR/native connector using OpenSSL
It is vulnerable when renegotiation is triggered by the client or by the
server.
Client triggered negotiation is supported.
Server triggered negotiation will be supported from 1.1.17 onwards.

OpenSSL 0.9.8l disables negotiation by default


In terms of what this means for users:

BIO/NIO
- There isn't anything we can do in Tomcat to stop client
  initiated renegotiation so it is a case of waiting for the JVM
  vendors to respond.

APR/native
- Re-building their current version with 0.9.8l will protect
  users at the risk of breaking any configurations that
  require renegotiation.
- We can release 1.1.17 with the binaries built with 0.9.8l. This
  will also protect users at the risk of breaking any
  configurations that require renegotiation. Mladen is doing this
  now.
- Supporting renegotiation whilst avoiding the vulnerability will
  require a protocol fix. In the meantime, we could port port
  r833582 from httpd which would disable client triggered
  renegotiation for OpenSSL < 0.9.8l (which may help some users
  who can't easily change their OpenSSl version and release 1.1.18
  with this fix
- Once the protocol is fixed, release 1.1.next bundled with the
  appropriate version of OpenSSL


Have I got my facts right above? If so, any objections to posting the
above to the users@ and announce@ lists along with adding something to
the security pages?

Mark




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Mladen Turk-3]

On 09/11/09 11:56, Mark Thomas wrote:
> - We can release 1.1.17 with the binaries built with 0.9.8l. This
>    will also protect users at the risk of breaking any
>    configurations that require renegotiation. Mladen is doing this
>    now.

I've uploaded binaries with APR-1.3.9/OpenSSL 9.8.8l.
Should be visible within an hour.

Regards
--
^TM

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Konstantin Kolinko]

2009/11/9 Mark Thomas <markt@...>:

> Konstantin Kolinko wrote:
>>
>> My understanding is that 1.1.17 and later require TC 6.0.21 and 5.5.29
>> and later and vice versa, because of some API changes, and thus won't
>> be useful until those versions are released.
>
> That isn't my understanding. 6.0.21/5.5.29 requires 1.1.17 but not the
> other way around (a method or two was added to the APR/native) libraries
> but nothing was removed. 1.1.17 should work happily with 6.0.x and 5.5.x
>

I am glad to be wrong.
I thought about the changes done by the following commit:
http://svn.apache.org/viewvc?view=revision&revision=832187
but those are already in 1.1.16 ..1.1.13. I have not looked earlier.

So let's go with 1.1.17

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Rainer Jung-3]

On 09.11.2009 11:56, Mark Thomas wrote:

> Summarising the information gathered so far from various channels
> (thanks to Bill B., Bill W. & Rainer who have done most of the actual
> work to find the info below).
>
> BIO/NIO connectors using JSSE.
> Vulnerable when renegotiation is triggered by the client or server.
> We could prevent server initiated renegotiation (and probably break the
> majority of configurations using CLIENT-CERT).
> We can't do anything to prevent client initiated renegotiation.
>
> APR/native connector using OpenSSL
> It is vulnerable when renegotiation is triggered by the client or by the
> server.
> Client triggered negotiation is supported.
> Server triggered negotiation will be supported from 1.1.17 onwards.
>
> OpenSSL 0.9.8l disables negotiation by default
>
>
> In terms of what this means for users:
>
> BIO/NIO
> - There isn't anything we can do in Tomcat to stop client
>   initiated renegotiation so it is a case of waiting for the JVM
>   vendors to respond.
>
> APR/native
> - Re-building their current version with 0.9.8l will protect
>   users at the risk of breaking any configurations that
>   require renegotiation.
> - We can release 1.1.17 with the binaries built with 0.9.8l. This
>   will also protect users at the risk of breaking any
>   configurations that require renegotiation. Mladen is doing this
>   now.
> - Supporting renegotiation whilst avoiding the vulnerability will
>   require a protocol fix. In the meantime, we could port port
>   r833582 from httpd which would disable client triggered
>   renegotiation for OpenSSL < 0.9.8l (which may help some users
>   who can't easily change their OpenSSl version and release 1.1.18
>   with this fix
> - Once the protocol is fixed, release 1.1.next bundled with the
>   appropriate version of OpenSSL
>
>
> Have I got my facts right above? If so, any objections to posting the
> above to the users@ and announce@ lists along with adding something to
> the security pages?

+1, everything seems right to me and ready for notice to the users.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Konstantin Kolinko]

2009/11/9 Mark Thomas <markt@...>:

> Summarising the information gathered so far from various channels
> (thanks to Bill B., Bill W. & Rainer who have done most of the actual
> work to find the info below).
>
> BIO/NIO connectors using JSSE.
> Vulnerable when renegotiation is triggered by the client or server.
> We could prevent server initiated renegotiation (and probably break the
> majority of configurations using CLIENT-CERT).
> We can't do anything to prevent client initiated renegotiation.
>
> APR/native connector using OpenSSL
> It is vulnerable when renegotiation is triggered by the client or by the
> server.
> Client triggered negotiation is supported.
> Server triggered negotiation will be supported from 1.1.17 onwards.
>
> OpenSSL 0.9.8l disables negotiation by default
>
>
> In terms of what this means for users:
>
> BIO/NIO
> - There isn't anything we can do in Tomcat to stop client
>  initiated renegotiation so it is a case of waiting for the JVM
>  vendors to respond.
>
> APR/native
> - Re-building their current version with 0.9.8l will protect
>  users at the risk of breaking any configurations that
>  require renegotiation.
> - We can release 1.1.17 with the binaries built with 0.9.8l. This
>  will also protect users at the risk of breaking any
>  configurations that require renegotiation. Mladen is doing this
>  now.
> - Supporting renegotiation whilst avoiding the vulnerability will
>  require a protocol fix. In the meantime, we could port port
>  r833582 from httpd which would disable client triggered
>  renegotiation for OpenSSL < 0.9.8l (which may help some users
>  who can't easily change their OpenSSl version and release 1.1.18
>  with this fix
> - Once the protocol is fixed, release 1.1.next bundled with the
>  appropriate version of OpenSSL
>
>
> Have I got my facts right above? If so, any objections to posting the
> above to the users@ and announce@ lists along with adding something to
> the security pages?
>
> Mark
>

+1

s/negotiation/renegotiation/
s/port port/port/

A question:
My understanding of renegotiation is that it changes SSL session. Is
it possible to observe changes in the value of SSL sessionId?  I doubt
so, but may be?
We read that value once and provide it to our users as
"javax.servlet.request.ssl_session" request attribute.

Regarding valves (as mentioned in issue 48157):
I understand, that that is not sufficient, but if anyone wants to
check against malformed headers, they can do so.

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[markt-2]

Konstantin Kolinko wrote:

> 2009/11/9 Mark Thomas <markt@...>:
>> Summarising the information gathered so far from various channels
>> (thanks to Bill B., Bill W. & Rainer who have done most of the actual
>> work to find the info below).
>>
>> BIO/NIO connectors using JSSE.
>> Vulnerable when renegotiation is triggered by the client or server.
>> We could prevent server initiated renegotiation (and probably break the
>> majority of configurations using CLIENT-CERT).
>> We can't do anything to prevent client initiated renegotiation.
>>
>> APR/native connector using OpenSSL
>> It is vulnerable when renegotiation is triggered by the client or by the
>> server.
>> Client triggered negotiation is supported.
>> Server triggered negotiation will be supported from 1.1.17 onwards.
>>
>> OpenSSL 0.9.8l disables negotiation by default
>>
>>
>> In terms of what this means for users:
>>
>> BIO/NIO
>> - There isn't anything we can do in Tomcat to stop client
>>  initiated renegotiation so it is a case of waiting for the JVM
>>  vendors to respond.
>>
>> APR/native
>> - Re-building their current version with 0.9.8l will protect
>>  users at the risk of breaking any configurations that
>>  require renegotiation.
>> - We can release 1.1.17 with the binaries built with 0.9.8l. This
>>  will also protect users at the risk of breaking any
>>  configurations that require renegotiation. Mladen is doing this
>>  now.
>> - Supporting renegotiation whilst avoiding the vulnerability will
>>  require a protocol fix. In the meantime, we could port port
>>  r833582 from httpd which would disable client triggered
>>  renegotiation for OpenSSL < 0.9.8l (which may help some users
>>  who can't easily change their OpenSSl version and release 1.1.18
>>  with this fix
>> - Once the protocol is fixed, release 1.1.next bundled with the
>>  appropriate version of OpenSSL
>>
>>
>> Have I got my facts right above? If so, any objections to posting the
>> above to the users@ and announce@ lists along with adding something to
>> the security pages?
>>
>> Mark
>>
>
> +1
>
> s/negotiation/renegotiation/
> s/port port/port/

Noted. I'll get the notice out.

> A question:
> My understanding of renegotiation is that it changes SSL session. Is
> it possible to observe changes in the value of SSL sessionId?  I doubt
> so, but may be?
> We read that value once and provide it to our users as
> "javax.servlet.request.ssl_session" request attribute.

Hmm. Interesting. I need to do some testing :)

I'll add something along the lines of "We are currently evaluating a
number of possible work-arounds prior to a protocol fix becoming
available. Discussion is happening on the dev list and any significant
developments will be posted to the users@ and announce@ mailing lists.

Mark



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Rainer Jung-3]

On 09.11.2009 17:16, Mark Thomas wrote:

> Konstantin Kolinko wrote:
>> 2009/11/9 Mark Thomas <markt@...>:
>>> Summarising the information gathered so far from various channels
>>> (thanks to Bill B., Bill W. & Rainer who have done most of the actual
>>> work to find the info below).
>>>
>>> BIO/NIO connectors using JSSE.
>>> Vulnerable when renegotiation is triggered by the client or server.
>>> We could prevent server initiated renegotiation (and probably break the
>>> majority of configurations using CLIENT-CERT).
>>> We can't do anything to prevent client initiated renegotiation.
>>>
>>> APR/native connector using OpenSSL
>>> It is vulnerable when renegotiation is triggered by the client or by the
>>> server.
>>> Client triggered negotiation is supported.
>>> Server triggered negotiation will be supported from 1.1.17 onwards.
>>>
>>> OpenSSL 0.9.8l disables negotiation by default
>>>
>>>
>>> In terms of what this means for users:
>>>
>>> BIO/NIO
>>> - There isn't anything we can do in Tomcat to stop client
>>>  initiated renegotiation so it is a case of waiting for the JVM
>>>  vendors to respond.
>>>
>>> APR/native
>>> - Re-building their current version with 0.9.8l will protect
>>>  users at the risk of breaking any configurations that
>>>  require renegotiation.
>>> - We can release 1.1.17 with the binaries built with 0.9.8l. This
>>>  will also protect users at the risk of breaking any
>>>  configurations that require renegotiation. Mladen is doing this
>>>  now.
>>> - Supporting renegotiation whilst avoiding the vulnerability will
>>>  require a protocol fix. In the meantime, we could port port
>>>  r833582 from httpd which would disable client triggered
>>>  renegotiation for OpenSSL < 0.9.8l (which may help some users
>>>  who can't easily change their OpenSSl version and release 1.1.18
>>>  with this fix
>>> - Once the protocol is fixed, release 1.1.next bundled with the
>>>  appropriate version of OpenSSL
>>>
>>>
>>> Have I got my facts right above? If so, any objections to posting the
>>> above to the users@ and announce@ lists along with adding something to
>>> the security pages?
>>>
>>> Mark
>>>
>>
>> +1
>>
>> s/negotiation/renegotiation/
>> s/port port/port/
>
> Noted. I'll get the notice out.
>
>> A question:
>> My understanding of renegotiation is that it changes SSL session. Is
>> it possible to observe changes in the value of SSL sessionId?  I doubt
>> so, but may be?
>> We read that value once and provide it to our users as
>> "javax.servlet.request.ssl_session" request attribute.
>
> Hmm. Interesting. I need to do some testing :)

Yes, using the naive openssl test with s_client and the "R" command, the
session id changes.

In order to find out, whether this is optional behaviour or will always
happen, I guess we would need to ask on the openssl dev list, which I
will do in a minute :)

> I'll add something along the lines of "We are currently evaluating a
> number of possible work-arounds prior to a protocol fix becoming
> available. Discussion is happening on the dev list and any significant
> developments will be posted to the users@ and announce@ mailing lists.

+1

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Costin Manolache-2]

On Mon, Nov 9, 2009 at 8:04 AM, Konstantin Kolinko
<knst.kolinko@...>wrote:

> 2009/11/9 Mark Thomas <markt@...>:
> > Summarising the information gathered so far from various channels
> > (thanks to Bill B., Bill W. & Rainer who have done most of the actual
> > work to find the info below).
> >
> > BIO/NIO connectors using JSSE.
> > Vulnerable when renegotiation is triggered by the client or server.
> > We could prevent server initiated renegotiation (and probably break the
> > majority of configurations using CLIENT-CERT).
> > We can't do anything to prevent client initiated renegotiation.
> >
> > APR/native connector using OpenSSL
> > It is vulnerable when renegotiation is triggered by the client or by the
> > server.
> > Client triggered negotiation is supported.
> > Server triggered negotiation will be supported from 1.1.17 onwards.
> >
> > OpenSSL 0.9.8l disables negotiation by default
> >
> >
> > In terms of what this means for users:
> >
> > BIO/NIO
> > - There isn't anything we can do in Tomcat to stop client
> >  initiated renegotiation so it is a case of waiting for the JVM
> >  vendors to respond.
> >
> > APR/native
> > - Re-building their current version with 0.9.8l will protect
> >  users at the risk of breaking any configurations that
> >  require renegotiation.
> > - We can release 1.1.17 with the binaries built with 0.9.8l. This
> >  will also protect users at the risk of breaking any
> >  configurations that require renegotiation. Mladen is doing this
> >  now.
> > - Supporting renegotiation whilst avoiding the vulnerability will
> >  require a protocol fix. In the meantime, we could port port
> >  r833582 from httpd which would disable client triggered
> >  renegotiation for OpenSSL < 0.9.8l (which may help some users
> >  who can't easily change their OpenSSl version and release 1.1.18
> >  with this fix
> > - Once the protocol is fixed, release 1.1.next bundled with the
> >  appropriate version of OpenSSL
> >
> >
> > Have I got my facts right above? If so, any objections to posting the
> > above to the users@ and announce@ lists along with adding something to
> > the security pages?
> >
> > Mark
> >
>
> +1
>
> s/negotiation/renegotiation/
> s/port port/port/
>
> A question:
> My understanding of renegotiation is that it changes SSL session. Is
> it possible to observe changes in the value of SSL sessionId?  I doubt
> so, but may be?
>

AFAIK you can reuse the session ID across negotiations ( it's a nice
optimization BTW, too
bad we're not using, it can speed up SSL connections a lot ), I'm not sure
if it changes
within a renegotation, but AFAIK when you start any negotiation you can
specify you want
to reuse the old session id.  But if I understand the exploit correctly -
they would want a different
cypher, and if you reuse the session you reuse the old one.


Maybe we can modify JSSESupport.Listener to break the connection if
handshakeCompleted is
called > once in a connection ? That is besides disabling server-initiated
handshakes.

Costin

> We read that value once and provide it to our users as
> "javax.servlet.request.ssl_session" request attribute.
>
> Regarding valves (as mentioned in issue 48157):
> I understand, that that is not sufficient, but if anyone wants to
> check against malformed headers, they can do so.
>
> Best regards,
> Konstantin Kolinko
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

[Costin Manolache-2]

On Mon, Nov 9, 2009 at 10:47 AM, Costin Manolache <costin@...> wrote:

On Mon, Nov 9, 2009 at 8:04 AM, Konstantin Kolinko <knst.kolinko@...> wrote:

2009/11/9 Mark Thomas <markt@...>:

> Summarising the information gathered so far from various channels
> (thanks to Bill B., Bill W. & Rainer who have done most of the actual
> work to find the info below).
>
> BIO/NIO connectors using JSSE.
> Vulnerable when renegotiation is triggered by the client or server.
> We could prevent server initiated renegotiation (and probably break the
> majority of configurations using CLIENT-CERT).
> We can't do anything to prevent client initiated renegotiation.
>
> APR/native connector using OpenSSL
> It is vulnerable when renegotiation is triggered by the client or by the
> server.
> Client triggered negotiation is supported.
> Server triggered negotiation will be supported from 1.1.17 onwards.
>
> OpenSSL 0.9.8l disables negotiation by default
>
>
> In terms of what this means for users:
>
> BIO/NIO
> - There isn't anything we can do in Tomcat to stop client
>  initiated renegotiation so it is a case of waiting for the JVM
>  vendors to respond.
>
> APR/native
> - Re-building their current version with 0.9.8l will protect
>  users at the risk of breaking any configurations that
>  require renegotiation.
> - We can release 1.1.17 with the binaries built with 0.9.8l. This
>  will also protect users at the risk of breaking any
>  configurations that require renegotiation. Mladen is doing this
>  now.
> - Supporting renegotiation whilst avoiding the vulnerability will
>  require a protocol fix. In the meantime, we could port port
>  r833582 from httpd which would disable client triggered
>  renegotiation for OpenSSL < 0.9.8l (which may help some users
>  who can't easily change their OpenSSl version and release 1.1.18
>  with this fix
> - Once the protocol is fixed, release 1.1.next bundled with the
>  appropriate version of OpenSSL
>
>
> Have I got my facts right above? If so, any objections to posting the
> above to the users@ and announce@ lists along with adding something to
> the security pages?
>
> Mark
>

+1

s/negotiation/renegotiation/
s/port port/port/

A question:
My understanding of renegotiation is that it changes SSL session. Is
it possible to observe changes in the value of SSL sessionId?  I doubt
so, but may be?

AFAIK you can reuse the session ID across negotiations ( it's a nice optimization BTW, too 

bad we're not using, it can speed up SSL connections a lot ), I'm not sure if it changes 

within a renegotation, but AFAIK when you start any negotiation you can specify you want 

to reuse the old session id.  But if I understand the exploit correctly - they would want a different

cypher, and if you reuse the session you reuse the old one.  

Maybe we can modify JSSESupport.Listener to break the connection if handshakeCompleted is 

called > once in a connection ? That is besides disabling server-initiated handshakes.

BTW - confirmed that JSSESupport.Listener is called when client does re-negotiate, but it is not called on the first 

negotiation ( it's added too late ). 

However it's pretty easy to add a listener earlier, patch attached - it should break all client re-negotiations, so we don't need

to wait for a JDK fix. 

I wrote a small unit test - but I'm can't seem to get jsse client to re-negotiate for the test, can only do it using command line

openssl. The patch seems to work - but you need so system properties  or flags if we want to let people

 disable this ( "allowManInTheMiddle" is a good name for a flag ).  Also the test needs a bit of work.

If anyone has more time, my 20% is getting low .... 

Costin 

 

Costin

 

We read that value once and provide it to our users as
"javax.servlet.request.ssl_session" request attribute.

Regarding valves (as mentioned in issue 48157):
I understand, that that is not sufficient, but if anyone wants to
check against malformed headers, they can do so.

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[TestTomcatSSL.java]

---

/*
 * Licensed to the Apache Software Foundation (ASF) under one or more
 * contributor license agreements.  See the NOTICE file distributed with
 * this work for additional information regarding copyright ownership.
 * The ASF licenses this file to You under the Apache License, Version 2.0
 * (the "License"); you may not use this file except in compliance with
 * the License.  You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */
package org.apache.catalina.startup;

import java.io.BufferedInputStream;
import java.io.File;
import java.io.InputStream;
import java.io.OutputStream;
import java.net.Socket;

import javax.net.ssl.HandshakeCompletedEvent;
import javax.net.ssl.HandshakeCompletedListener;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLSocket;
import javax.net.ssl.SSLSocketFactory;
import javax.net.ssl.TrustManager;
import javax.net.ssl.X509TrustManager;

import org.apache.tomcat.util.buf.ByteChunk;

/**
 * Requires:
 *  keytool -genkey -alias tomcat -keyalg RSA
 *  pass: changeit
 *  CN: localhost ( for hostname validation )
 */
public class TestTomcatSSL extends TomcatBaseTest {
    static TrustManager[] trustAllCerts = new TrustManager[] {
        new X509TrustManager() {
            public java.security.cert.X509Certificate[] getAcceptedIssuers() {
                return null;
            }
            public void checkClientTrusted(java.security.cert.X509Certificate[] certs, String authType) {
            }
            public void checkServerTrusted(java.security.cert.X509Certificate[] certs, String authType) {
            }
        }
    };

    static {
        //  Install the all-trusting trust manager
        try {
            SSLContext sc = SSLContext.getInstance("SSL");
            sc.init(null, trustAllCerts, new java.security.SecureRandom());
            javax.net.ssl.HttpsURLConnection.setDefaultSSLSocketFactory(
                    sc.getSocketFactory());
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    public void testHandshake() throws Exception {
        Tomcat tomcat = getTomcatInstance();

        File appDir =
            new File("output/build/webapps/examples");
        // app dir is relative to server home
        tomcat.addWebapp(null, "/examples", appDir.getAbsolutePath());

        tomcat.getConnector().setSecure(true);
        tomcat.getConnector().setProperty("SSLEnabled", "true");
        tomcat.getConnector().setProperty("sslProtocol",
        "tls");

        tomcat.start();
        ByteChunk res = getUrl("https://localhost:" + getPort() +
        "/examples/servlets/servlet/HelloWorldExample");
        assertTrue(res.toString().indexOf("<h1>Hello World!</h1>") > 0);
    }

    public void testReHandshake() throws Exception {
        Tomcat tomcat = getTomcatInstance();

        File appDir =
            new File("output/build/webapps/examples");
        // app dir is relative to server home
        tomcat.addWebapp(null, "/examples", appDir.getAbsolutePath());

        tomcat.getConnector().setSecure(true);
        tomcat.getConnector().setProperty("SSLEnabled", "true");
        tomcat.getConnector().setProperty("sslProtocol",
        "tls");

        tomcat.start();
        SSLContext sslCtx = SSLContext.getInstance("TLS");
        sslCtx.init(null, trustAllCerts, new java.security.SecureRandom());
        SSLSocketFactory socketFactory = sslCtx.getSocketFactory();
        SSLSocket socket = (SSLSocket) socketFactory.createSocket("localhost", getPort());

        socket.addHandshakeCompletedListener(new HandshakeCompletedListener() {

            @Override
            public void handshakeCompleted(HandshakeCompletedEvent event) {
                System.err.println("Handshake done");
            }
           
        });
        OutputStream os = socket.getOutputStream();
        os.write("GET /examples/servlets/servlet/HelloWorldExample HTTP/1.0\n".getBytes());
       
        socket.getSession().invalidate();
        socket.startHandshake();
       
        os.write("Host: localhost\n\n".getBytes());
       
        InputStream is = socket.getInputStream();
        ByteChunk out = new ByteChunk();
        BufferedInputStream bis = new BufferedInputStream(is);
        byte[] buf = new byte[2048];
        int rd = 0;
        while((rd = bis.read(buf)) > 0) {
            out.append(buf, 0, rd);
        }
        assertTrue(out.toString().indexOf("<h1>Hello World!</h1>") > 0);
       
    }
}

---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Costin Manolache-2]

Unless someone has a better solution - I'll submit the fix ( tonight ), will
disable re-negotiation for
Jsse-mode.
I added a system property to allow people how don't care about this, IMO by
default it should
be on.

Also got the test case to work - please let me know if it's acceptable to
commit it, it depends
on having a .keystore with a 'localhost' cert, didn't find any other SSL
tests in the suite.
Forgot that you need to read() after startHandshake() - just cut&pasted the
code from
JsseSupport and it worked.


Costin

On Mon, Nov 9, 2009 at 1:32 PM, Costin Manolache <costin@...> wrote:

>
>
> On Mon, Nov 9, 2009 at 10:47 AM, Costin Manolache <costin@...>wrote:
>
>>
>>
>> On Mon, Nov 9, 2009 at 8:04 AM, Konstantin Kolinko <
>> knst.kolinko@...> wrote:
>>
>>> 2009/11/9 Mark Thomas <markt@...>:
>>> > Summarising the information gathered so far from various channels
>>> > (thanks to Bill B., Bill W. & Rainer who have done most of the actual
>>> > work to find the info below).
>>> >
>>> > BIO/NIO connectors using JSSE.
>>> > Vulnerable when renegotiation is triggered by the client or server.
>>> > We could prevent server initiated renegotiation (and probably break the
>>> > majority of configurations using CLIENT-CERT).
>>> > We can't do anything to prevent client initiated renegotiation.
>>> >
>>> > APR/native connector using OpenSSL
>>> > It is vulnerable when renegotiation is triggered by the client or by
>>> the
>>> > server.
>>> > Client triggered negotiation is supported.
>>> > Server triggered negotiation will be supported from 1.1.17 onwards.
>>> >
>>> > OpenSSL 0.9.8l disables negotiation by default
>>> >
>>> >
>>> > In terms of what this means for users:
>>> >
>>> > BIO/NIO
>>> > - There isn't anything we can do in Tomcat to stop client
>>> >  initiated renegotiation so it is a case of waiting for the JVM
>>> >  vendors to respond.
>>> >
>>> > APR/native
>>> > - Re-building their current version with 0.9.8l will protect
>>> >  users at the risk of breaking any configurations that
>>> >  require renegotiation.
>>> > - We can release 1.1.17 with the binaries built with 0.9.8l. This
>>> >  will also protect users at the risk of breaking any
>>> >  configurations that require renegotiation. Mladen is doing this
>>> >  now.
>>> > - Supporting renegotiation whilst avoiding the vulnerability will
>>> >  require a protocol fix. In the meantime, we could port port
>>> >  r833582 from httpd which would disable client triggered
>>> >  renegotiation for OpenSSL < 0.9.8l (which may help some users
>>> >  who can't easily change their OpenSSl version and release 1.1.18
>>> >  with this fix
>>> > - Once the protocol is fixed, release 1.1.next bundled with the
>>> >  appropriate version of OpenSSL
>>> >
>>> >
>>> > Have I got my facts right above? If so, any objections to posting the
>>> > above to the users@ and announce@ lists along with adding something to
>>> > the security pages?
>>> >
>>> > Mark
>>> >
>>>
>>> +1
>>>
>>> s/negotiation/renegotiation/
>>> s/port port/port/
>>>
>>> A question:
>>> My understanding of renegotiation is that it changes SSL session. Is
>>> it possible to observe changes in the value of SSL sessionId?  I doubt
>>> so, but may be?
>>>
>>
>> AFAIK you can reuse the session ID across negotiations ( it's a nice
>> optimization BTW, too
>> bad we're not using, it can speed up SSL connections a lot ), I'm not sure
>> if it changes
>> within a renegotation, but AFAIK when you start any negotiation you can
>> specify you want
>> to reuse the old session id.  But if I understand the exploit correctly -
>> they would want a different
>> cypher, and if you reuse the session you reuse the old one.
>>
>>
>> Maybe we can modify JSSESupport.Listener to break the connection if
>> handshakeCompleted is
>> called > once in a connection ? That is besides disabling server-initiated
>> handshakes.
>>
>>
>
> BTW - confirmed that JSSESupport.Listener is called when client does
> re-negotiate, but it is not called on the first
> negotiation ( it's added too late ).
>
> However it's pretty easy to add a listener earlier, patch attached - it
> should break all client re-negotiations, so we don't need
> to wait for a JDK fix.
>
> I wrote a small unit test - but I'm can't seem to get jsse client to
> re-negotiate for the test, can only do it using command line
> openssl. The patch seems to work - but you need so system properties  or
> flags if we want to let people
>  disable this ( "allowManInTheMiddle" is a good name for a flag ).  Also
> the test needs a bit of work.
>
> If anyone has more time, my 20% is getting low ....
>
>
> Costin
>
>
>
>> Costin
>>
>>
>>
>>> We read that value once and provide it to our users as
>>> "javax.servlet.request.ssl_session" request attribute.
>>>
>>> Regarding valves (as mentioned in issue 48157):
>>> I understand, that that is not sufficient, but if anyone wants to
>>> check against malformed headers, they can do so.
>>>
>>> Best regards,
>>> Konstantin Kolinko
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>> For additional commands, e-mail: dev-help@...
>>>
>>>
>>
>

[markt-2]

Costin Manolache wrote:
> Unless someone has a better solution - I'll submit the fix ( tonight ), will
> disable re-negotiation for
> Jsse-mode.
> I added a system property to allow people how don't care about this, IMO by
> default it should
> be on.

Sounds good. Any chance it could be a connector property rather than a
system property? If you don't have a chance to do this I can always make
that change (and do some testing) tomorrow.

> Also got the test case to work - please let me know if it's acceptable to
> commit it, it depends
> on having a .keystore with a 'localhost' cert, didn't find any other SSL
> tests in the suite.

Add the keystore to svn as well. That way, the test should always work.

> Forgot that you need to read() after startHandshake() - just cut&pasted the
> code from
> JsseSupport and it worked.

Mark

> Costin
>
> On Mon, Nov 9, 2009 at 1:32 PM, Costin Manolache <costin@...> wrote:
>
>>
>> On Mon, Nov 9, 2009 at 10:47 AM, Costin Manolache <costin@...>wrote:
>>
>>>
>>> On Mon, Nov 9, 2009 at 8:04 AM, Konstantin Kolinko <
>>> knst.kolinko@...> wrote:
>>>
>>>> 2009/11/9 Mark Thomas <markt@...>:
>>>>> Summarising the information gathered so far from various channels
>>>>> (thanks to Bill B., Bill W. & Rainer who have done most of the actual
>>>>> work to find the info below).
>>>>>
>>>>> BIO/NIO connectors using JSSE.
>>>>> Vulnerable when renegotiation is triggered by the client or server.
>>>>> We could prevent server initiated renegotiation (and probably break the
>>>>> majority of configurations using CLIENT-CERT).
>>>>> We can't do anything to prevent client initiated renegotiation.
>>>>>
>>>>> APR/native connector using OpenSSL
>>>>> It is vulnerable when renegotiation is triggered by the client or by
>>>> the
>>>>> server.
>>>>> Client triggered negotiation is supported.
>>>>> Server triggered negotiation will be supported from 1.1.17 onwards.
>>>>>
>>>>> OpenSSL 0.9.8l disables negotiation by default
>>>>>
>>>>>
>>>>> In terms of what this means for users:
>>>>>
>>>>> BIO/NIO
>>>>> - There isn't anything we can do in Tomcat to stop client
>>>>>  initiated renegotiation so it is a case of waiting for the JVM
>>>>>  vendors to respond.
>>>>>
>>>>> APR/native
>>>>> - Re-building their current version with 0.9.8l will protect
>>>>>  users at the risk of breaking any configurations that
>>>>>  require renegotiation.
>>>>> - We can release 1.1.17 with the binaries built with 0.9.8l. This
>>>>>  will also protect users at the risk of breaking any
>>>>>  configurations that require renegotiation. Mladen is doing this
>>>>>  now.
>>>>> - Supporting renegotiation whilst avoiding the vulnerability will
>>>>>  require a protocol fix. In the meantime, we could port port
>>>>>  r833582 from httpd which would disable client triggered
>>>>>  renegotiation for OpenSSL < 0.9.8l (which may help some users
>>>>>  who can't easily change their OpenSSl version and release 1.1.18
>>>>>  with this fix
>>>>> - Once the protocol is fixed, release 1.1.next bundled with the
>>>>>  appropriate version of OpenSSL
>>>>>
>>>>>
>>>>> Have I got my facts right above? If so, any objections to posting the
>>>>> above to the users@ and announce@ lists along with adding something to
>>>>> the security pages?
>>>>>
>>>>> Mark
>>>>>
>>>> +1
>>>>
>>>> s/negotiation/renegotiation/
>>>> s/port port/port/
>>>>
>>>> A question:
>>>> My understanding of renegotiation is that it changes SSL session. Is
>>>> it possible to observe changes in the value of SSL sessionId?  I doubt
>>>> so, but may be?
>>>>
>>> AFAIK you can reuse the session ID across negotiations ( it's a nice
>>> optimization BTW, too
>>> bad we're not using, it can speed up SSL connections a lot ), I'm not sure
>>> if it changes
>>> within a renegotation, but AFAIK when you start any negotiation you can
>>> specify you want
>>> to reuse the old session id.  But if I understand the exploit correctly -
>>> they would want a different
>>> cypher, and if you reuse the session you reuse the old one.
>>>
>>>
>>> Maybe we can modify JSSESupport.Listener to break the connection if
>>> handshakeCompleted is
>>> called > once in a connection ? That is besides disabling server-initiated
>>> handshakes.
>>>
>>>
>> BTW - confirmed that JSSESupport.Listener is called when client does
>> re-negotiate, but it is not called on the first
>> negotiation ( it's added too late ).
>>
>> However it's pretty easy to add a listener earlier, patch attached - it
>> should break all client re-negotiations, so we don't need
>> to wait for a JDK fix.
>>
>> I wrote a small unit test - but I'm can't seem to get jsse client to
>> re-negotiate for the test, can only do it using command line
>> openssl. The patch seems to work - but you need so system properties  or
>> flags if we want to let people
>>  disable this ( "allowManInTheMiddle" is a good name for a flag ).  Also
>> the test needs a bit of work.
>>
>> If anyone has more time, my 20% is getting low ....
>>
>>
>> Costin
>>
>>
>>
>>> Costin
>>>
>>>
>>>
>>>> We read that value once and provide it to our users as
>>>> "javax.servlet.request.ssl_session" request attribute.
>>>>
>>>> Regarding valves (as mentioned in issue 48157):
>>>> I understand, that that is not sufficient, but if anyone wants to
>>>> check against malformed headers, they can do so.
>>>>
>>>> Best regards,
>>>> Konstantin Kolinko
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>>> For additional commands, e-mail: dev-help@...
>>>>
>>>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Rainer Jung-3]

On 10.11.2009 01:17, Mark Thomas wrote:

> Costin Manolache wrote:
>> Unless someone has a better solution - I'll submit the fix ( tonight ), will
>> disable re-negotiation for
>> Jsse-mode.
>> I added a system property to allow people how don't care about this, IMO by
>> default it should
>> be on.
>
> Sounds good. Any chance it could be a connector property rather than a
> system property? If you don't have a chance to do this I can always make
> that change (and do some testing) tomorrow.
>
>> Also got the test case to work - please let me know if it's acceptable to
>> commit it, it depends
>> on having a .keystore with a 'localhost' cert, didn't find any other SSL
>> tests in the suite.
>
> Add the keystore to svn as well. That way, the test should always work.
>
>> Forgot that you need to read() after startHandshake() - just cut&pasted the
>> code from
>> JsseSupport and it worked.

+1 to everything

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...