Hi !
actually, I'm responsible for that.
based on the information I received, and the informations I grab from
the internet, I thought tht we were safe.
My mistake. The opened JIRA, where it was explicitely said that doing a
test prove that we are not protected against POODLE (and I tested it
myself).
Ok, now, what's the plan ?
There is a solution : we have to provide the SslEngine with the list of
protocol that it should accept, excluding the ones that we don't want to
support (here, SSLV3). This boils down to doing something like :
sslEngine.setEnabledProtocols(new String[]{ "TLSv1", "TLSv1.1",
"TLSv1.2" });
Sadly, this is not a part of ApacheDS, but it's a part of MINA. And
sadly, we can't pass the list of protocols to MINA, because MINA
currently does not expose this in its API.
But hopefully, I'm a MINA committer, so I can change this !
Bottom line, I'll add an extension point in MINA which will allow us to
inject the list of supported protocol to teh SslEngine, then I'll change
the server to provide the list of protocol we want to use, and test it.
If it's safe, then I'll cut a quick release (ie, 24h notice instead of
72h). The good thing is that MINA 2.0.9 has been released 2 weeks ago,
and all the apache DS component have been released last week, so there
is no other important changes that needs to be checked.
Wdyt ?
Le 18/11/14 23:52, Pierre Smits a écrit :
> Hi All,
>
> We (as a community) thank you for having persisted, conducted tests and
> shared with us your finding regarding the POODLE threat that is affecting
> our Apache Directory Server up to current released milestone (2.0.0-M18).
>
> We have found that a piece of software that we have taken from another open
> source project and use a core element in our solution is creating this
> issue. We are now working very hard to get a new milestone release out that
> will ensure that remove this threat.
>
> For more information regarding the POODLE threat and our Apache Directory
> Server, have a look at:
> https://issues.apache.org/jira/browse/DIRSERVER-2020. Please share your
> concerns and insights there.
>
> On behalf of the community, thank you.
>
> Regards,
>
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Fri, Nov 14, 2014 at 11:17 AM, <[email protected]> wrote:
>
>> Hi Emmanuel,
>>
>> well I asked the question again because I was not sure whether TLS just
>> set as the protocol for the SSLConnext or the usage of TLS additionally is
>> enforced.
>>
>> However, thanks for the clarification. We will switch to a newer version.
>>
>> Best regards,
>> Shushant
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Emmanuel Lécharny [mailto:[email protected]]
>> Gesendet: Freitag, 14. November 2014 11:04
>> An: [email protected]
>> Betreff: Re: AW: [ApacheDS] Disable usage of SSL (SSLv2 and SSL v3)
>> protocol
>>
>> Le 14/11/14 10:55, [email protected] a écrit :
>>> Hi,
>>>
>>> Well we use Java 1.7.0_71.
>>>
>>> The Security Advisory states “However, even if a client and server both
>> support a version of TLS, the security level offered by SSL 3.0 is still
>> relevant since many clients implement a protocol downgrade dance to work
>> around serverside interoperability bugs.”
>>> The recommendation is to disable SSLv3 either on client or serverside to
>> completely avoid an attack. We would like to do that on our serverside.
>>
>> It *is* already disabled, as we enfore the use of TLS.
>>
>> I already said that two times. Asking a third time will not bring you any
>> more comfort.
>>
>> At this point, I would suggest you check the code by yourself, and if you
>> find some place where you think that SSL v3 can still be used, then fill a
>> JIRA, and we will be very pleased to apply a patch in trunk. Also keep in
>> mind that ApacheDS 1.0 is not anymore maintained, so I strongly suggest you
>> either switch to ApacheDS 2.0, or you are totally on your own.
>>
