Closed radex closed 5 years ago
Marlin is not a dynamic site and neither requests nor stores user data (in spite of the required cookie notice). There is no need for the site to be encrypted.
There is no need for the site to be encrypted.
Sure there is! It's 2019, and all websites ought to be encrypted :)
It's very easy and free these days to serve websites over HTTPS, so why not?
Be sure to pass this on so people understand:
All of our file downloads are links to HTTPS:// GitHub, not hosted on "quote" marlinfw.org.
I am personally of the opinion that these concerns are overwrought. Malicious files can be served from a secure HTTPS server just as easily simply by getting them onto those site's servers, which is actually a far easier exploit than DNS poisoning.
But here's the crux of the thing. I am very busy and right now with many concerns and I don't feel like going out and obtaining a certificate and dealing with the installation and all of that.
This is a volunteer organization and we all pitch in how we can, according to our specialties and our interests. It sounds like you are much more interested in this subject than me. So, I think you should obtain the certificate and you should help one of our volunteers get it installed. Your efforts would be appreciated.
@thinkyhead
All of our file downloads are links to HTTPS:// GitHub, not hosted on "quote" marlinfw.org.
Attacker can easily replace links to his own, served from his own server. Just saying.
Attacker can easily replace links to his own, served from his own server. Just saying.
Alas, https does not prevent that in any way whatsoever. All HTTPS or SSL does is ensure that no one in the middle can decrypt the packets between you and the server. They can only be decrypted at the endpoints.
@thinkyhead HTTPS does prevent that. Probably you misunderstood what I mean. For example you serve HTML code
<a href="https://github.com/marlin.exe">Download marlin</a>
over HTTP. Then attacker can connect to your WiFi (for example) and do ARP spoofing (for example) and route all your traffic through his machine. And then replace HTML on page to
<a href="http://1.2.3.4/marlin.exe">Download marlin</a>
on the fly. Then when you click Download marlin
you no longer downloading HTTPS link file. It will be file served by attacker from his own server.
So point
All of our file downloads are links to HTTPS:// GitHub, not hosted on "quote" marlinfw.org.
has no sense or security when HTML code with those links served over HTTP.
D'oh! Yes, of course you are correct. I was only considering the case of someone who managed to get a bad link into the legitimate site by some means. But truly, the site being open source makes this night impossible.
In any case, GitHub has made it much easier to use HTTPS, so we'll give it a try and see how it goes.
Took a little tweaking, but it seems to work!
Marlin's website is served over HTTP, which major browsers (Chrome, Safari) are rightly pointing out is not secure.
It seems easy enough to set up Let's Encrypt to manage SSL certificates automatically. Is there a specific issue preventing you from adopting HTTPS?
Perhaps that's something I can help with? I recently set up https on my website (https://radex.io), which also uses Jekyll