<div dir="ltr">Your assumption in this case is that the LDAP servers are locked down only to the network and not wide open to the world to support use-cases such as client-side address-books. If the LDAP service is open to the world, you're right back at starbucks on the open WIFI and have good reason to immediately shut down SSLv3.<div><br></div><div>Dave</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 16, 2014 at 12:23 AM, Rhys Smith <span dir="ltr"><<a href="mailto:Smith@cardiff.ac.uk" target="_blank">Smith@cardiff.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Disclaimer: I’ve only had time to have a quick glance through how POODLE works, so please correct me if I’m wrong everybody!<br>
<br>
With the caveat of that disclaimer - It should be said for those reading this who are panicking about their ldaps connections, from what I understand the POODLE attack requires:<br>
a) the attacker being able to intercept traffic<br>
b) a client that will downgrade from TLS1 to SSLv3<br>
c) to be able to inject data into the connection to make the client retry.<br>
<br>
So, for those running doing web browser stuff over the wifi in starbucks where the client is a web browser which does javascript, this is bad. For an LDAP connection on a relatively secure corporate network where the client is a set of LDAP libraries, this is less bad.<br>
<br>
Not saying people shouldn’t be considering disabling SSLv3 everywhere now, just that I don’t think there are really known attack vectors for poodle in the ldaps circumstance - yet. So web servers should be switching off SSLv3 support now, but LDAP servers on corporate networks… we probably have a bit of time to sort this out in a more orderly manner with a bit more testing and thought before we turn off SSLv3 support.<br>
<br>
Anyway, just my 2c, and happy to be corrected (well, not happy per se, as it’ll make everyone’s lives more difficult!).<br>
Rhys.<br>
--<br>
Dr Rhys Smith<br>
Identity, Access, and Middleware Specialist<br>
Cardiff University & Janet, the UK's research and education network<br>
<br>
email: <a href="mailto:smith@cardiff.ac.uk">smith@cardiff.ac.uk</a> / <a href="mailto:rhys.smith@ja.net">rhys.smith@ja.net</a><br>
GPG: 0x4638C985<br>
<div class="HOEnZb"><div class="h5"><br>
On 16 Oct 2014, at 04:50, Daniel Fisher <<a href="mailto:dfisher@vt.edu">dfisher@vt.edu</a>> wrote:<br>
<br>
> On Wed, Oct 15, 2014 at 3:56 PM, Cantor, Scott <<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</a>> wrote:<br>
>> On 10/15/14, 3:30 PM, "Wessel, Keith" <<a href="mailto:kwessel@illinois.edu">kwessel@illinois.edu</a>> wrote:<br>
>><br>
>>> Hi, all,<br>
>>><br>
>>> Our AD folks just turned off SSLv3 support on our AD LDAPS service. Shib<br>
>>> didn¹t like it.<br>
>><br>
>> A little quick searching implies to me that the<br>
>> java.naming.security.protocol JNDI property is what controls this in Java,<br>
>> and the only value it appears to have is ssl [1]. Which probably means it<br>
>> doesn't support TLS.<br>
>><br>
>> There is no actual standard for running LDAP over SSL, and I think the way<br>
>> TLS is handled is with StartTLS, and that's probably why Java doesn't<br>
>> support it.<br>
>><br>
>> Daniel probably knows the specifics, but offhand I'd say it's apparently<br>
>> time to dump ldaps or somebody will need to complain to Oracle.<br>
>><br>
><br>
> You should be able to use either the SSLv3 or TLSv1 protocols with<br>
> LDAPS or startTLS.<br>
> I'll do some more testing tomorrow to confirm.<br>
> We're considering disabling SSLv3 support on our directories as well.<br>
><br>
> --Daniel Fisher<br>
> --<br>
> To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
<br>
</div></div><br>--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br>David Langenberg<div>Identity & Access Management</div><div>The University of Chicago</div>
</div>