| |||||||||||||
|
| |||||||||||||
Strange SSH flaw raised by French porterStrange SSH flaw raised by French porterPosted Dec 16, 2010 3:44 UTC (Thu) by djm (subscriber, #11651)In reply to: Strange SSH flaw raised by French porter by boog Parent article: OpenBSD IPSEC backdoored?
That criticism applies to any protocol that uses non-determinism. By that logic, DH, CBC ciphers and anything that uses random challenges or nonces is flawed.
It only makes sense if the endpoints have no other way of leaking bits, which is not the case for the overwhelming majority of systems.
(Log in to post comments)
Strange SSH flaw raised by French porter Posted Dec 17, 2010 12:05 UTC (Fri) by tialaramex (subscriber, #21167) [Link]
Leaking bits on the same channel has advantages in convenience and discreetness. It's convenient because when you tap the channel (perhaps under cover of claiming you'll do traffic analysis) you get this leaked data without also needing to tap a separate channel.
It's discreet because a fairly competent analysis of the affected system will find a separate channel, an IPSec implementation that sends mysterious ICMP packets to an anycast address will cause the researcher to go look up who owns that anycast address, what it's for, what's in the ICMP packets, etc. Whereas if the data is just in some padding bytes that's not something you'd necessarily do more than glance at.
Also there have been weaknesses involving one of the parties in a two party protocol choosing a bad "random" challenge or nonce. The protocol will usually include a step to detect this and retry, which will be seamless unless bad guys are involved, but of course an implementation which does not check will appear to work - it's just not secure.
|
|
||||||||||||