Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

marlifw.org is not served over HTTPS #218

Closed
radex opened this issue May 7, 2019 · 8 comments
Closed

marlifw.org is not served over HTTPS #218

radex opened this issue May 7, 2019 · 8 comments

Comments

@radex
Copy link

radex commented May 7, 2019

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

@thinkyhead
Copy link
Member

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.

@radex
Copy link
Author

radex commented Jun 14, 2019

There is no need for the site to be encrypted.

Sure there is! It's 2019, and all websites ought to be encrypted :)

  1. There are download links on Marlin website. When serving over http, it would be easy to replace those links to a malicious download
  2. Chrome and Safari mark the website as "Not Secure", which just looks bad and scary.

It's very easy and free these days to serve websites over HTTPS, so why not?

@thinkyhead
Copy link
Member

thinkyhead commented Jul 5, 2019

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.

@Uinden
Copy link

Uinden commented Dec 25, 2019

@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.

@thinkyhead
Copy link
Member

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.

@Uinden
Copy link

Uinden commented Jan 20, 2020

@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.

@thinkyhead
Copy link
Member

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.

@thinkyhead
Copy link
Member

Took a little tweaking, but it seems to work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants