potatomushclient / potato

A Graphical MUSH Client for Windows, Linux and Mac OS X -
http://www.potatomushclient.com
30 stars 3 forks source link

Offer to upgrade connection to SSL when available. #395

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
At least some MU*s support an extension to the MSSP which allows advertising a 
port for connections using SSL. As far as I know, no clients actually take 
advantage of this fact to do the sensible thing in such a situation. I propose 
that potato should take this initiative. This would significantly improve 
discoverability for encrypted connection support, making the MU* world that 
much more secure. It would also make for a nice, if relatively minor, usability 
improvement.

When a MU* (displayed as 'MUD' in the output example below, but this should 
change as appropriate) to which we are connecting insecurely implements MSSP 
and reports an SSL port in the usual MSSP fashion, potato ought to prompt the 
user with the option to upgrade the connection to SSL, offering something along 
the lines of the following example:

---

This MUD reports that it can accept secure connections which protect against 
eavesdropping. We are currently using a normal, unsecured connection. Would you 
like me to connect securely instead?

    [Yes, secure the connection.]   [No, keep connecting normally.]

[] Remember my choice for this MUD.
[] Use this choice for all MUDs.

---

Clicking the Yes button with no checkboxes checked terminates the connection in 
progress and starts a new one to the newly discovered SSL port. Clicking the No 
button with no checkboxes checked continues transmitting on the current 
connection as if nothing had happened.

Clicking the Yes button with the 'Remember my choice for this MUD' checkbox 
checked does the same thing as clicking it with no boxes checked, and also 
alters the world definition for the MU* in question to record the SSL port as a 
replacement for the connection that triggered this message (that is, the SSL 
port becomes part of the primary address for the MU* if the connection was to 
the primary address, or the secondary address if that was the one to which we 
connected), so that future attempts to connect to this world will automatically 
use SSL. Clicking the No button with the '[...] this MUD' checkbox checked does 
the same thing as clicking it with no boxes checked, and also permanently 
records an exclusion such that that particular address for that particular 
world will never prompt again.

Clicking the 'Use this choice for all MUDs' checkbox will disable the 'Remember 
my choice for this MUD' checkbox, as its effect is implicitly included.

Clicking the Yes button with the '[...] all MUDs' checkbox checked will do the 
same thing as clicking it with the '[...] this MUD' box checked, and also 
perform the same action instead of prompting whenever this would come up again 
in the future. Clicking the No button with the '[...] all MUDs' checkbox 
checked will continue using the current connection and disable the SSL upgrade 
feature permanently. It should be possible later to re-enable the feature in 
the program settings.

As an additional note, if we are connecting insecurely to the secondary address 
of a world entry, and the primary address of the world entry appears to be the 
same address and port which the server reports for SSL use in the MSSP, we 
should assume that the SSL port was inaccessible, and not prompt the user, 
since the user's affirmative choice would likely only be destructive.

Finally, autoconnects should not prompt the user in any way (especially since 
the user may not see it for an arbitrarily long time); instead, I think, if an 
'all MUDs'-style choice has not already been made, a checkbox in the 
autoconnect setup should permit the user to decide whether or not to 
automatically upgrade to SSL if available. (The reason for doing this instead 
of expecting the presumably sufficiently advanced user to know what protocol it 
wants to use is simply that an SSL port which did not previously exist may be 
advertised at some point in the future, and we should be able to respond to 
this intelligently.)

Original issue reported on code.google.com by t...@funview.pennmush.org on 7 Jun 2014 at 6:46

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Second!

Original comment by personto...@gmail.com on 7 Jun 2014 at 7:02

GoogleCodeExporter commented 9 years ago
I intend to add support for the STARTTLS telnet option at some point, which is 
a more proper way to handle this (it doesn't require disconnecting, it just 
negotiates securely in the existing connection). Something like this may be 
suitable as a backup, though.

Original comment by mike@keyboardzombie.com on 10 Jun 2014 at 11:07