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

TLS for sprunge.us #37

Open
jbg opened this issue Jan 21, 2016 · 7 comments
Open

TLS for sprunge.us #37

jbg opened this issue Jan 21, 2016 · 7 comments

Comments

@jbg
Copy link

jbg commented Jan 21, 2016

You could get a free Let's Encrypt cert and set up TLS on App Engine. If you only support SNI, which curl has had support for since 7.18.1 which was released in March 2008, there are no additional costs in doing this.

@Trozz
Copy link

Trozz commented Jan 26, 2016

defo +1

@strugee
Copy link

strugee commented Feb 12, 2017

@rupa ping? According to the above comment this is free...

@mikedld
Copy link

mikedld commented Jun 5, 2017

Why would you want HTTPS for public content where nobody gives a damn about authenticity and/or security? Just to spend additional time on handshakes?

@jbg
Copy link
Author

jbg commented Jun 5, 2017

@mikedld The fact that the content is public doesn't mean nobody gives a damn about authenticity.

If the site is served over HTTPS, I only trust sprunge.us to serve me (or others I send the URL to) the same content that I uploaded to that URL. If the site is not served over HTTPS I'm trusting a lot of additional parties in the middle. Trusting one party that I know a bit about, rather than trusting an unknown number of parties that are unknown to me.

I've traveled to countries where ISPs in the path inject things into certain types of content served over HTTP. I've seen advertising inserted into HTML many times, and in two countries I've come across malware. This is much harder to achieve over HTTPS -- it requires compromising a CA or installing a root certificate on the client device.

@strugee
Copy link

strugee commented Jun 5, 2017

Additionally even if something is public content, the fact that you're reading the content might be private information.

You don't know what situation your visitors are in - they could be in an abusive relationship, targeted by oppressive regimes, etc. Better to play it safe and protect them from eavesdropping.

Also, spending additional time on handshakes is (mostly) FUD. A properly configured TLS server won't have any additional round trips on subsequent visits because of session IDs and session tickets. And, TLS 1.3 has a 0RTT mode that allows zero round trips, even on initial connections (though it's disabled by default because it has security implications).

https://istlsfastyet.com

@Industrial
Copy link

+1 for HTTPS.

Any overhead argument is invalid. You are sending a few characters. 📜
Any I-like-to-do-it-without-security argument is invalid. Try insecure sex, see what happens. 🤦‍♂️

@zzo38
Copy link

zzo38 commented Sep 21, 2023

Please do not make mandatory HTTPS. Mandatory HTTPS is no good and HSTS is even worse. However, making it optional is good, and has advantages mentioned above. (Something that might be even better is if the URL includes the hash of the data, so that you can verify it even if you do not trust that the server operator has not tampered with it (something which HTTPS does not and cannot prevent).) (Also, injecting stuff into HTML seems not applicable if it is text/plain anyways?)

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

6 participants