[jdev] XMPPloit

[Kevin Smith]

On Thu, Aug 16, 2012 at 1:04 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 8/16/12 5:48 AM, Kevin Smith wrote:
>> On Thu, Aug 16, 2012 at 12:36 PM, Pedro Melo
>> <melo at simplicidade.org> wrote:
>>> Hi,
>>>
>>> On Thu, Aug 16, 2012 at 11:12 AM, Kevin Smith
>>> <kevin at kismith.co.uk> wrote:
>>>> On Thu, Aug 16, 2012 at 10:50 AM, Pedro Melo
>>>> <melo at simplicidade.org> wrote:
>>>>> came across this today and I haven't seen it mentioned here:
>>>>>
>>>>> http://www.pentestit.com/xmpploit-tool-attack-xmpp-connections/
>>>>>
>>>>>
>>>>>
> I haven't tested it yet, and the article is strong on claims and light
>>>>> on explanations on how it works, so take it with a grain of
>>>>> salt.
>>>>
>>>> The claims they make seem sensible - everyone's known about
>>>> the possibility of such downgrade attacks since forever - which
>>>> is why clients generally won't allow both PLAIN and non-TLS at
>>>> the same time. What clients really need to do is cert pinning
>>>> and mech pinning to prevent these exploits in all but the
>>>> first-login case.
>>>
>>> Yes. The author as a small demo video screencast of the tool in
>>> action here:
>>>
>>> http://www.ldelgado.es/index.php?dir=aplicaciones/xmpploit
>>>
>>> The initial plain-text part of the XMPP handshake will allow a
>>> MITM attack to downgrade the security. Only cert and mech pinning
>>> would work here.
>>
>> It'll allow it to downgrade to no-TLS, but not to PLAIN, as
>> clients shouldn't be allowing PLAIN over connections without TLS.
>
> Sure, that's the proper policy for all clients. (I don't see it as
> "mechanism pinning" so much as client policy.)

This isn't mechanism pinning - mechanism pinning would be remembering
the previously used mechs and warning when they become unavailable.

I was suggesting that all clients should have a policy as above, but
that mech pinning would be better.

/K