91–100 of 105 posts
I read somewhere that SSH can be MITM'ed by a global adversary on the first visit (before it establishes the secure connection). Is that true?
Which threat model you prefer to deal with is up to you.
Earlier quoted context omitted.
SSH agent forwarding is extremely risky. Anyone with appropriate permissions (legitimate or illegitimately gained) on a machine you have connected to can use your credentials to open a new connection to any machine you have access to.
> on a machine you have connected to Don't you have to be actively connected to the machine for this to work? i.e. the server I haven't connected to for a few months has no way of opening connections on my behalf at this point, right?
What the...? Does the author just not know anything about SSH, or web browsers? Why would we use SSH for everything? On top of the fact that they're entirely different protocols and tools designed for entirely different purposes, browsers already support virtually everything SSH does. File transfers, authentication, client certs, multiplexing, key pinning, etc. There is no need to use SSH, and if you did, it would be…
What does this even mean? Your browser supports those things because it implements protocols, like HTTP, TLS, and others. Your browser, or other tools, could support SSH, which I think is the point of the article.
The article's title is "Why aren't we using SSH for everything?", not "Why don't browsers support SSH?". Both make no sense. It's like asking why FTP clients don't support Voice-over-IP.
For one thing, SSH performance for large transfers is abysmal over high-latency links. SSH uses a small TCP window size because it was optimized for quick response, not bulk transfers. (After all, it was designed to be a remote shell protocol, not a generic file transfer protocol; scp and sftp were added after the fact.) And unfortunately you can't currently specify a different buffer size even if you wanted to. More…
Would be pretty hairy though. Maybe another solution would be to have some new socket standard that can achieve what both UDP and TCP do, at some kind of variable window size...
Earlier quoted context omitted.
It's multiplexing support uses static sized windows, which even on modern LANs means you usually only see 3-5 mb/s transfer rates where you should be able to - even with encryption overhead - achieve almost gigabit NIC speed. Fortunately the HPN-SSH patches exist to solve this problem - but I really want to know why their's so much resistance to adding them upstream.
> which even on modern LANs means you usually only see 3-5 mb/s transfer rates where you should be able to On a WAN, sure, but even a mid-2000s gigabit LAN could routinely hit 800+Mb with scp as long as you had tuned the underlying TCP stack (Linux was poor and OS X/*BSD worse in that era) and weren't using something slow like 3-DES. > Fortunately the HPN-SSH patches exist to solve this problem - but I really want to…
But the NONE encryption makes a lot of sense in a "use SSH more" perspective. When you need to move piles of totally non-private data, but want to use a secure authentication mechanism (and message authenticity system) for issuing shell commands...
Earlier quoted context omitted.
It's multiplexing support uses static sized windows, which even on modern LANs means you usually only see 3-5 mb/s transfer rates where you should be able to - even with encryption overhead - achieve almost gigabit NIC speed. Fortunately the HPN-SSH patches exist to solve this problem - but I really want to know why their's so much resistance to adding them upstream.
> means you usually only see 3-5 mb/s I see over 50Mb/s (=~400Mb/s) on a gb network without any attempts at optimization, between a stupid Atom machine and a fast machine, both running Linux (which other responders claim is unoptimized). When did you last test? Also, this might be the speed of the disks at one of the ends - I've never even bothered to check, because making it faster doesn't make a difference for me.
These are not slow machines - i7's and i5's.
I've never been able to find a compelling explanation as to how this could be when other network protocols can manage it just fine.
"Why aren't we using a protocol designed to add encryption to pseudo-devices emulating a real text terminal device [1] for everything?"
Earlier quoted context omitted.
> means you usually only see 3-5 mb/s I see over 50Mb/s (=~400Mb/s) on a gb network without any attempts at optimization, between a stupid Atom machine and a fast machine, both running Linux (which other responders claim is unoptimized). When did you last test? Also, this might be the speed of the disks at one of the ends - I've never even bothered to check, because making it faster doesn't make a difference for me.
My experience with a 20-disk RAIDZ3 machine and my desktops has always been that SSH tops out at 3-5mb/s, which was why I could never understand the prevalence of advice to "just do your disk backup over SSH". The same disks Samba between Windows and Linux achieve 70-90 mb/s, and switching to HPN-SSH (in either Cygwin or Linux) gives me the same sort of speeds with the AES cipher or none cipher. These are not slow ma…
Something in your setup is broken. I get 50MB/s speeds when Linux is on both ends, and even when Cygwin is on one end.
It's not clear to me how SSH differs from SSL/TLS conceptually. It seems to me both achieve similar goals (encrypted tunnel, client/server authentication). Perhaps we should take the best bits of both protocols and create a new one? But then, I am reminded of http://xkcd.com/927/ .
SSH is designed to serve a single service on a single host. It distributes its host key on the first connection and caches it indefinitely, assuming it will never change. SSH is designed with a limited set of protocol features, and everything else is kind of hacked on top of proprietary client/server pairs. SSH is designed as a loose encrypted session (kind of like a pipe) for an application on a host. TLS is designe…
www.bank.com is 1.2.3.4 with pub key XYZ
Or is this already implemented and I am too stupid to find it?
Earlier quoted context omitted.
SSH supports CA-style key signing, and it also supports server fingerprint validation over DNSSEC (search for SSHFP DNS). Unfortunately neither of these things are commonly used yet. Cloudflare is adding DNSSEC support soon, so hopefully that will change.
It's going to take a lot more than Cloudflare adding DNSSEC support to make SSHFP records viable. Every system running an SSH client will need to run its own validating resolver. If you leave validation to an upstream server you lose a significant amount of security.