full-disclosure - SSH vs. TLS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

From: dante at forethought.net (dante@...ethought.net)
Subject: SSH vs. TLS

Has anyone had experience with TLS Telnet?

I'm having an interesting debate with a security architect about the
dangers of using SSH. Initially, I was floored to hear this him. I thought
I'd see what some of the opinions from this list are.

This person is pushing for the use of TLS Telnet instead of SSH for the
following reasons:

- SSH is not an IETF standard.

The documents that make up the SSH2 protocol are still at the
Internet-Draft stage. I don't know how long they've been at this stage,
but the comment from security was that it's been at this stage for a while
and doesn't appear to be moving forward.

- SSH allows tunneling other protocols, circumventing firewall policies.

While most admins consider this to be a desirable feature, it's generally
frowned upon by network ops and security. Port forwarding can be turned
off within the sshd config file. However, the security group has no way of
making sure it stays off. Essentially, it's a trust issue: Can the
security group trust the admin group not to turn it back on?

In addition, there are several requirements for key management. I think
kerberos will address all of these, maybe I'm wrong.

- There must be a secure means by which all server keys are distributed to
appropriate ssh clients.

- There must be a secure means by which all necessary client keys are
distributed to appropriate servers.

- There must be a mechanism to expire keys. Keys will not be valid for
more than 365 days. This feature should be an integral part of the key
management infrastructure. It must technically prevent either clients or
servers from using expired keys.

- There must be a mechanism in place to allow a trusted third party to
revoke either a client or a server key. Revocation must technically
prevent either clients or servers from using revoked keys.

- There must be a mechanism to integrate both client and server keys into
LDAP.

So, what do you all think? Is SSH really that bad or are these
requirements unreasonable? Is it really worth implementing TLS Telnet?