Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why aren’t we using SSH for everything? (2015)

medium.com

Post reply on HN
Print view View original

11–20 of 87 posts

Re: Why aren’t we using SSH for everything? (2015)

#11

Post by tptacek »

sargun wrote: post #8
dozzie wrote: post #2

> Programmatic Data Streams > RPC API Please don't. Managing SSH sensibly (with checking keys properly) in any greater scale is awful. SSH was never meant for general communication, which reflects how it operates on implementation level and on protocol level. SSH servers require usable home directory locally and remotely (OpenSSH has some workarounds, but this quickly becomes ugly), you need to manage SSH keys, both…

SSH is also implemented by Golang, and Erlang (And probably a bunch of other languages). You're right that traditional SSH clients tend to need long-term storage, but one could easily turn off host key caching, and look to SSHFP records ( http://www.ietf.org/rfc/rfc4255.txt ) instead. I'd actually argue that SSHFP records are analogous to DANE. Paired with DNSSEC, I'm not there there's a practical attack there. As fa…

By "no practical attack", you mean, "as long as you trust whichever government controls your TLD and whichever governments effectively control the global DNS root" --- which, for most of the hosts people on HN contact, means "as long as you trust the NSA".

DNSSEC is a disaster. Avoid it.

http://sockpuppet.org/blog/2015/01/15/against-dnssec/

Re: Why aren’t we using SSH for everything? (2015)

#12

Post by userbinator »

sargun wrote: post #6
deathanatos wrote: post #3

> Fortunately, as long as the proxy doesn’t have the original server’s private key, then the key fingerprint will be different. Will it? What is the proxy server happens to have a key whose fingerprint hash is the same as the original server's key? SSH very recently upgraded how keys are fingerprinted; the screenshots in this article are the old method, which as I learned recently, are MD5 hashes. (I had thought they…

I'm not sure how easy it is to forge a fingerprint. Given most of the MD5 collision work was done based on length-extension attacks, I think SSH is somewhat more tolerant to these. Nonetheless, your point stands - it is possible to forge a key that has the same fingerprint as the original server, but I cannot think of any practical way to do this.

Nonetheless, your point stands - it is possible to forge a key that has the same fingerprint as the original server, but I cannot think of any practical way to do this.

If I understand correctly that's basically a preimage attack, and even for MD5 where you can find arbitrary colliding pairs very easily today, AFAIK no one has come up with a single preimage example or practical attack.

Re: Why aren’t we using SSH for everything? (2015)

#14

Post by cturner »

tptacek wrote: post #10

Because it's not a very good protocol. Adopting it, instead of HTTP/2 and TLS 1.3, basically gets you everything that is bad about TLS (most notably, a legacy of 1990s cryptography) and everything that is bad about SSH (poor performance, extreme complexity), and leave you with no upsides. For instance: the HTTPS stack will, with effort, allow you to opt in to protocol forwarding, via mechanisms that were designed to…

In the article, it shows a chat server as an example. Imagine the same app implemented using HTTPS. Would openssl s_client be effective as a client? [I suspect not, as HTTPS != SSL, but perhaps my naive question will prompt suggestion of a better approach from someone with a clear understanding of the layers.]

Update: looks like an effective tool could be socat, which seems to be a SSL-capable take on netcat. On the server side, reckon it would work to use stunnel. You could have xinetd host a launcher that wraps stunnel around a simple socket server. Clients could connect to that with socat.

Re: Why aren’t we using SSH for everything? (2015)

#15

Post by tptacek »

cturner wrote: post #14
tptacek wrote: post #10

Because it's not a very good protocol. Adopting it, instead of HTTP/2 and TLS 1.3, basically gets you everything that is bad about TLS (most notably, a legacy of 1990s cryptography) and everything that is bad about SSH (poor performance, extreme complexity), and leave you with no upsides. For instance: the HTTPS stack will, with effort, allow you to opt in to protocol forwarding, via mechanisms that were designed to…

In the article, it shows a chat server as an example. Imagine the same app implemented using HTTPS. Would openssl s_client be effective as a client? [I suspect not, as HTTPS != SSL, but perhaps my naive question will prompt suggestion of a better approach from someone with a clear understanding of the layers.] Update: looks like an effective tool could be socat, which seems to be a SSL-capable take on netcat. On the…

