from Hacker News

OpenSSH 9.5 released with keystroke timing obfuscation

by surteen on 10/4/23, 1:50 PM with 58 comments

  • by Tempest1981 on 10/4/23, 3:18 PM

    More from last month:

    https://news.ycombinator.com/item?id=37307708 (258 comments)

  • by throw0101a on 10/4/23, 2:07 PM

    More importantly (IMHO):

        ssh-keygen(1): generate Ed25519 keys by default. Ed25519 public keys
    are very convenient due to their small size. Ed25519 keys are
    specified in RFC 8709 and OpenSSH has supported them since version 6.5
    (January 2014).
    * https://www.openssh.com/releasenotes.html#9.5

    Previously, if you didn't specify "-t", you got RSA keys; now you get Ed25519, and if you want RSA you have to ask for it.

    NIST's publication of FIPS 186-5 in February (2023) added Ed25519 and Ed448 as approved (? allowed?) algorithms:

    * https://csrc.nist.gov/publications/detail/fips/186/5/final

    * https://en.wikipedia.org/wiki/EdDSA#Standardization_and_impl...

    Partly one of the reasons given for the default switch:

    * https://lists.mindrot.org/pipermail/openssh-unix-dev/2023-Se...

    Curious to know if/when the OpenSSH folks will add Ed448 (RFC 8709, like Ed25519).

  • by FiloSottile on 10/4/23, 4:10 PM

    I'm very proud that we implemented server-side support for the keystroke timing obfuscation mechanism in golang.org/x/crypto/ssh already.

    (I just clicked the Submit button! https://go.dev/cl/524775)

    It's a small change, but it's a signal that we're much more on top of x/crypto/ssh maintenance, compared to a year ago when we had to scramble to implement rsa-sha2-256/512 support just hours before GitHub (rightfully) dropped SHA-1 support, potentially breaking every x/crypto/ssh client.

    The main reason is that thanks to the funding of my clients (https://words.filippo.io/full-time-maintainer/) I was able to hire Nicola Murino, the maintainer of SFTPGo, to pick up maintenance of x/crypto/ssh. This is benefiting both my clients and the whole ecosystem, and is a little step in growing the professional maintainer model.

  • by throw0101a on 10/4/23, 2:07 PM

    The link that was (originally) submitted is to LWN just posting the release notes. The direct link(s) to the release notes is:

    * https://www.openssh.com/txt/release-9.5

    * https://www.openssh.com/releasenotes.html#9.5

  • by cabirum on 10/4/23, 2:42 PM

    The release notes do not say why there is a need to obfuscate keystroke timings. I guess it is designed to mitigate some attack vector? Is it already being exploited in the wild or... let's say is purely of academic interest?

  • by rollcat on 10/4/23, 6:48 PM

    If you use OpenSSH (wink), please consider donating to OpenBSD, aka the upstream developers: https://www.openbsd.org/donations.html

  • by devsda on 10/4/23, 2:22 PM

    > This attempts to hide inter-keystroke timings by sending interactive traffic at fixed intervals (default: every 20ms) when there is only a small amount of data being sent. It also sends fake "chaff" keystrokes for a random interval after the last real keystroke. These are controlled by a new ssh_config ObscureKeystrokeTiming keyword.

    So does it send these phantom keystrokes only when there are real keystrokes?

    On first reading I thought it sends periodic+random keystrokes and so {Client,Server}AliveInterval option(s) may not be required to keep the connection alive. Need to try and confirm the behaviour.

    This version also changes ssh-keygen to generate ed25519 keys by default. Time to update scripts that generate keys without a '-t' arg.

  • by jsanford on 10/4/23, 7:45 PM

    With the new default ObscureKeystrokeTiming setting, a single typed character now causes hundreds of packets on the wire instead of 3.

  • by enbugger on 10/4/23, 5:05 PM

    What are the downsides of this?

  • by guerrilla on 10/4/23, 6:11 PM

    It's nice to see that they take this seriously. I praise their risk aversion.