[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100908174923.GB2207@sentinelchicken.org>
Date: Wed, 8 Sep 2010 10:49:23 -0700
From: Tim <tim-security@...tinelchicken.org>
To: Andrew Auernheimer <gluttony@...il.com>
Cc: Full Disclosure <full-disclosure@...ts.grok.org.uk>
Subject: Re: [GOATSE SECURITY] Clench: Goatse's way to say
"screw you" to certificate authorities
> While we may be similar to other proposed ideas, our implementation is
> unique and we are rapidly developing a PAM module at this moment. We
> are not limited to https.
I would expect there to be quite a bit less value in adding something
like this to SSH for the following reasons:
* Users of SSH tend to be more savvy and can be expected to better
verify fingerprints.
* Fingerprints of servers are generally cached after the first
login, so the window of MitM is smaller than with HTTPS.
* SSH has several alternative authentication mechanisms already. SSH
public keys come to mind. Sure, you can use client certs with
SSL/TLS, but it's more effort than with SSH and admins can be
expected to figure out how to drop their keys on a server. Other
existing mechanisms include one-time passwords.
I'm not saying what you're considering isn't worthwhile, but before
you propose alternative solutions, do the research and see what's
already out there. If you like what's already out there, then
aid it's development/deployment and advocate it's usage. It's easy to
develop a new crypto protocol. It's really hard to get people to use
it.
tim
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists