Ssh – How to disable SSLv3 in an OpenSSH SSH server to avoid POODLE

This is not an issue for OpenSSH since it doesn't make use of SSL.

They differ on the things which are around the tunnel. SSL traditionally uses X.509 certificates for announcing server and client public keys; SSH has its own format. Also, SSH comes with a set of protocols for what goes inside the tunnel (multiplexing several transfers, performing password-based authentication within the tunnel, terminal management...) while there is no such thing in SSL, or, more accurately, when such things are used in SSL they are not considered to be part of SSL (for instance, when doing password-based HTTP authentication in a SSL tunnel, we say that it is part of "HTTPS", but it really works in a way similar to what happens with SSH).

Conceptually, you could take SSH and replace the tunnel part with the one from SSL. You could also take HTTPS and replace the SSL thing with SSH-with-data-transport and a hook to extract the server public key from its certificate. There is no scientific impossibility and, if done properly, security would remain the same. However, there is no widespread set of conventions or existing tools for that.

As further evidence I'd direct you to RFC 4253, which discusses the "The Secure Shell (SSH) Transport Layer Protocol". This is SSH's own custom transport layer, it does not use the same one that HTTPS/SSL uses.

This document describes the SSH transport layer protocol, which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression.

Lastly this Q&A from the security SE site titled: SSL3 “Poodle” Vulnerability had this to say about the POODLE attack.

The Poodle attack works in a chosen-plaintext context, like BEAST and CRIME before it. The attacker is interested in data that gets protected with SSL, and he can:

• inject data of his own before and after the secret value that he wants to obtain;
• inspect, intercept and modify the resulting bytes on the wire.

The main and about only plausible scenario where such conditions are met is a Web context: the attacker runs a fake WiFi access point, and injects some Javascript of his own as part of a Web page (HTTP, not HTTPS) that the victim browses. The evil Javascript makes the browser send requests to a HTTPS site (say, a bank Web site) for which the victim's browser has a cookie. The attacker wants that cookie.

So there is no action that needs to be taken for OpenSSH against this particular threat.

References

• How POO­DLE Hap­pened
• Taxonomy of Ciphers/MACs/Kex available in SSH?
• Secure Configuration of Ciphers/MACs/Kex available in SSH

More reading

• SSL3 “Poodle” Vulnerability