Shib IDP's LDAPS attribute resolution and SSLv3

[Wessel, Keith]

Hi, all,

Our AD folks just turned off SSLv3 support on our AD LDAPS service. Shib didn't like it.

13:44:08.766 - ERROR [edu.vt.middleware.ldap.pool.DefaultLdapFactory:109] [session=296a318ae3b59564bf94f8fb50fee6ef4a93ecd3716f7574556b0a6715c65b97]
- unabled to connect to the ldap
javax.naming.ServiceUnavailableException: host.name.removed:636; socket closed
at com.sun.jndi.ldap.Connection.readReply(Connection.java:454) ~[na:1.7.0_60]
at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:364) ~[na:1.7.0_60]
at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:213) ~[na:1.7.0_60]
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2740) ~[na:1.7.0_60]
at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:316) ~[na:1.7.0_60]
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193)
~[na:1.7.0_60]
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211)
~[na:1.7.0_60]
at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154)
~[na:1.7.0_60]
at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84)
~[na:1.7.0_60]
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
~[na:1.7.0_60]
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307)
~[na:1.7.0_60]
at javax.naming.InitialContext.init(InitialContext.java:242) ~[na:1.7.0_60]
at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:153)
~[na:1.7.0_60]
at edu.vt.middleware.ldap.handler.DefaultConnectionHandler.connectInternal(DefaultConnectionHandler.java:134)
~[vt-ldap-3.3.8.jar:na]
at edu.vt.middleware.ldap.handler.AbstractConnectionHandler.connect(AbstractConnectionHandler.java:156)
~[vt-ldap-3.3.8.jar:na]
at edu.vt.middleware.ldap.AbstractLdap.connect(AbstractLdap.java:1006) ~[vt-ldap-3.3.8.jar:na]
at edu.vt.middleware.ldap.pool.DefaultLdapFactory.create(DefaultLdapFactory.java:106)
[vt-ldap-3.3.8.jar:na]
at edu.vt.middleware.ldap.pool.DefaultLdapFactory.create(DefaultLdapFactory.java:28)
[vt-ldap-3.3.8.jar:na]
at edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.dataConnector.LdapPoolEmptyStrategy.checkOut(LdapPoolEmptyStrategy.java:92)
[shibboleth-common-1.4.2.jar:na]
at edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.dataConnector.LdapDataConnector.searchLdap(LdapDataConnector.java:367)
[shibboleth-common-1.4.2.jar:na]
at edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.dataConnector.LdapDataConnector.resolve(LdapDataConnector.java:315)
[shibboleth-common-1.4.2.jar:na]
at edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.dataConnector.LdapDataConnector.resolve(LdapDataConnector.java:50)
[shibboleth-common-1.4.2.jar:na]
at edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.dataConnector.ContextualDataConnector.resolve(ContextualDataConnector.java:77)
[shibboleth-common-1.4.2.jar:na]
at edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.dataConnector.ContextualDataConnector.resolve(ContextualDataConnector.java:31)
[shibboleth-common-1.4.2.jar:na]
at edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver.resolveDataConnector(ShibbolethAttributeResolver.java:374)
[shibboleth-common-1.4.2.jar:na]
at edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver.resolveDependencies(ShibbolethAttributeResolver.java:410)
[shibboleth-common-1.4.2.jar:na]
at edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver.resolveAttribute(ShibbolethAttributeResolver.java:332)
[shibboleth-common-1.4.2.jar:na]
at edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver.resolveAttributes(ShibbolethAttributeResolver.java:284)
[shibboleth-common-1.4.2.jar:na]
at edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.ShibbolethAttributeResolver.resolveAttributes(ShibbolethAttributeResolver.java:131)
[shibboleth-common-1.4.2.jar:na]
at edu.internet2.middleware.shibboleth.common.attribute.provider.ShibbolethSAML2AttributeAuthority.getAttributes(ShibbolethSAML2AttributeAuthority.java:175)
[shibboleth-common-1.4.2.jar:na]
at edu.internet2.middleware.shibboleth.common.attribute.provider.ShibbolethSAML2AttributeAuthority.getAttributes(ShibbolethSAML2AttributeAuthority.java:59)
[shibboleth-common-1.4.2.jar:na]
at edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler.resolveAttributes(AbstractSAML2ProfileHandler.java:480)
[shibboleth-identityprovider-2.4.2.jar:na]
at edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler.completeAuthenticationRequest(SSOProfileHandler.java:307)
[shibboleth-identityprovider-2.4.2.jar:na]
at edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler.processRequest(SSOProfileHandler.java:173)
[shibboleth-identityprovider-2.4.2.jar:na]
at edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler.processRequest(SSOProfileHandler.java:90)
[shibboleth-identityprovider-2.4.2.jar:na]
at edu.internet2.middleware.shibboleth.common.profile.ProfileRequestDispatcherServlet.service(ProfileRequestDispatcherServlet.java:83)
[shibboleth-common-1.4.2.jar:na]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:723) [servlet-api.jar:na]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
[catalina.jar:6.0.41]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
[catalina.jar:6.0.41]
at net.clareitysecurity.shibboleth.storage.ClusterFilter.doFilter(ClusterFilter.java:95)
[db-storage-service-1.1.3.jar:na]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
[catalina.jar:6.0.41]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
[catalina.jar:6.0.41]
at edu.internet2.middleware.shibboleth.idp.util.NoCacheFilter.doFilter(NoCacheFilter.java:50)
[shibboleth-identityprovider-2.4.2.jar:na]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
[catalina.jar:6.0.41]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
[catalina.jar:6.0.41]
at edu.internet2.middleware.shibboleth.idp.session.IdPSessionFilter.doFilter(IdPSessionFilter.java:87)
[shibboleth-identityprovider-2.4.2.jar:na]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
[catalina.jar:6.0.41]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
[catalina.jar:6.0.41]
at edu.internet2.middleware.shibboleth.common.log.SLF4JMDCCleanupFilter.doFilter(SLF4JMDCCleanupFilter.java:52)
[shibboleth-common-1.4.2.jar:na]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
[catalina.jar:6.0.41]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
[catalina.jar:6.0.41]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219)
[catalina.jar:6.0.41]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
[catalina.jar:6.0.41]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
[catalina.jar:6.0.41]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
[catalina.jar:6.0.41]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
[catalina.jar:6.0.41]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
[catalina.jar:6.0.41]
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
[tomcat-coyote.jar:6.0.41]
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:311) [tomcat-coyote.jar:6.0.41]
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:776) [tomcat-coyote.jar:6.0.41]
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:705)
[tomcat-coyote.jar:6.0.41]
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:898)
[tomcat-coyote.jar:6.0.41]
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
[tomcat-coyote.jar:6.0.41]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_60]

