Update on user-level hack to do telnet encryption posted recently
Perry doesn't like Graham's hack for telnet style encryption. Graham doesn't like Perry's attitude. Such a _small_ teapot. For the forseeable future, there will be the need for link encryption where one is connecting to a site where the far end doesn't have encrypted telnet available, _for_whatever_reason_at_all. There are lots of reasons, e.g. site managers are busy and the user did not plan in advance. It doesn't really matter. If you can't alter the remote end except by a user process, that's what you use. Perry is absolutely correct that this hack is very bad as a long-term solution, but it is labelled a hack, after all. Nevertheless, there is need for a short term solution. Graham seems to have provided one part of that. Great. Just because you shouldn't need to be using it in two years is no reason to say it shouldn't be written. Eric
Eric Hughes says:
For the forseeable future, there will be the need for link encryption where one is connecting to a site where the far end doesn't have encrypted telnet available, _for_whatever_reason_at_all. There are lots of reasons, e.g. site managers are busy and the user did not plan in advance. It doesn't really matter. If you can't alter the remote end except by a user process, that's what you use.
I strongly disagree. If you truly insist, run your own telnetd on the remote machine. Don't run a hack. However, the right solution is to get the site manager to replace their telnet, a process that takes minutes and which, given the current epidemic of line tapping, is of obvious necessity even to the brain damaged. As I've noted, however, its trivial to run your own telnetd on another port if you absolutely insist. Perry
participants (3)
-
hughes@ah.com -
Perry E. Metzger -
tim werner