Re: [9front] [patch] /sys/src/cmd/ssh.c notify user of unavailable cipher

[Romano <unobe@cpan.org>]

As a follow-up: I started speaking with IT today. They're using the CIS CentOS Linux Benchmark v2.1.0, but the last check missed yhe faxt that an entire section, section 5.2.11, was removed. That section restricts ciphers but even the audit looks wrong considering what it describes. The latest version of the document, v2.2.0 does not restrict ciphers more than the defaults shipped with openssh, and so IT looks like they're fine with updating.

I'll still look into patching to provide better diagnostic info to yhe user when supported cipher/mac isn't available.


On April 22, 2020 5:40:29 AM UTC, Romano <unobe@cpan.org> wrote:
>On Tue, Apr 21, 2020, at 4:25 PM, cinap_lenrek@felloff.net wrote:
>> maybe consider if it really is required for our ssh client to
>> support old versions of sshd with flawed algorithms. the best
>> way might be to just wait it out until ther servers get hacked
>> or they update.
>
>I agree that it would be better to not have servers hacked, and be
>up-to-date. I hope the sysadmin for the (work) server I need access to
>will be open to including the chacha20/poly1305 cipher.  I'll let the
>list know, hopefully sometime next week, what I hear.
>
>> that code was never written to support multiple ciphers (all
>> the other ciphers are slow and insecure/broken anyway). i just
>> had no time for bullshit like this as i was writing this over
>> a weekend, fast.
>
>I've looked a bit online for more information about all the other
>ciphers being insecure/broken. I didn't see anything about AES256-CTR
>being insecure or broken, but I probably missed something.  I read that
>one has to be careful with the key used, and that AES-256 is the "gold
>standard" presumably because the U.S. government uses it (argument from
>authority--yay!). The server I was trying to connect to does support
>AES256-CTR, and I plan to follow-up next week w/the sysadmin of that
>server to understand why that's supported, but not chacha20/poly1305.
>Would you (or someone else reading this on the list) have a paper or
>something handy that I can read re: the insecurity and brokenness of
>that cipher specifically? That would help in my conversation with the
>sysadmin.
>
>> the initial version didnt even bother with password and
>> keyboard-interactive authentication, and only supported
>> RSA public key auth. only what i needed (for my dayjob
>> as admin).
>
>Since I am now using this software, I really appreciate the time you
>took to update it to accept a password.  For one-off testing, that was
>helpful.  And I am grateful that you're taking the time to reply to me
>on this list.
>
>> the nice thing about chacha20/poly1305 is that is is a AEAD
>> cipher construction. that is, it does authentication (MAC)
>> and encrypion as a single operation. so that cuts down
>> complexity and pointless-combinations down.
>
>Very cool! I did not know any of this.
>
>> the question is if you want to support all combinations or not.
>> i'd do some research what the most common cipher+mac combination
>> is supported on old ssh2 versions. maybe its not possible i
>> dont know. just be as lazy as possible.
>> 
>> and maybe just implement one encryption+mac algrithm. then
>> the code needs less indirection and you can just have to
>> adapt recvpkt() and sendpkt(). they do the encryption in
>> place (at the beginning of recvpkt() or at the end of
>> sendpkt()).
>> 
>> 
>> if the versions you want to support dont implement curve25519
>> diffie-hellman, then you might also need to implement FFDH.
>> but its easy and libsec has you covered. all the complexity is
>> mostly with the negotiation. thats why i avoided this.
>
>Fortunately, the server in question does support curve25519 for key
>exchange.
>
>> try it out. you dont need to me much of a cryptographer as
>> the design has already been done by the ssh people. the RFC's
>> is really all you need.
>
>Hopefully this won't be needed, but I did look into what might be
>needed if I had to do it. I'd focus on AES-256-CTR. From what I see in
>9front, there's aes(2) which provides OFB and is similar to CTR[1], but
>is not CTR.  So that implementation would have to be added to aes(2),
>no?  In terms of steps I'd take, I'd dig into how the OFB
>implementation works on 9front, then determine how to adjust in order
>to implement CTR.
>
>For authentication, I'd focus on hmac-sha2-512, which is available from
>sechash(2) on 9front.
>
>Thanks again for taking the time to respond.
>
>[1]
>https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Counter_(CTR)