Socket closed doesn't tell me much, but as soon as they turned SSLv3 back on, things worked again. I did some OpenSSL snooping, and the LDAPS service does seem to support SSLv3 and TLS v1.0/1.1/1.2.

Based on the fairly obvious theory that the IDP is only using SSL v3, are their any ways to make it use TLS v1?

Or might it be something completely different? Should this have still worked?

Keith

[Nate Klingenstein]

Keith,

I'd start my investigation with the hostname checks that Shibboleth had to add recently. host.name.removed is pretty suspicious, but I don't know where that code is. It's the first thing I'd look for.

http://shibboleth.net/community/advisories/secadv_20140919.txt

Dunno,
Nate.

On Oct 15, 2014, at 1:30 PM, Wessel, Keith <kwessel-nzINlOoChub2fBVCVOL8/***@public.gmane.org<mailto:kwessel-nzINlOoChub2fBVCVOL8/***@public.gmane.org>> wrote:

13:44:08.766 - ERROR [edu.vt.middleware.ldap.pool.DefaultLdapFactory:109] [session=296a318ae3b59564bf94f8fb50fee6ef4a93ecd3716f7574556b0a6715c65b97]
- unabled to connect to the ldap
javax.naming.ServiceUnavailableException: host.name.removed:636; socket closed

[Wessel, Keith]

Sorry, Nate, host.name.removed was me. I pull out our real ldap server hostname before posting to the list.

We are running V2.4.2 as of this past Monday, so that's not the case here.

Keith


From: users-bounces-***@public.gmane.org [mailto:users-bounces-***@public.gmane.org] On Behalf Of Nate Klingenstein
Sent: Wednesday, October 15, 2014 2:36 PM
To: Shib Users
Subject: Re: Shib IDP's LDAPS attribute resolution and SSLv3

Keith,

I'd start my investigation with the hostname checks that Shibboleth had to add recently. host.name.removed is pretty suspicious, but I don't know where that code is. It's the first thing I'd look for.

http://shibboleth.net/community/advisories/secadv_20140919.txt

Dunno,
Nate.

On Oct 15, 2014, at 1:30 PM, Wessel, Keith <kwessel-nzINlOoChub2fBVCVOL8/***@public.gmane.org<mailto:kwessel-nzINlOoChub2fBVCVOL8/***@public.gmane.org>> wrote:


13:44:08.766 - ERROR [edu.vt.middleware.ldap.pool.DefaultLdapFactory:109] [session=296a318ae3b59564bf94f8fb50fee6ef4a93ecd3716f7574556b0a6715c65b97]
- unabled to connect to the ldap
javax.naming.ServiceUnavailableException: host.name.removed:636; socket closed

[Nate Klingenstein]

Sorry, Nate, host.name.removed was me. I pull out our real ldap server hostname before posting to the list.

Ah, okay, thanks. This will probably have to wait for one of the developers then.

We are running V2.4.2 as of this past Monday, so that’s not the case here.

Yep, that'd be consistent with your logs, it looks like. I was more worried about the newly added code in Shibboleth not being compatible with SSLv3 being off. But really, I have no idea. That was just a hunch. For me, real stacktrace problems start getting fixed by tracing the stack, I guess, and the devs can do that faster and better than me.

[Cantor, Scott]

Post by Wessel, Keith
Hi, all,
Our AD folks just turned off SSLv3 support on our AD LDAPS service. Shib
didn¹t like it.

A little quick searching implies to me that the
java.naming.security.protocol JNDI property is what controls this in Java,
and the only value it appears to have is ssl [1]. Which probably means it
doesn't support TLS.

There is no actual standard for running LDAP over SSL, and I think the way
TLS is handled is with StartTLS, and that's probably why Java doesn't
support it.

Daniel probably knows the specifics, but offhand I'd say it's apparently
time to dump ldaps or somebody will need to complain to Oracle.

-- Scott

[1]
http://docs.oracle.com/javase/7/docs/technotes/guides/jndi/jndi-ldap.html

[Cantor, Scott]

Post by Cantor, Scott

Post by Wessel, Keith
Hi, all,
Our AD folks just turned off SSLv3 support on our AD LDAPS service. Shib
didn¹t like it.

A little quick searching implies to me that the
java.naming.security.protocol JNDI property is what controls this in Java,
and the only value it appears to have is ssl [1]. Which probably means it
doesn't support TLS.

Of course I find this strange and surprising, but if you're seeing it not
work, I don't know what other conclusion to reach.

-- Scott

[Nate Klingenstein]

Of course I find this strange and surprising, but if you're seeing it not
work, I don't know what other conclusion to reach.

Your conclusion makes sense to me, though the fact is pretty shocking. It appears to be true of Jave 8 as well.

http://docs.oracle.com/javase/8/docs/technotes/guides/jndi/jndi-ldap-gl.html#protocol

Are other Java webapps using ldaps:// URL's having problems?

[Wessel, Keith]

Thanks, Scott. I was afraid that'd be the answer.

My AD admin is suggesting we do our query over LDAP (cleartext) but with Kerberos-based LDAP authentication so we're not authenticating cleartext. I suspect the library's not capable of this, either. Does anyone know otherwise? Otherwise, time to see how AD handles starttls.

Keith


-----Original Message-----
From: users-bounces-***@public.gmane.org [mailto:users-bounces-***@public.gmane.org] On Behalf Of Cantor, Scott
Sent: Wednesday, October 15, 2014 3:00 PM
To: Shib Users
Subject: Re: Shib IDP's LDAPS attribute resolution and SSLv3

Post by Cantor, Scott

Post by Wessel, Keith
Hi, all,
Our AD folks just turned off SSLv3 support on our AD LDAPS service. Shib
didn¹t like it.

A little quick searching implies to me that the
java.naming.security.protocol JNDI property is what controls this in Java,
and the only value it appears to have is ssl [1]. Which probably means it
doesn't support TLS.

Of course I find this strange and surprising, but if you're seeing it not
work, I don't know what other conclusion to reach.

-- Scott

[Dave Perry]

FWIW, our IdP binds to AD using a ldap:// URL and a service login we had created (same as other web services, like moodle) and then tries to do the login. No startTLS involved, and they're happy with that (IdP is in a DMZ, and has a translated IP address to access our domain controllers).

Dave

_________________________________________________
Dave Perry
eLearning Technologist, Hull College Group

Room L34 - Queens Gardens Library
Wilberforce Drive, Queen's Gardens, Hull, HU1 3DG
Extension 2230 / Direct Dial 01482 381930

* Need a fast reply? Try elearning-NOSDTyrR4+***@public.gmane.org *

-----Original Message-----
From: users-bounces-***@public.gmane.org [mailto:users-bounces-***@public.gmane.org] On Behalf Of Wessel, Keith
Sent: 15 October 2014 21:10
To: Shib Users
Subject: RE: Shib IDP's LDAPS attribute resolution and SSLv3

Thanks, Scott. I was afraid that'd be the answer.

My AD admin is suggesting we do our query over LDAP (cleartext) but with Kerberos-based LDAP authentication so we're not authenticating cleartext. I suspect the library's not capable of this, either. Does anyone know otherwise? Otherwise, time to see how AD handles starttls.

Keith


-----Original Message-----
From: users-bounces-***@public.gmane.org [mailto:users-bounces-***@public.gmane.org] On Behalf Of Cantor, Scott
Sent: Wednesday, October 15, 2014 3:00 PM
To: Shib Users
Subject: Re: Shib IDP's LDAPS attribute resolution and SSLv3

Post by Cantor, Scott

Post by Wessel, Keith
Hi, all,
Our AD folks just turned off SSLv3 support on our AD LDAPS service.
Shib didn¹t like it.

A little quick searching implies to me that the
java.naming.security.protocol JNDI property is what controls this in
Java, and the only value it appears to have is ssl [1]. Which probably
means it doesn't support TLS.

Of course I find this strange and surprising, but if you're seeing it not work, I don't know what other conclusion to reach.

-- Scott

--
To unsubscribe from this list send an email to users-***@shibboleth.net
--
To unsubscribe from this list send an email to users-***@shibboleth.net

**********************************************************************
This message is sent in confidence for the addressee
only. It may contain confidential or sensitive
information. The contents are not to be disclosed
to anyone other than the addressee. Unauthorised
recipients are requested to preserve this
confidentiality and to advise us of any errors in
transmission. Any views expressed in this message
are solely the views of the individual and do not
represent the views of the College. Nothing in this
message should be construed as creating a contract.

Hull College owns the email infrastructure, including the contents.

Hull College is committed to sustainability, please reflect before printing this email.
**********************************************************************

TEXT

[Christopher Bongaarts]

Post by Cantor, Scott
A little quick searching implies to me that the
java.naming.security.protocol JNDI property is what controls this in Java,
and the only value it appears to have is ssl [1]. Which probably means it
doesn't support TLS.
There is no actual standard for running LDAP over SSL, and I think the way
TLS is handled is with StartTLS, and that's probably why Java doesn't
support it.
Daniel probably knows the specifics, but offhand I'd say it's apparently
time to dump ldaps or somebody will need to complain to Oracle.

The underlying JSSE support is there (in JDK6 for TLS1.1, JDK7 for
TLS1.2), so it might just be a matter of figuring out where to tweak
those settings... it's tricky here since we have multiple layers
involved (VT-ldap, JNDI, JSSE; plus repeat for the JAAS login handler if
you're using it).

[Cantor, Scott]

Post by Christopher Bongaarts
The underlying JSSE support is there (in JDK6 for TLS1.1, JDK7 for
TLS1.2), so it might just be a matter of figuring out where to tweak
those settings... it's tricky here since we have multiple layers
involved (VT-ldap, JNDI, JSSE; plus repeat for the JAAS login handler if
you're using it).

That's what I thought, so my next conclusion would be that they didn't
just turn off SSLv3, they turned off all support for ldaps on 636 without
realizing it.

-- Scott

[Charles Hedrick]

I didn’t set up our LDAP support initially, but it appears to use TLS. I guess it’s possible that it doesn’t actually work.

jaas.conf
edu.vt.middleware.ldap.jaas.LdapLoginModule required
ldapUrl="ldap://ldap.rutgers.edu ldap://ldap2.rutgers.edu"
base="ou=people,dc=rutgers,dc=edu"
tls="true"
userField="uid"
serviceUser=“xxxx"
serviceCredential=“xxxx";


attribute-resolver.xml
<resolver:DataConnector xsi:type="LDAPDirectory" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
id="myLDAP"
ldapURL="ldap://ldap.rutgers.edu ldap://ldap2.rutgers.edu"
baseDN="ou=people,dc=rutgers,dc=edu"
principal=“xxxx"
principalCredential=“xxxx"
useStartTLS="true">
<FilterTemplate>
<![CDATA[
(uid=$requestContext.principalName)
]]>
</FilterTemplate>
</resolver:DataConnector>

Post by Christopher Bongaarts

Post by Cantor, Scott
A little quick searching implies to me that the
java.naming.security.protocol JNDI property is what controls this in Java,
and the only value it appears to have is ssl [1]. Which probably means it
doesn't support TLS.
There is no actual standard for running LDAP over SSL, and I think the way
TLS is handled is with StartTLS, and that's probably why Java doesn't
support it.
Daniel probably knows the specifics, but offhand I'd say it's apparently
time to dump ldaps or somebody will need to complain to Oracle.

The underlying JSSE support is there (in JDK6 for TLS1.1, JDK7 for
TLS1.2), so it might just be a matter of figuring out where to tweak
those settings... it's tricky here since we have multiple layers
involved (VT-ldap, JNDI, JSSE; plus repeat for the JAAS login handler if
you're using it).
--
%% OIT - Identity Management %% http://umn.edu/~cab %%
%% University of Minnesota %% [phone] %%
--

[Cantor, Scott]

I didn¹t set up our LDAP support initially, but it appears to use TLS. I
guess it¹s possible that it doesn¹t actually work.

That's using startTLS.

-- Scott

[Wessel, Keith]

That's startTLS, not TLS protocol negocaton during the connection establishment. I'm hoping that also works on AD, trying it now.

Keith


From: users-bounces-***@public.gmane.org [mailto:users-bounces-***@public.gmane.org] On Behalf Of Charles Hedrick
Sent: Wednesday, October 15, 2014 3:26 PM
To: Shib Users
Subject: Re: Shib IDP's LDAPS attribute resolution and SSLv3

I didn't set up our LDAP support initially, but it appears to use TLS. I guess it's possible that it doesn't actually work.

jaas.conf
edu.vt.middleware.ldap.jaas.LdapLoginModule required
ldapUrl="ldap://ldap.rutgers.edu ldap://ldap2.rutgers.edu"
base="ou=people,dc=rutgers,dc=edu"
tls="true"
userField="uid"
serviceUser="xxxx"
serviceCredential="xxxx";


attribute-resolver.xml
<resolver:DataConnector xsi:type="LDAPDirectory" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
id="myLDAP"
ldapURL="ldap://ldap.rutgers.edu ldap://ldap2.rutgers.edu"
baseDN="ou=people,dc=rutgers,dc=edu"
principal="xxxx"
principalCredential="xxxx"
useStartTLS="true">
<FilterTemplate>
<![CDATA[
(uid=$requestContext.principalName)
]]>
</FilterTemplate>
</resolver:DataConnector>

On Oct 15, 2014, at 4:10 PM, Christopher Bongaarts <cab-***@public.gmane.org<mailto:***@umn.edu>> wrote:


On 10/15/2014 2:56 PM, Cantor, Scott wrote:

A little quick searching implies to me that the
java.naming.security.protocol JNDI property is what controls this in Java,
and the only value it appears to have is ssl [1]. Which probably means it
doesn't support TLS.

There is no actual standard for running LDAP over SSL, and I think the way
TLS is handled is with StartTLS, and that's probably why Java doesn't
support it.

Daniel probably knows the specifics, but offhand I'd say it's apparently
time to dump ldaps or somebody will need to complain to Oracle.

The underlying JSSE support is there (in JDK6 for TLS1.1, JDK7 for
TLS1.2), so it might just be a matter of figuring out where to tweak
those settings... it's tricky here since we have multiple layers
involved (VT-ldap, JNDI, JSSE; plus repeat for the JAAS login handler if
you're using it).

--
%% Christopher A. Bongaarts %% cab-***@public.gmane.org<mailto:cab-***@public.gmane.org> %%
%% OIT - Identity Management %% http://umn.edu/~cab %%
%% University of Minnesota %% [phone] %%

--
To unsubscribe from this list send an email to users-***@shibboleth.net<mailto:users-unsubscribe-***@public.gmane.org>

[Wessel, Keith]

If someone does find the options, I'd love to know about them.

In the meantime, it appears that recent versions of AD are happy supporting starttls on port 389, and that may have to do.

If anyone knows a way to change the sasl mechanism used by the LDAP library to gssapi, our AD admins would prefer I do what I said earlier: Kerberos authentication over the cleartext channel. Personally, this feels like more that could break moving forward than just using startTLS.

Keith


-----Original Message-----
From: users-bounces-***@public.gmane.org [mailto:users-bounces-***@public.gmane.org] On Behalf Of Christopher Bongaarts
Sent: Wednesday, October 15, 2014 3:11 PM
To: users-***@public.gmane.org
Subject: Re: Shib IDP's LDAPS attribute resolution and SSLv3

Post by Cantor, Scott
A little quick searching implies to me that the
java.naming.security.protocol JNDI property is what controls this in Java,
and the only value it appears to have is ssl [1]. Which probably means it
doesn't support TLS.
There is no actual standard for running LDAP over SSL, and I think the way
TLS is handled is with StartTLS, and that's probably why Java doesn't
support it.
Daniel probably knows the specifics, but offhand I'd say it's apparently
time to dump ldaps or somebody will need to complain to Oracle.

The underlying JSSE support is there (in JDK6 for TLS1.1, JDK7 for
TLS1.2), so it might just be a matter of figuring out where to tweak
those settings... it's tricky here since we have multiple layers
involved (VT-ldap, JNDI, JSSE; plus repeat for the JAAS login handler if
you're using it).

[Cantor, Scott]

Post by Wessel, Keith
If anyone knows a way to change the sasl mechanism used by the LDAP
Kerberos authentication over the cleartext channel. Personally, this
feels like more that could break moving forward than just using startTLS.

https://code.google.com/p/vt-middleware/wiki/vtldapGSSAPI

-- Scott

[Wessel, Keith]

Thanks, Scott and Paul. That page talks extensively about adding GSSAPI authentication to JAAS, but would I just pass the same options to the library inside my LDAP data connector definition?

Keith


-----Original Message-----
From: users-bounces-***@public.gmane.org [mailto:users-bounces-***@public.gmane.org] On Behalf Of Cantor, Scott
Sent: Wednesday, October 15, 2014 3:44 PM
To: Shib Users
Subject: Re: Shib IDP's LDAPS attribute resolution and SSLv3

Post by Wessel, Keith
If anyone knows a way to change the sasl mechanism used by the LDAP
Kerberos authentication over the cleartext channel. Personally, this
feels like more that could break moving forward than just using startTLS.

https://code.google.com/p/vt-middleware/wiki/vtldapGSSAPI

-- Scott

[Cantor, Scott]

Post by Wessel, Keith
Thanks, Scott and Paul. That page talks extensively about adding GSSAPI
authentication to JAAS, but would
I just pass the same options to the library inside my LDAP data
connector definition?

I have absolutely no idea. Using SASL with LDAP is very complex. I doubt
you could do it right now, you'd need to be able to configure lots of
underlying behavior in the LDAP client.

Using Kerberos to authenticate to AD is totally unrelated. That has
nothing to do with securing LDAP binds, which is what you're asking about.

-- Scott

[Wessel, Keith]

Correct. I thought this might be completely different, but I was hopeful that authentication was authentication. I've put my vote in here for startTLS since all it took was removing the s from ldaps:// and adding useStartTLS="true" to the data connector definition. Hopefully, that'll be what we do. Not only is it easier to do, but it'll keep query responses from coming across unencrypted.

Keith

-----Original Message-----
From: users-bounces-***@public.gmane.org [mailto:users-bounces-***@public.gmane.org] On Behalf Of Cantor, Scott
Sent: Wednesday, October 15, 2014 3:55 PM
To: Shib Users
Subject: Re: Shib IDP's LDAPS attribute resolution and SSLv3

Post by Wessel, Keith
Thanks, Scott and Paul. That page talks extensively about adding GSSAPI
authentication to JAAS, but would
I just pass the same options to the library inside my LDAP data
connector definition?

I have absolutely no idea. Using SASL with LDAP is very complex. I doubt
you could do it right now, you'd need to be able to configure lots of
underlying behavior in the LDAP client.

Using Kerberos to authenticate to AD is totally unrelated. That has
nothing to do with securing LDAP binds, which is what you're asking about.

-- Scott

[Rod Widdowson]

Post by Wessel, Keith
I've put my vote in here for startTLS since all
it took was removing the s from ldaps:// and adding useStartTLS="true" to

the

Post by Wessel, Keith
data connector definition. Hopefully, that'll be what we do. Not only is

it easier

Post by Wessel, Keith
to do, but it'll keep query responses from coming across unencrypted.

FWIW, and the record the Quick Installer has been using startTLS for both
JAAS and the attribute connector for some time now and nobody has complained
about it not working.

Rod

[Caskey, Paul]

FWIW, we've been doing Kerberos to AD using shibb for a while now, works fine (no pre-auth however).

Post by Wessel, Keith
-----Original Message-----
Sent: Wednesday, October 15, 2014 3:42 PM
To: Shib Users
Subject: RE: Shib IDP's LDAPS attribute resolution and SSLv3
If someone does find the options, I'd love to know about them.
In the meantime, it appears that recent versions of AD are happy supporting
starttls on port 389, and that may have to do.
If anyone knows a way to change the sasl mechanism used by the LDAP
Kerberos authentication over the cleartext channel. Personally, this feels like
more that could break moving forward than just using startTLS.
Keith
-----Original Message-----
Sent: Wednesday, October 15, 2014 3:11 PM
Subject: Re: Shib IDP's LDAPS attribute resolution and SSLv3

Post by Cantor, Scott
A little quick searching implies to me that the
java.naming.security.protocol JNDI property is what controls this in
Java, and the only value it appears to have is ssl [1]. Which probably
means it doesn't support TLS.
There is no actual standard for running LDAP over SSL, and I think the
way TLS is handled is with StartTLS, and that's probably why Java
doesn't support it.
Daniel probably knows the specifics, but offhand I'd say it's
apparently time to dump ldaps or somebody will need to complain to

Oracle.
The underlying JSSE support is there (in JDK6 for TLS1.1, JDK7 for TLS1.2), so it
might just be a matter of figuring out where to tweak those settings... it's
tricky here since we have multiple layers involved (VT-ldap, JNDI, JSSE; plus
repeat for the JAAS login handler if you're using it).
--
%% OIT - Identity Management %% http://umn.edu/~cab %%
%% University of Minnesota %% [phone] %%
--
To unsubscribe from this list send an email to users-
--
To unsubscribe from this list send an email to users-

[Daniel Fisher]

Post by Cantor, Scott

Post by Wessel, Keith
Hi, all,
Our AD folks just turned off SSLv3 support on our AD LDAPS service. Shib
didn¹t like it.

A little quick searching implies to me that the
java.naming.security.protocol JNDI property is what controls this in Java,
and the only value it appears to have is ssl [1]. Which probably means it
doesn't support TLS.
There is no actual standard for running LDAP over SSL, and I think the way
TLS is handled is with StartTLS, and that's probably why Java doesn't
support it.
Daniel probably knows the specifics, but offhand I'd say it's apparently
time to dump ldaps or somebody will need to complain to Oracle.

You should be able to use either the SSLv3 or TLSv1 protocols with
LDAPS or startTLS.
I'll do some more testing tomorrow to confirm.
We're considering disabling SSLv3 support on our directories as well.

--Daniel Fisher

[Rhys Smith]

Disclaimer: I’ve only had time to have a quick glance through how POODLE works, so please correct me if I’m wrong everybody!

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:
a) the attacker being able to intercept traffic
b) a client that will downgrade from TLS1 to SSLv3
c) to be able to inject data into the connection to make the client retry.

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.

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.

Anyway, just my 2c, and happy to be corrected (well, not happy per se, as it’ll make everyone’s lives more difficult!).
Rhys.
--
Dr Rhys Smith
Identity, Access, and Middleware Specialist
Cardiff University & Janet, the UK's research and education network

email: smith-bewU9O/***@public.gmane.org / rhys.smith-***@public.gmane.org
GPG: 0x4638C985

Post by Daniel Fisher

Post by Cantor, Scott

Post by Wessel, Keith
Hi, all,
Our AD folks just turned off SSLv3 support on our AD LDAPS service. Shib
didn¹t like it.

A little quick searching implies to me that the
java.naming.security.protocol JNDI property is what controls this in Java,
and the only value it appears to have is ssl [1]. Which probably means it
doesn't support TLS.
There is no actual standard for running LDAP over SSL, and I think the way
TLS is handled is with StartTLS, and that's probably why Java doesn't
support it.
Daniel probably knows the specifics, but offhand I'd say it's apparently
time to dump ldaps or somebody will need to complain to Oracle.

You should be able to use either the SSLv3 or TLSv1 protocols with
LDAPS or startTLS.
I'll do some more testing tomorrow to confirm.
We're considering disabling SSLv3 support on our directories as well.
--Daniel Fisher
--

[Ian Young]

Post by Rhys Smith
a) the attacker being able to intercept traffic
b) a client that will downgrade from TLS1 to SSLv3

The padding oracle attack should be possible whenever SSLv3 is negotiated. In the modern world this would normally not happen unless a downgrade dance is forced by the attacker, but if a client only supports SSLv3 then SSLv3 will be negotiated without a downgrade, and as far as I can tell the padding oracle attack is still applicable in that case.

Post by Rhys Smith
c) to be able to inject data into the connection to make the client retry.

Bottom line: SSLv3 is no longer secure under your conditions A and C; B is just icing on the cake.

As the only possible reason to continue to support SSLv3 on the server side is to support clients which don't support anything newer than SSLv3, you can therefore ignore condition B entirely.

Post by Rhys Smith
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.

If you have a secure network between the server and all clients, that's true. However, in those circumstances you should feel equally safe without using SSL/TLS at all, no? If you don't feel that safe, you really need to disable SSLv3.

-- Ian

[Rhys Smith]

Post by Ian Young
If you have a secure network between the server and all clients, that's true. However, in those circumstances you should feel equally safe without using SSL/TLS at all, no? If you don't feel that safe, you really need to disable SSLv3.

Well, having the confidence in your corporate network that your firewalls will light up and switch the ship to red alert when one machine (ldap client) is actively attacking another - pumping the LDAP server with enough packets to hit the right combination of bytes to trigger the padding bug - is somewhat different to the confidence required that there is nothing on the network passively listening to unencrypted traffic…

Anyway, just saying that waking up to find your Shib IdP no longer works because your directory admins have instantly turned off SSLv3 is probably overkill on their part, at the moment. We have time to make the switch after first doing some appropriate testing and reconfiguration where necessary… Orderly transition is good.

Rhys.
--
Dr Rhys Smith
Identity, Access, and Middleware Specialist
Cardiff University & Janet, the UK's research and education network

email: smith-bewU9O/***@public.gmane.org / rhys.smith-***@public.gmane.org
GPG: 0x4638C985

[Ian Young]

Post by Rhys Smith
Anyway, just saying that waking up to find your Shib IdP no longer works because your directory admins have instantly turned off SSLv3 is probably overkill on their part, at the moment. We have time to make the switch after first doing some appropriate testing and reconfiguration where necessary… Orderly transition is good.

I'd agree that what you're describing there could probably be politely described as the result of an excess of zeal in a production environment. I wouldn't assume that you have very much time for an orderly transition, though.

-- Ian

[David Langenberg]

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.

Dave

Disclaimer: I’ve only had time to have a quick glance through how POODLE
works, so please correct me if I’m wrong everybody!
With the caveat of that disclaimer - It should be said for those reading
this who are panicking about their ldaps connections, from what I
a) the attacker being able to intercept traffic
b) a client that will downgrade from TLS1 to SSLv3
c) to be able to inject data into the connection to make the client retry.
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.
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.
Anyway, just my 2c, and happy to be corrected (well, not happy per se, as
it’ll make everyone’s lives more difficult!).
Rhys.
--
Dr Rhys Smith
Identity, Access, and Middleware Specialist
Cardiff University & Janet, the UK's research and education network
GPG: 0x4638C985

Post by Daniel Fisher

Post by Cantor, Scott

Post by Wessel, Keith
Hi, all,
Our AD folks just turned off SSLv3 support on our AD LDAPS service.

Shib

Post by Daniel Fisher

Post by Cantor, Scott

Post by Wessel, Keith
didn¹t like it.

A little quick searching implies to me that the
java.naming.security.protocol JNDI property is what controls this in

Java,

Post by Daniel Fisher

Post by Cantor, Scott
and the only value it appears to have is ssl [1]. Which probably means

it

Post by Daniel Fisher

Post by Cantor, Scott
doesn't support TLS.
There is no actual standard for running LDAP over SSL, and I think the

way

Post by Daniel Fisher

Post by Cantor, Scott
TLS is handled is with StartTLS, and that's probably why Java doesn't
support it.
Daniel probably knows the specifics, but offhand I'd say it's apparently
time to dump ldaps or somebody will need to complain to Oracle.

You should be able to use either the SSLv3 or TLSv1 protocols with
LDAPS or startTLS.
I'll do some more testing tomorrow to confirm.
We're considering disabling SSLv3 support on our directories as well.
--Daniel Fisher
--
To unsubscribe from this list send an email to

--
To unsubscribe from this list send an email to

[Daniel Fisher]

Post by Daniel Fisher

Post by Cantor, Scott

Post by Wessel, Keith
Hi, all,
Our AD folks just turned off SSLv3 support on our AD LDAPS service. Shib
didn¹t like it.

A little quick searching implies to me that the
java.naming.security.protocol JNDI property is what controls this in Java,
and the only value it appears to have is ssl [1]. Which probably means it
doesn't support TLS.
There is no actual standard for running LDAP over SSL, and I think the way
TLS is handled is with StartTLS, and that's probably why Java doesn't
support it.
Daniel probably knows the specifics, but offhand I'd say it's apparently
time to dump ldaps or somebody will need to complain to Oracle.

You should be able to use either the SSLv3 or TLSv1 protocols with
LDAPS or startTLS.
I'll do some more testing tomorrow to confirm.
We're considering disabling SSLv3 support on our directories as well.

We tested an instance of OpenLDAP with SSLv3 disabled.
I was able to use both startTLS and LDAPS using TLSv1 on Java 6 with JNDI.

It's worth noting that with OpenSSL there are at least two ways to
restrict the use of SSLv3.
You can set the supported protocol version, but you can also set the
supported cipher suites.
If you choose to set cipher suites to something like: HIGH:MEDIUM:-SSLv2:-SSLv3
You may also restrict the use of TLSv1 if you've only left ciphers
supported by TLSv1.1/1.2

The AD configuration that started this thread may have inadvertently
done more than disable the SSLv3 protocol.
We certainly had issues with both Java 6 and 7 with a restricted list
of supported cipher suites.

--Daniel Fisher

[Wessel, Keith]

Thanks for testing and getting back on this so quickly, Daniel. I've forwarded your very reasonable theory on to our AD team. We'll see what we find out and, if it's something interesting, I'll report back here.

Thanks,
Keith


-----Original Message-----
From: users-***@shibboleth.net [mailto:users-***@shibboleth.net] On Behalf Of Daniel Fisher
Sent: Thursday, October 16, 2014 1:01 PM
To: Shib Users
Subject: Re: Shib IDP's LDAPS attribute resolution and SSLv3

Post by Daniel Fisher

Post by Cantor, Scott

Post by Wessel, Keith
Hi, all,
Our AD folks just turned off SSLv3 support on our AD LDAPS service. Shib
didn¹t like it.

A little quick searching implies to me that the
java.naming.security.protocol JNDI property is what controls this in Java,
and the only value it appears to have is ssl [1]. Which probably means it
doesn't support TLS.
There is no actual standard for running LDAP over SSL, and I think the way
TLS is handled is with StartTLS, and that's probably why Java doesn't
support it.
Daniel probably knows the specifics, but offhand I'd say it's apparently
time to dump ldaps or somebody will need to complain to Oracle.

You should be able to use either the SSLv3 or TLSv1 protocols with
LDAPS or startTLS.
I'll do some more testing tomorrow to confirm.
We're considering disabling SSLv3 support on our directories as well.

We tested an instance of OpenLDAP with SSLv3 disabled.
I was able to use both startTLS and LDAPS using TLSv1 on Java 6 with JNDI.

It's worth noting that with OpenSSL there are at least two ways to
restrict the use of SSLv3.
You can set the supported protocol version, but you can also set the
supported cipher suites.
If you choose to set cipher suites to something like: HIGH:MEDIUM:-SSLv2:-SSLv3
You may also restrict the use of TLSv1 if you've only left ciphers
supported by TLSv1.1/1.2

The AD configuration that started this thread may have inadvertently
done more than disable the SSLv3 protocol.
We certainly had issues with both Java 6 and 7 with a restricted list
of supported cipher suites.

--Daniel Fisher
--
To unsubscribe from this list send an email to users-***@shibboleth.net