stpeter at stpeter.im
Thu Aug 16 12:04:35 UTC 2012
-----BEGIN PGP SIGNED MESSAGE-----
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:
>> 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:
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
>>> 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:
>> 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.)
> But yes, pinning (or something similar) is the right solution to
Yes, certificate pinning is a good idea.
>> Didn't someone suggested a TXT DNS record for this sometime ago,
>> mentioning the required methods and cert sig?
> I don't recall - but for this attack to work you need to have
> already compromised either routing or DNS - so in either case it
> wouldn't help.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
More information about the JDev