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. |

| 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> |
|---|---|---|
| ||
| Previous by Date: | Re: [Full-Disclosure] Microsoft and Security, Ron DuFresne |
|---|---|
| Next by Date: | Re: [Full-Disclosure] Microsoft and Security, William Warren |
| Previous by Thread: | [Full-Disclosure] IE Web Browser: "Sitting Duck", Edge, Ronald D |
| Next by Thread: | Re: [Full-Disclosure] SSH vs. TLS, Valdis . Kletnieks |
| Indexes: | [Date] [Thread] [Top] [All Lists] |