I'm not sure I understand the comparison. openssl s_client creates a TLS connection, but doesn't drive the HTTP protocol; it's a generic bidirectional encrypted transport. Lots of chat protocols use TLS in exactly this manner.

But I'm going a step further: I think even if you're stuck with HTTPS/HTTP/2, you're still better off tunneling your application protocol over that than SSH.

Re: Why aren’t we using SSH for everything? (2015)

#16

Post by dsl »

tptacek wrote: post #11
sargun wrote: post #8

Earlier quoted context omitted.

SSH is also implemented by Golang, and Erlang (And probably a bunch of other languages). You're right that traditional SSH clients tend to need long-term storage, but one could easily turn off host key caching, and look to SSHFP records ( http://www.ietf.org/rfc/rfc4255.txt ) instead. I'd actually argue that SSHFP records are analogous to DANE. Paired with DNSSEC, I'm not there there's a practical attack there. As fa…

By "no practical attack", you mean, "as long as you trust whichever government controls your TLD and whichever governments effectively control the global DNS root" --- which, for most of the hosts people on HN contact, means "as long as you trust the NSA". DNSSEC is a disaster. Avoid it. http://sockpuppet.org/blog/2015/01/15/against-dnssec/

I hate to add "me too" replies, but it is important to get the message out there that lots of really smart folks consider DNSSEC an absolute failure of such epic proportions that you shouldn't even joke about building something real on top of it.

The only thing DNSSEC has given us is widespread DDoS amplification.

Re: Why aren’t we using SSH for everything? (2015)

#17

Post by cturner »

tptacek wrote: post #15
cturner wrote: post #14

Earlier quoted context omitted.

In the article, it shows a chat server as an example. Imagine the same app implemented using HTTPS. Would openssl s_client be effective as a client? [I suspect not, as HTTPS != SSL, but perhaps my naive question will prompt suggestion of a better approach from someone with a clear understanding of the layers.] Update: looks like an effective tool could be socat, which seems to be a SSL-capable take on netcat. On the…

I'm not sure I understand the comparison. openssl s_client creates a TLS connection, but doesn't drive the HTTP protocol; it's a generic bidirectional encrypted transport. Lots of chat protocols use TLS in exactly this manner. But I'm going a step further: I think even if you're stuck with HTTPS/HTTP/2, you're still better off tunneling your application protocol over that than SSH.

Part of the appeal of the ssh chat server from the article is that you can connect to the server using an existing console tool. It's not necessary to have a purpose-built client. So I've been trying to think: how could you get that convenience, but using HTTPS instead of SSH. [based on your example above]

In an update above I've talked about socat. That's less convenient than ssh, because socat is obscure vs ssh.

A hassle I've had trying to get a SSL server going in this last hour - it seems like you need to be signed by a recognised authority. ssh is convenient in that you get solid encryption, but you only need a fingerprint, not an authority sig.

Re: Why aren’t we using SSH for everything? (2015)

#18

Post by TillE »

userbinator wrote: post #12
sargun wrote: post #6

Earlier quoted context omitted.

I'm not sure how easy it is to forge a fingerprint. Given most of the MD5 collision work was done based on length-extension attacks, I think SSH is somewhat more tolerant to these. Nonetheless, your point stands - it is possible to forge a key that has the same fingerprint as the original server, but I cannot think of any practical way to do this.

Nonetheless, your point stands - it is possible to forge a key that has the same fingerprint as the original server, but I cannot think of any practical way to do this. If I understand correctly that's basically a preimage attack, and even for MD5 where you can find arbitrary colliding pairs very easily today, AFAIK no one has come up with a single preimage example or practical attack.

Right, none of the published MD5 attacks allow you to generate data to match a specific hash value. It's certainly a good idea to avoid MD5, but it's not easily exploitable in most situations.

Re: Why aren’t we using SSH for everything? (2015)

#19

Post by scintill76 »

eru wrote: post #9

Some MUDs already support ssh, don't they? I know that some nethack servers do.

I think I've seen that implemented by using a standard SSH server and having the remote shell be essentially the command "telnet localhost". You would want to make sure to disable port forwarding, running other commands, etc.
Post reply on HN