[openssl-users] SSL_CTX_set_cert_verify_callback and certificate access
Michael.Wojcik at microfocus.com
Sat Jan 12 14:20:22 UTC 2019
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
> Corey Minyard
> Sent: Friday, January 11, 2019 17:09
> I don't really like my options, but I'm kind of boxed in. I'm not sure
> why ssh doesn't run on top of ssl; that seems so sensible. I assume
> that's for historical reasons.
Since SSH and SSL were developed simultaneously (both first relased in 1995), neither could be based on the other.
More importantly, SSH and SSL are completely different protocols, initially designed for different use cases and as cryptographically-secured replacements for different existing mechanisms. In their early versions they had very different approaches to PKI, and as they're commonly used they still do.
There are remote-shell and file-transfer applications built on TLS (Telnet-over-TLS and Telnet-with-STARTTLS, and similarly for FTP). There's no real advantage to changing SSH to use the same architecture. It would force users away from the SSH PKI, which is widely abused; but the X.509 PKIX is such a mess that it's hard to claim it's all that much better.
Asking why SSH isn't built on SSL is a bit like asking why TCP/IP isn't based on X.25. Similarity of intent doesn't indicate similarity of fitness for a particular purpose.
 Though as always with opportunistic TLS, you want a client which will fail safe by aborting the connection, or at least make it *very* clear to the user, when a secure channel cannot be established.
 Sometimes referred to as "SFTP" or "FTPS", but the nomenclature is inconsistent; people also use those for SSH-based file transfer, among other things.
 Anecdotal evidence and some surveys suggest many, likely most, SSH users practice poor key hygiene, accepting public keys without checking their provenance.
Distinguished Engineer, Micro Focus
More information about the openssl-users