You've probably all heard about this "new" attack several times by now. Just to confirm what's already been stated - this attack only affects HTTP browsers that deliberately break the TLS handshake protocol to allow using older SSL versions. It does not affect LDAP software at all.
Also, since version 2.4.14 (released February 2009), OpenLDAP has supported TLSProtocolMin slapd config and LDAP_TLS_PROTOCOL_MIN client config directives for selecting the minimum version of SSL/TLS to allow. As this feature has been available for over 5 years there is no reason for any OpenLDAP deployments to be using SSLv3 today.
Pardon my ignorance on the subject, but I need to understand this:
You've probably all heard about this "new" attack several times by now. Just to confirm what's already been stated - this attack only affects HTTP browsers that deliberately break the TLS handshake protocol to allow using older SSL versions. It does not affect LDAP software at all.
Isn't this configurable? With the following: TLSCipherSuite HIGH:MEDIUM:+TLSv1:+SSLv3:RSA doesn't this allow SSLv3? To secure against POODLE, don't we need to remove the SSLv3?
Also, since version 2.4.14 (released February 2009), OpenLDAP has supported
TLSProtocolMin slapd config and LDAP_TLS_PROTOCOL_MIN client config directives for selecting the minimum version of SSL/TLS to allow. As this feature has been available for over 5 years there is no reason for any OpenLDAP deployments to be using SSLv3 today.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Joe Friedeggs wrote:
Pardon my ignorance on the subject, but I need to understand this:
You've probably all heard about this "new" attack several times by now. Just to confirm what's already been stated - this attack only affects HTTP browsers that deliberately break the TLS handshake protocol to allow using older SSL versions. It does not affect LDAP software at all.
Isn't this configurable? With the following:
TLSCipherSuite HIGH:MEDIUM:+TLSv1:+SSLv3:RSA
doesn't this allow SSLv3?
Yes.
To secure against POODLE, don't we need to remove the SSLv3?
No. In the standard TLS handshake protocol, if both sides support TLSv1, it's not possible to downgrade to SSLv3. The POODLE attack only exists because web browsers intentionally break the standard TLS handshake protocol.
Also, since version 2.4.14 (released February 2009), OpenLDAP has supported TLSProtocolMin slapd config and LDAP_TLS_PROTOCOL_MIN client config directives for selecting the minimum version of SSL/TLS to allow. As this feature has been available for over 5 years there is no reason for any OpenLDAP deployments to be using SSLv3 today.
2014-10-19 15:36 GMT+02:00 Howard Chu hyc@symas.com:
Joe Friedeggs wrote:
Pardon my ignorance on the subject, but I need to understand this:
You've probably all heard about this "new" attack several times by
now. Just
to confirm what's already been stated - this attack only affects HTTP
browsers
that deliberately break the TLS handshake protocol to allow using
older SSL
versions. It does not affect LDAP software at all.
Isn't this configurable? With the following:
TLSCipherSuite HIGH:MEDIUM:+TLSv1:+SSLv3:RSA
doesn't this allow SSLv3?
Yes.
To secure against POODLE, don't we need to remove
the SSLv3?
No. In the standard TLS handshake protocol, if both sides support TLSv1, it's not possible to downgrade to SSLv3. The POODLE attack only exists because web browsers intentionally break the standard TLS handshake protocol.
Or more commonly because some equipment (a firewall, most of the time) closes the connection at both ends, and the browser retries the connection with a protocol downgrade. Web browsers don't intentionally break the handshake, they try to adapt to various servers+networks environments to get the resource desired by the end user.
* Erwann Abalea:
Or more commonly because some equipment (a firewall, most of the time) closes the connection at both ends, and the browser retries the connection with a protocol downgrade. Web browsers don't intentionally break the handshake, they try to adapt to various servers+networks environments to get the resource desired by the end user.
They enable server operators to get away with non-compliant behavior. Now they even punish those who actually maintain their web servers by forcing them to implement TLS_FALLBACK_SCSV support. Web browsers are very much too blame for this particular mess.
And even worse, developers now rush in client application changes to send TLS_FALLBACK_SCSV on every handshake, even if they do not perform a browser-style insecure protocol version downgrade. This will make deployment of TLS 1.3 on servers rather difficult.
Joe Friedeggs friedeggs44@hotmail.com schrieb am 19.10.2014 um 15:17 in
Nachricht BLU170-W8303CBEF13F0FA435A5765A5960@phx.gbl:
Pardon my ignorance on the subject, but I need to understand this:
You've probably all heard about this "new" attack several times by now. Just
to confirm what's already been stated - this attack only affects HTTP
browsers
that deliberately break the TLS handshake protocol to allow using older SSL versions. It does not affect LDAP software at all.
Isn't this configurable? With the following: TLSCipherSuite HIGH:MEDIUM:+TLSv1:+SSLv3:RSA doesn't this allow SSLv3? To secure against POODLE, don't we need to remove the SSLv3?
Related question: If a slapcat of the config database doesn't show a value for TLSCipherSuite, does it mean it is some default value? Any other way to query the setting?
[...]
Regards, Ulrich
Ulrich Windl wrote:
Related question: If a slapcat of the config database doesn't show a value for TLSCipherSuite, does it mean it is some default value?
I'm pretty sure the default depends on the TLS lib used and how it was built for a certain OS.
=> always set TLSCipherSuite explicitly
To find out which protocols/ciphers can be used with a current installation use sslscan.
Ciao, Michael.
Michael Ströder michael@stroeder.com schrieb am 20.10.2014 um 08:47 in
Nachricht 5444B01F.2050701@stroeder.com:
Ulrich Windl wrote:
Related question: If a slapcat of the config database doesn't show a value for TLSCipherSuite, does it mean it is some default value?
I'm pretty sure the default depends on the TLS lib used and how it was
built
for a certain OS.
Does it mean openLDAP has no idea about the default, unless you explicitly set it?
=> always set TLSCipherSuite explicitly
To find out which protocols/ciphers can be used with a current installation use sslscan.
Ciao, Michael.
Ulrich Windl wrote:
Michael Ströder michael@stroeder.com schrieb am 20.10.2014 um 08:47 in
Nachricht 5444B01F.2050701@stroeder.com:
Ulrich Windl wrote:
Related question: If a slapcat of the config database doesn't show a value for TLSCipherSuite, does it mean it is some default value?
I'm pretty sure the default depends on the TLS lib used and how it was built for a certain OS.
Does it mean openLDAP has no idea about the default, unless you explicitly set it?
I think so. But maybe one of the core developers can confirm.
Also note that cipher key-words HIGH, MEDIUM etc. gets mapped to some library specific cipher sets which can change. E.g. OpenSSL project decided to limit the set of ciphers defined with HIGH.
Which is...
=> always set TLSCipherSuite explicitly
..yet another reason to define TLS protocols and ciphers explicitly.
Ciao, Michael.
openldap-technical@openldap.org
-
Erwann Abalea -
Florian Weimer -
Howard Chu -
Joe Friedeggs -
Michael Ströder -
Ulrich Windl