[Full-Disclosure] SSH vs. TLS

dante_at_forethought.net
Date: 06/29/04

  • Next message: Eric Paynter: "Re: SUPER SPOOF DELUXE Re: [Full-Disclosure] Microsoft and Security" 
    To: <full-disclosure@lists.netsys.com>
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?

    _______________________________________________
    Full-Disclosure - We believe in it.
    Charter: http://lists.netsys.com/full-disclosure-charter.html

  • Next message: Eric Paynter: "Re: SUPER SPOOF DELUXE Re: [Full-Disclosure] Microsoft and Security"

    Relevant Pages

    • Re: [Full-Disclosure] SSH vs. TLS
      ... > frowned upon by network ops and security. ... > - There must be a secure means by which all server keys are distributed to ... > appropriate ssh clients. ... > servers from using expired keys. ...
      (Full-Disclosure)
    • telnet replacement - not ssh?
      ... the natural choice would be to switch to ssh. ... I need a telnet replacement that prevents hackers from snooping ... passwords but allowd me to give back-door acces to our security group, ... I think ssh can do what they want, if I use public/private keys and give ...
      (comp.security.misc)
    • telnet replacement - not ssh?
      ... the natural choice would be to switch to ssh. ... I need a telnet replacement that prevents hackers from snooping ... passwords but allowd me to give back-door acces to our security group, ... I think ssh can do what they want, if I use public/private keys and give ...
      (comp.security.ssh)
    • telnet replacement - not ssh?
      ... the natural choice would be to switch to ssh. ... I need a telnet replacement that prevents hackers from snooping ... passwords but allowd me to give back-door acces to our security group, ... I think ssh can do what they want, if I use public/private keys and give ...
      (comp.security.unix)
    • Re: ssh library attack
      ... > Or perhaps configure ssh to use only keys and not passwords. ... So I guess tcpwraper going to protect or keys protection is going to ... Don't have limited thought in security. ...
      (comp.os.linux.networking)