Date: Tue, 21 Aug 2001 18:22:59 -0500 (CDT) From: James Wyatt <jwyatt@rwsystems.net> To: Rob Simmons <rsimmons@wlcg.com> Cc: Matt Piechota <piechota@argolis.org>, Wes Peters <wes@softweyr.com>, "Carroll, D. (Danny)" <Danny.Carroll@mail.ing.nl>, freebsd-security@freebsd.org Subject: Re: Silly crackers... NT is for kids... Message-ID: <Pine.BSF.4.10.10108211807510.2334-100000@bsdie.rwsystems.net> In-Reply-To: <20010821150657.G21383-100000@mail.wlcg.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 21 Aug 2001, Rob Simmons wrote: > On Tue, 21 Aug 2001, Matt Piechota wrote: > > No No, on the realtime machine controllers (QNX), or OCR nodes that need > > all the cpu cycles they can get. I'm talking about the [de|en]crypt on > > the remote side, not the PC side. Every bit or performance matters, and > > could be the difference between us and someone else getting a contract. > > There should be a way to configure sshd so that only the username/password > exchange is encrypted. The rest of the connection would be unencrypted. > You would get some of the benefits of ssh without a constant performance > hit. IMHO, that would be a "bad idea" as it would 1) be easier to insert forged command packets after browsing what was going on, 2) break changing your password because it could be sniffed at change time, 3) not save *that* much CPU for tactical shell sessions, and 4) confuse users who thought SSH was always "safe" to use. When I've worked on embedded systems, if there wasn't enough CPU to encrypt/decrypt the stream, there was likely not enough CPU to run the commands I usually wanted. I avoid doing things that generated a lot of output because the network and system needed real-time priority for everything else going on. Large return flows either hurt the running (lower-priority), filled queues with backlog because a higher-priority task got IO and CPU first, or caused non-deterministic latency on the LAN. Be realistic about the relative overhead of encryption before spreading FUD. If the systems are so close their limits that encryption "hurts", you likely warrant a separate sub-network to reduce packet reception overhead on your nodes. If you do that, you can protect the entrance to that sub-network and save the encryption setup, diskspace, and overhead. - Jy@ btw: I have always been impressed at how much QNX can run in real-time on a SBC. I've also been impressed at how much stuff ports to it easily. I just wish I could afford enough of it to play with on my own more. (Besides the surfing platform on a single floppy demo they sent out...) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.10108211807510.2334-100000>