Hey there! Thanks for helping Mudlet improve. 🌟

Test versions

You can directly test the changes here:

• linux: https://make.mudlet.org/snapshots/668474/Mudlet-4.16.0-testing-pr6409-f14c6d40-linux-x64.AppImage.tar
• osx: https://make.mudlet.org/snapshots/bc13f8/Mudlet-4.16.0-testing-pr6409-f14c6d40.dmg
• windows: https://make.mudlet.org/snapshots/46c380/Mudlet-4.16.0-testing-pr6409-f14c6d40-windows.zip

No need to install anything - just unzip and run.
Let us know if it works well, and if it doesn't, please give details.

Cool idea! Thanks for implementing it @mpconley 🎉 🔒 🎉

I would also be curious if you or the Mudlet developers have thought about adding RFC 2941 support for using AUTHENTICATION negotiation to upgrade an existing telnet connection to use encryption opportunistically. I haven't found any MUD clients with support yet, so I've been putting off implementing support in my server. Very possible MUD client developers are playing the same chicken/egg game from the other side :-)

respond to detection of the SSL key of MSSP (Mud Server Status Protocol)

I don't know how tightly specified MSSP is but I'd love to see Mudlet also respect a TLS key when detected in the MTTS information. It's pedantic but I hate to propagate the legacy protocol name further.

This would introduce the complication of having to decide what to do if a server's MTTS info contains both keys. It seems reasonable to prefer the TLS key in that case. WDYT?

TLS builds on the now-deprecated SSL (Secure Sockets Layer) specifications

Source: https://en.wikipedia.org/wiki/Transport_Layer_Security

Better rename SSL to TLS.

I would also be curious if you or the Mudlet developers have thought about adding RFC 2941 support for using AUTHENTICATION negotiation to upgrade an existing telnet connection to use encryption opportunistically.

I've thought about this problem, did not know there was a spec already for it. Would be very happy to see this supported in Mudlet.

I don't know how tightly specified MSSP is but I'd love to see Mudlet also respect a TLS key when detected in the MTTS information. It's pedantic but I hate to propagate the legacy protocol name further.

Agreed!

This would introduce the complication of having to decide what to do if a server's MTTS info contains both keys. It seems reasonable to prefer the TLS key in that case. WDYT?

Also agreed.

TLS builds on the now-deprecated SSL (Secure Sockets Layer) specifications

Source: https://en.wikipedia.org/wiki/Transport_Layer_Security

Better rename SSL to TLS.

I will add a TLS key as well into the code. Current games are using SSL as the port indicator.

I would also be curious if you or the Mudlet developers have thought about adding RFC 2941 support for using AUTHENTICATION negotiation to upgrade an existing telnet connection to use encryption opportunistically. I haven't found any MUD clients with support yet, so I've been putting off implementing support in my server. Very possible MUD client developers are playing the same chicken/egg game from the other side :-)

If you'd consider implementing it in your MUD and LDMud 2.4.5 code, I may be able to do the Mudlet side of the equation. I could do the MUD side too (and perhaps will!) but you've got the mad skills and it will take me longer :)

I don't know how tightly specified MSSP is but I'd love to see Mudlet also respect a TLS key when detected in the MTTS information. It's pedantic but I hate to propagate the legacy protocol name further.

Were you thinking a TLS key to carry over the port information via MTTS, or for authentication? I have MTTS in my game, but it is an odd protocol, and we'd need to cut @SlySven 's internet access for a while to get it merged into Mudlet :) Would be nice to know how many games are implementing to understand the value of adding it.

If you'd consider implementing it in your MUD and LDMud 2.4.5 code, I may be able to do the Mudlet side of the equation.

👍 - I'll take a look at doing that. I think Gnomi contributed the hard parts but hasn't wired them up in the 2.4.5 example game.

Were you thinking a TLS key to carry over the port information via MTTS

@mpconley I was thinking that in the Mud Server Status Protocol I'd like to support sending TLS = "$PORT" in place of (or alongside if required for interop with other clients) SSL = "$PORT", and have Mudlet detect it to prompt users on a telnet port to switch.

@mpconley I was thinking that in the Mud Server Status Protocol I'd like to support sending TLS = "$PORT" in place of (or alongside if required for interop with other clients) SSL = "$PORT", and have Mudlet detect it to prompt users on a telnet port to switch.

OK, cool. The latest build here supports TLS = "$PORT" now with MSSP.

Test cases passed on: ats.trekmush.org 1701 and cheeseworld.wtf 3000 to respond to MSSP and flip them over to TLS.

I don't have MSSP setup on dunemud.net but on dev.dunemud.net the MSSP info was updated with both TLS and SSL keys in case you want a test host advertising both. You should be able to hit dev.dunemud.net:4242 (telnet) and get prompted to switch to dev.dunemud.net:4241 (TLS).

Worked for me!

Nice login controls once you get inside the game to lock people down to the TLS port, @cpu !

Great stuff. Just highlighting that #6409 (comment) has up to date links with dev builds that you can unzip and run.

So this is functional, but on the preference screen where the new preference is I'm also seeing an extra box outline

And in Light mode, it is behind the checkbox

Other than that, it lgtm

