[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: TLS renotiation
Ludovic Poitou wrote:
> Howard,
>
> Our security expert at Sun consider that the attack could be applied to
> LDAP, although it will be more complex to achieve for all the good
> reasons you've outline (session-oriented, with explicit authentication
> attached to a session, and is a record-oriented ASN.1 encoded protocol
> with precisely defined message structure).
> The renegotiation in the attack is as far as I understand, driven by the
> man in the middle, and so even though OpenLDAP slapd never request the
> renegociation, it is still subject to the attack.
Hi Ludo, thanks for the note. Kurt and I were discussing this offline and he
has suggested a possible attack as well. I'm still not convinced of the
details but we'll continue to investigate.
> My 2 cents.
>
> Ludovic.
>
> On Nov 8, 2009, at 11:04 AM, Howard Chu wrote:
>
>> Dieter Kluenter wrote:
>>> Hi,
>>> I just wonder weather LDAP and in particular OpenLDAP is affected by
>>> TLS client auth renegotiation, as described
>>> http://extendedsubset.com/?p=8
>>> and the fix
>>> http://isc.sans.org/diary.html?storyid=7543
>>
>> No. These attacks are specific to HTTP; they are effective because HTTP is
>> inherently stateless, lacks an explicit Authentication operation in its
>> protocol spec, and is a line-oriented plaintext protocol with mostly
>> ad hoc
>> structure. Since LDAP is inherently session-oriented, with explicit
>> authentication attached to a session, and is a record-oriented ASN.1
>> encoded
>> protocol with precisely defined message structure, this stuff doesn't
>> apply.
>>
>> There may be other plaintext protocols that are similarly affected,
>> though I
>> tend to doubt it. The majority of other useful, widely deployed plaintext
>> protocols are session-oriented...
>>
>> The PDF document outlines 3 vulnerability scenarios.
>>
>> In the first case, the problem is that an HTTP server might be serving
>> documents from multiple security domains, and some may require certificate
>> authentication while others don't, and the server won't know what is
>> required
>> until it has parsed the HTTP request. Because HTTP is stateless and
>> the client
>> has simply issued a GET request, the certificate authentication has to
>> occur
>> implicitly via a renegotiation of TLS session and be applied
>> retroactively to
>> the request.
>>
>> LDAP never applies authentication retroactively to a session. In LDAP,
>> while
>> you are allowed to renegotiate TLS in the middle of an LDAP session,
>> there is
>> no actual reason to do so, and OpenLDAP slapd certainly never requests
>> it. If
>> a client were to do a renegotiate to provide a new client cert, it still
>> wouldn't affect the LDAP session until a new LDAP Bind with
>> SASL/EXTERNAL was
>> performed, and LDAP Bind is a hard delimiter - nothing sent before the
>> Bind
>> request can cause a response after the request. No session state can
>> straddle
>> a Bind. Therefore you can't perform privilege escalation attacks like
>> this in
>> LDAP.
>>
>> In the second case, differing crypto requirements - in OpenLDAP this can't
>> arise because cipher suite selection is global to the server, not
>> dependent on
>> request context. ACLs may require a particular strength before
>> allowing access
>> to a resource, but slapd simply denies the request in that case, it
>> doesn't
>> try to automagically renegotiate stronger crypto with the client.
>> (Note that
>> the PDF recommends making cipher suite configuration global in the
>> HTTP server
>> as well, to mitigate this attack. Duh.)
>>
>> As for the Man in the Middle aspect, this vulnerability exists because
>> HTTP is
>> a simple text line-oriented protocol, without real record boundaries.
>> LDAP is
>> based on ASN.1, where each message has an explicit length encoded in the
>> protocol. You can't just pre-inject a bunch of data and splice a valid
>> LDAP
>> request onto the end of it, the result will not be a valid LDAP
>> request. slapd
>> will get a parsing error when decoding such an attempt, and will
>> simply drop
>> the connection as it does for any improperly encoded messages it receives.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/