How much effort do you estimate it will take to teach Simutrans https using libcurl?
I find it untimely that Simutrans does not support https for the list server.
https://curl.se/libcurl/ (https://curl.se/libcurl/)
https://curl.se/libcurl/c/example.html (https://curl.se/libcurl/c/example.html)
I tried it. It is very hard, especially the certificates need frequent updates (apart from almost 100 MB for a full certificate chain). And libcurl does not work for Android, there one would need the Java native functions. Doable, but not by me.
Furthermore, there are no security sensitive data exchanged. And the changes to node are also needed. So lot of work for zero security gain.
The question is more what happens if http is blocked or removed.
It is already almost impossible to access websites via http with some browsers. So sooner or later we get to the point where the program reaches the list server but no one can access it via the browser.
https://developer.android.com/privacy-and-security/security-ssl (https://developer.android.com/privacy-and-security/security-ssl)
Since simutrans uses directly the sockets for http, it would not be affected by such a block. I highly doubt any browser would forbid http as this does not make sense. Many small servers (sensor etc.) cannot maintain the https protocal as this is way to power intensive.
Since the server data are not personlized, anybody gets the same data from the server, even if they listen to the communication. I fail to see the point of encryption then.
Anyway, adding https to node has been done by others, that will be possible. Simutrans on the other hand is not so easy to cenvert, each additional library makes things harder to maintain.
EDIT: Ok, progress, I could issue a certificate with a modfied server.js, now just to find out how to handle http and https simultaniously.
Following this discussion I believe there is one (currently not mentioned) point of view why a simutrans user could benefit from "https".
It has to do with user trust.
Requiring "https" would mean an extra check that the program is communicating with the correct list server instead of some rogue server that impersonates the list server (for whatever reason). An IP-address can be spoofed, correctly implemented certificates are a lot harder (if not near impossible).
Going with this train of thought that would also mean that there is NO need to provide "http" fallback inside simutrans if a user requires "https" (using a simuconf parameter?) since that would defeat the purpose for this use case.
https inside simutrans will not come. This is not portable enough and too much hassle for maintenance. The only one needing trust is the listserver when it receives the announcement. Hence, it does a reverse lookup of the announcing server with its connection informations. But that could be spoofed with https as well (or bad) as with http.
And if somebody wants to host another listserver, please go ahead. Or if somebody implements a way that https works on Mac, Linux, Windows, and Android using the installed certificates of the main system, well, it would be likely integrated.
By the way, simutrans itselves does not use http for the server messages, that "protocol" overhead is useless.
EDIT: list is now accessible via SSL too. Certifcate reneval is still work in progress.