🤦‍♂️ That option in the preferences should be a QCheckBox NOT a QGroupBox there is not other information to be displayed within the element so it shouldn't be a container-type widget. {Edit: That is why Demonnic is seeing that extra empty box - and the reason why the two examples he showed looked different is that in "Dark mode" the Style factory used is forced to be Qt's own "Fusion" one whereas in "Normal" /"Light" mode it uses whatever is the default for that OS which on Windows is "windowsvista" and on MacOS is something else - and they do look different!}

Also please call the widget in the form/dialogue something beginning with checkBox_ rather than something beginning with m. It helps to keep track what shape the knob has in the C++ methods that use it.

Also also, can you check that if you are multi-playing (have another profile already open, can be to a different MUD) that the QMessageBox that pop-up does NOT stop things working in the other profile while it is waiting for an answer. I have a nasty suspicion that (particularly on WIndows) such an item stalls the main event-loop which might not be a good idea. See: https://doc.qt.io/qt-5/qmessagebox.html#exec and for further enlightenment I found this article {incidentally by the guy behind the "QtKeychain" interface to the OS's secure storage system library!}

I put my IP address and unencrypted port into a new profile, connected. It brings up the question. I click Yes. It reconnects, brings up the profile preferences window, "The host name did not match any of the valid hosts for this certificate", which is completely appropriate, as my certificate is issued for the domain name and not IP address.

On the preferences window there are options to "Accept self-signed certificates", "Accept expired certificates", "Accept all certificate errors". Nothing sounds like accept this specific certificate (which is outside the scope of this PR, but perhaps something to consider later).

172.105.4.154 7680 for StickMUD does the same thing.

MSSP does usually have "HOSTNAME". Perhaps offer to change both the port and also the hostname if it does not match the stored hostname, with an updated message that mentions this.

Then I tried 192.99.10.40 3000 for Cheeseworld, clicked yes, and it went straight into it. At first I figured maybe their certificate is configured different than me and StickMUD and includes the IP and I should be doing the same on mine? I look in the connection tab and it says issued to coremud.org. I look in Chrome and https://coremud.org uses a certificate that says Certificate Subject Alternative Name has coremud.org, cheeseworld.wtf, and core.evilmog.io. I guess because the reverse lookup of the 192.99.10.40 returns coremud.org, that's what made it working match? Mudlet connected with [ INFO ] - Looking up the IP address of server: 192.99.10.40:3022 ... [ INFO ] - Trying secure connection to coremud.org: 3022 ... so I guess it is aware of the reverse lookup even though it was given the IP directly. What I probably should do on my own game next time I mess with letsencrypt I guess is either set the reverse lookup to say my domain name, or else change my certificates to include the Google Cloud name.

Anyway, after I have connected to Cheeseworld with the secure port and saved my profile and then closed and reopened client, that profile comes up saying 192.99.10.40 3022 with secure checked, with the connect button disabled and a warning saying SSL connections require URL. So they'd benefit from utilizing HOSTNAME even though their switching over worked initially.

You needed the latest development code as I broke that branch recently...

So this is functional, but on the preference screen where the new preference is I'm also seeing an extra box outline

And in Light mode, it is behind the checkbox

Other than that, it lgtm

@demonnic could you take another look now? This is now a QCheckBox. I had my reasons on Mac for doing what I did, but your comments provided insight that needed addressed for other platforms - so thank you!

Also please call the widget in the form/dialogue something beginning with checkBox_ rather than something beginning with m. It helps to keep track what shape the knob has in the C++ methods that use it.

@SlySven this naming conflict is resolved.

Also also, can you check that if you are multi-playing (have another profile already open, can be to a different MUD) that the QMessageBox that pop-up does NOT stop things working in the other profile while it is waiting for an answer. I have a nasty suspicion that (particularly on WIndows) such an item stalls the main event-loop which might not be a good idea. See: https://doc.qt.io/qt-5/qmessagebox.html#exec and for further enlightenment I found this article {incidentally by the guy behind the "QtKeychain" interface to the OS's secure storage system library!}

@SlySven QMessageBox is also used with downloading a map in Mudlet, and things keep happening in the background during that dialog being open, so that is evidence that the main event loop is not halted completely. I took the advice of the article you shared, which uses a QPointer and uses a delete right after the exec() is called. This differs from the OTB example from the Qt documentation of QMessageBox. The change works the same. Hopefully straying from the documentation does not lead someone in the future to ask WTH this Tamarindo was thinking when he created this QPointer.

172.105.4.154 7680 for StickMUD does the same thing.

Thank you @atari2600tim. This inspired some more changes. I limited this from prompting if there are any scenarios out there that could lead to confusion for non-technical users. For now, this will filter out prompting profiles that are using an IP address as their host name. Also, decided not to prompt if a HOSTNAME is define by MSSP, but that does not match the host name in Mudlet. That could be an indicator that a game has not updated their MSSP information over time and provides the slightest reason not to prompt.

Handled known comments to date and no more changes planned from my side.

Try out 172-105-4-154.ip.linodeusercontent.com 7680 (not that any players would be using that, but just to be thorough)

"Issued to" is probably enough for a geeky type to figure out what's going on, someone who is setting up their own game or something I mean.

172-105-4-154.ip.linodeusercontent.com 7680

Cool. Tested and I did not see anything I did not expect there.

LGTM, thanks!