IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: applying AES-GCM to secure shell: proposed "tweak"



On Wed, Apr 15, 2009 at 03:38:45PM -0500, Nicolas Williams wrote:
> On Wed, Apr 15, 2009 at 04:20:46PM -0400, der Mouse wrote:
> > > There has been a security vulnerability that resulted from
> > > information leaks that take place when the encrypted packet length is
> > > decrypted and checked before the MAC is verified.
> > 
> > Which actually is mostly unavoidable, since the MAC can't be even
> > _located_ until the packet length is known.
> > 
> > > The leak was enormously compounded by sending the decrypted packet
> > > length in a DISCONNECT packet,
> > 
> > !!  It's hardly the fault of the protocol if implementations
> > gratuitously leak cribs for attacking the crypto!
> 
> Even without the DISCONNECT and syslogging you still leak quite a bit
> IFF the packet length decodes to something less than max packet.  Yes,
> it's unlikely for an active attacker to cause that, since max packet
> will usually be on the order of 2^16 but the truly max packet length is
> on the order of 2^32, but surely you see the point.

The reason you leak if the packet length decodes to something less than
max packet is this:

   The attacker can modify what he thinks is encrypted ciphertext and
   hope it decrypts to a value less than max packet, then he can send
   garbage one block at a time until the peer responds by closing the
   connection when the MAC fails to validate.  The attacker then knows
   the decrupted packet size to within one block size.

If max packet size is much smaller than the max possible packet length
then most of the time all that's leaked is that the decrypted packet
size is larger than the negotiated max packet length and so this attack
is not worthwhile.  With HPN in the picture I'm not sure that that will
be the case, though one expects no active attackers in HPN cases, but
still.

With a cleartext packet length you don't have any of these problems.
Instead you get the normal traffic analysis problems, such as the
ability to recognize echo-off password prompts and count any
one-character packets and thus determine packet length.  However, these
problems can be addressed without cryptography.

Nico
-- 



Home | Main Index | Thread Index | Old Index