MAC Cipher umac-128-etm@openssh.com does not correctly work

[iguyking]

When using the libressl-portable version with "OpenSSH for Windows", the MAC cipher umac-128-etm@openssh.com does not work correctly.

Details can be found with issue #1359 in the Powershell/Wind32-Openssh project.

PowerShell/Win32-OpenSSH#1359

[kinichiro]

Hi,

I have 3 different version of OpenSSH installed servers.
And those OpenSSHs are linked with different version of OpenSSL, respectively.
I could successfully connect to these 3 servers from my Windows10
with -m umac-128-etm@openssh.com option.

My client and servers environment here.
"SSH and LibreSSL version" shows the results of ssh -V.

- Client
  OS : Windows10 Home 64bit
  SSH and LibreSSL version : OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5

- Server1
  OS : Fedora 31 (x86_64)
  SSH and LibreSSL version : OpenSSH_8.1p1, OpenSSL 1.1.1g FIPS  21 Apr 2020

- Server2
  OS : Ubuntu18
  SSH and LibreSSL version : OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n  7 Dec 2017

- Server3
  OS : Ubuntu14
  SSH and LibreSSL version : OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.13, OpenSSL 1.0.1f 6 Jan 2014

From Windows10 cmd.exe, I typed command like below and was able to connect to my servers successfully.

C:\work>ssh -m umac-128-etm@openssh.com myserver

I have no changes to my /etc/ssh/sshd_config.
Are there any configurations to reproduce this issue ?

[jansohn]

@kinichiro I think this can be only reproduced when using cipher aes128-ctr.

sftp.exe -o "ciphers=aes128-ctr" -o "macs=umac-128-etm@openssh.com" user@hostname

[kinichiro]

@jansohn Thanks.
I saw ssh -m umac-128-etm@openssh.com -c aes128-ctr user@hostname on Windows10 failed.

C:\work>ssh -m umac-128-etm@openssh.com -c aes128-ctr user@hostname
Corrupted MAC on input.
ssh_dispatch_run_fatal: Connection to xx.xx.xx.xx port 22: message authentication code incorrect

[kinichiro]

On Ubuntu18 server, that runs OpenSSH_7.6p1 with OpenSSL 1.0.2n,
I had built OpenSSH 8.3p1 with LibreSSL 3.1.3 like below.

LibreSSL 3.1.3 build
$ ./configure --prefix=/mypath
$ make check
$ make install

OpenSSH 8.3p1 build
$ export LD_LIBRARY_PATH=/mypath/lib
$ ./configure --prefix=/mypath --with-ssl-dir=/mypath
$ make install

And this ssh client using umac-128-etm@openssh.com and aes128-ctr can successfully connect to localhost.

$ ./ssh -V
OpenSSH_8.3p1, LibreSSL 3.1.3
$
$ ./ssh -m umac-128-etm@openssh.com -c aes128-ctr localhost
localhost's password:
...

I believe this issue is specific to Windows build.

[kinichiro]

@iguyking , @jansohn ,
Original issue seems to be closed now.
Can you close this, too ?
And I think this is "OpenSSH for Windows" specific issue, since I had tested OpenSSH with LibreSSL on Linux platform as above comment.
Am I misunderstanding ?

[jansohn]

@kinichiro no, I don't think this issue should be closed as it seems to be a specific problem with LibreSSL. The problematic combination works for example with the Git for Windows ssh binary which uses OpenSSL instead of LibreSSL.

"C:\Program Files\Git\usr\bin\ssh.exe" -v -m umac-128-etm@openssh.com -c aes128-ctr user@hostname
OpenSSH_8.3p1, OpenSSL 1.1.1g  21 Apr 2020
[...]
Last login: Sun Jul 19 18:29:51 2020 from 192.1.1.55
[user@hostname ~]$

[kinichiro]

@jansohn Can you tell or provide link about the procedure to build that Windows ssh ?
As I mentioned above, I believe this issue is specific to Windows build.
To see more about this issue, building ssh with libressl on Windows is needed.

[jansohn]

@kinichiro I'm not very familiar with the build process but afaik @bagajjal is.

[tgauth]

I can provide support for building ssh with libressl on Windows to help debug this.

The latest release of OpenSSH for Windows with LibreSSL is available at https://github.com/powershell/win32-OpenSSH/releases/
and instructions for building the repo can be found at https://github.com/PowerShell/Win32-OpenSSH/wiki/Building-OpenSSH-for-Windows-(using-LibreSSL-crypto)

Also if it's been too long since this issue was opened, and we should open another one - let me know!

[mtinberg]

I can confirm that this issue is still present

PS C:\Users\mtinberg> ssh -V
OpenSSH_for_Windows_9.5p1, LibreSSL 3.8.2
PS C:\Users\mtinberg> ssh -m umac-128-etm@openssh.com host.example.com
Corrupted MAC on input.
ssh_dispatch_run_fatal: Connection to 192.0.2.101 port 22: message authentication code incorrect
PS C:\Users\mtinberg> ssh -m hmac-sha2-512-etm@openssh.com host.example.com
[mtinberg@host ~]$

[botovq]

It would be interesting to know if this issue goes away if LibreSSL is compiled with -DOPENSSL_SMALL_FOOTPRINT.
One possible explanation for the breakage is that this is compiled with a modern compiler that may break code that relies on undefined behavior to gain speed.

I do not currently have access to a Windows platform, nor do I have time to do a lot of debugging for this issue myself, but if someone could confirm this, I think I have an idea how to fix this properly.

[tgauth]

@mtinberg, can you provide some more details about your repro? What's the architecture of the client machine? Is the issue present connecting to any ssh server? I've tested from an ssh client on an AMD64 Windows machine to both a Windows and Ubuntu ssh server, but cannot repro.

I can also compile LibreSSL with -DOPENSSL_SMALL_FOOTPRINT and provide the binaries if you or someone else would be open to testing it out.

[mtinberg]

The combination that doesn't work is: Client is Win10 x86_64 OpenSSH_for_Windows_9.5p1, LibreSSL 3.8.2 Server is CentOS7 x86_64 OpenSSH_7.4p1, OpenSSL 1.0.2k-fips openssh-7.4p1-22.el7_9.x86_64 I have other EL7 servers running openssh-7.4p1-23.0.1.el7_9.x86_64 managed by a different group (the affected one is on an appliance-like system) that work fine but their sshd_config is different sshd_config (not working) MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com sshd_config (working) MACs hmac-sha2-512,hmac-sha2-256,hmac-sha1 and I was able to make things work on both hosts by adding allowed MACs to the ssh_config on my Win10 host Host * MACs hmac-sha2-256,hmac-sha1,umac-128@openssh.com,hmac-sha2-512 I thought there was some default crypto policy that got included in the ssh config on redhat, but I can't seem to find this in the config at the moment. So either the client or server config can constrain the MACs to a working set that gets negotiated, but the default config from OpenBSD/OpenSSH present on Windows SSH (not having ssh_config in system-wide appdata and relying on the compiled-in defaults) doesn't negotiate right with LibreSSL when connecting to EL7 with OpenSSL with the umac-128-etm@openssh.com MAC