[14201] in Athena Bugs
Re: telnetd: spurious "You must use the encryption option"
daemon@ATHENA.MIT.EDU (brlewis@MIT.EDU)
Tue Feb 20 10:23:46 1996
From: brlewis@MIT.EDU
Date: Tue, 20 Feb 96 10:23:41 -0500
To: Greg Hudson <ghudson@MIT.EDU>
Cc: bugs@MIT.EDU
In-Reply-To: "[14200] in Athena Bugs"
>This is clearly a problematic way of fixing the bug, especially
>because libtelnet and telnetd use alarm() in many other parts of the
>code.
Unless I'm missing something, alarm() is used three non-overlapping times:
I) libtelnet/auth.c: in auth_wait()
as the user is authenticated
II) in my patch
after the user is authenticated; before login is started
III) telnetd/sys_term.c: in startslave()
when (in BSD 4.4) telnetd asks init to start login
>Please explain what's wrong with the protocol such that timeouts are
>needed before forking login. Shouldn't telnetd simply initiate
>request for authentication and encryption, and wait for the response?
I don't know whether to call this a problem with the protocol. If one
were to augment the protocl to get around this problem, one would need
to add something like "ENCRYPT WONT START". If a client supports
encryption, there's no way to know when/if it will actually begin
encrypting its output (telnetd's input).
There's no response for telnetd to wait for. It may already have
received "WONT ENCRYPT" or "WILL ENCRYPT SOMEDAY IF I FEEL LIKE IT", but
the key response is either "ENCRYPT START" or nothing. The timeout is
needed in case it's nothing.
XXX CORRECTION TO COMMENT IN PATCH:
+ ttloop(); /* hopefully receive ENCRYPT REQUEST-START */
should read
+ ttloop(); /* hopefully receive ENCRYPT START */
XXX
Note that the timeout happens under specific conditions:
(AND client has sent "WILL ENCRYPT"
telnetd has started encrypting its output - encrypt_wait();
telnetd was called with -a off (always ask for password)
)
So the timeout won't happen unless it really is needed.
