Packet Timing and Data Leaks

Darren Tucker dtucker at dtucker.net
Fri Aug 11 14:12:39 AEST 2023


On Thu, 10 Aug 2023 at 20:44, Peter Stuge <peter at stuge.se> wrote:
> Philipp Marek wrote:
> > An easy workaround is to use a password manager (a plain file as a minimum)
>
> If you can/want to use a file then consider using a key instead.
>
> publickey authentication is non-interactive on the wire and the key is
> already unlocked so packet timing leaks nothing about your passphrase.

Just to be clear: SSH's password authentication is not subject to this
attack.  The client sends the whole password in a single
SSH_MSG_USERAUTH_REQUEST packet (see RFC4252 section 8) so there's no
inter-keystroke timing.  Same goes for keyboard-interactive (RFC4256).

The issue is that if during an interactive session you invoke
something that wants a password which it reads from the tty (eg su,
sudo, ssh-add or a second ssh invocation) that the potential exists to
leak keystroke timing.

If you needed to do a two-hop ssh then using either of pubkey via
agent forwarding or jumphost would avoid the timing leaving the client
machine.

-- 
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.


More information about the openssh-unix-dev mailing list