Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security FullDisclosure
[Top] [All Lists]

[Full-Disclosure] SSH vs. TLS

Subject: [Full-Disclosure] SSH vs. TLS
Date: Tue, 29 Jun 2004 09:20:11 -0600 (MDT)
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?



<Prev in Thread] Current Thread [Next in Thread>