Re: [ssh] Host key sync - "global-requests-ok" extension

 > In other words instead of saying "we'd prefer -CTR, but will go with 
-CBC if you can't do that, which unless you've got a pretty broken 
implementation is no less secure", the server is saying "if you can't do 
-CTR, we'll force you to fall back to what's pretty much the least 
secure file transfer protocol there is (TFTP)".

In isolation, that reasoning makes perfect sense. However, the security 
scans are likely that way for reasons of demonstrability.

An organization uses scans to show they are following best practices in 
a way that's easy to evaluate for purposes of outside standards such as PCI.

Servers are easier to scan than clients. If an organization can show all 
of their SSH servers have CBC disabled, this demonstrates CBC is never 
used. However if servers allow CBC, then showing it's never used, or 
it's used safely, requires inspecting clients within and without the 
organization's network. This is a demanding task.

An organization's goal will be to have no CBC if they can. If they need 
to use older devices that require it, they can make the decision to 
enable CBC, make a note of why they enabled it, and configure an 
exception in the security scan for a particular server.

 > a lot of implementations don't look beyond 4251-4254

I'm sure /new /implementation would be concerned about connecting to 
OpenSSH. It would be hard to ignore that /at least/ CTR is needed, if 
not AES-GCM or ChaCha.

denis


On 2018-12-20 06:48, Peter Gutmann wrote:
> denis bider <[email protected]> writes:
>
>> You're focusing on an outdated aspect of the spec instead of widely known
>> best practice.
> I'm trying to deal with the fallout from existing implementations that only
> do what's in the base RFCs.
>
>> CBC algorithms are known to have security problems in the way they are used
>> in SSH. They haven't been recommended for use in years.
> Only if they're badly implemented.  SSH packets have so much known plaintext
> at the start that it's pretty easy to reject guessing attacks, or at least
> reduce the success rate to the point where it's not useful to an attacker.  In
> addition it's a chosen-plaintext attack, which for many implementations of SSH
> (e.g. embedded and SCADA) is essentially impossible.
>
> The problem with disabling the MTI algorithms is that a lot of implementations
> don't look beyond 4251-4254, so by only allowing -CTR, which they don't do,
> it's forcing them to fall back to things like FTP and (shudder) TFTP.  In
> other words instead of saying "we'd prefer -CTR, but will go with -CBC if you
> can't do that, which unless you've got a pretty broken implementation is no
> less secure", the server is saying "if you can't do -CTR, we'll force you to
> fall back to what's pretty much the least secure file transfer protocol there
> is (TFTP)".
>
> The reason why my code warns about -CTR only servers is because I got tired of
> answering questions along the lines of "X works with Y, but not with OpenSSH,
> what's wrong?".
>
>> If we ship the SSH Server with CBC algorithms enabled, we get support cases
> >from users failing security scans.
>
> Ah, I can see that'd be a problem then.  Can you beat the scanner vendor over
> the head to fix the scanner?  I had to do that when someone's scanner reported
> an OpenSSL vuln in my code.
>
> Peter.
>