|
> 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 <ietf-ssh3%denisbider.com@localhost> 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. |