[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: TLS renegotiation

Emmanuel Lecharny wrote:
> Howard Chu wrote:
>> 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.
>>   
> Wondering if we (ApacheDS) can be a possible target, assuming that we 
> are Java based. Any idea ?

I think Kurt's post already outlined the points of exposure but just to recap:

Renegotiation for privilege escalation is only a threat if the server
automatically and implicitly uses the client's certificate for authentication.
An LDAPv3-compliant server should be requiring the use of SASL/EXTERNAL Bind
for certificate-based authentication, so if your server is actually compliant
then there is no privilege escalation threat. If your server does implicit
certificate authentication, then you have a vulnerability here.

OpenLDAP slapd is not vulnerable to this particular threat. While our current
TLS code allows renegotiation, only the certificate used in the first TLS
handshake (if any) is ever parsed by slapd. So at worst, an MITM can impose
its own certificate credentials onto a client's session. Aside from causing
the client's requests to fail due to insufficient privileges, I don't see what
this accomplishes. (In fact it leads me to wonder if we can leverage this as a
feature, when proxying encrypted sessions. But that's for another day...)

Given the inability of an MITM to do anything useful to the authentication
state, I don't consider the request-injection aspect worthy of any further
concern.

-- 
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/