-
Notifications
You must be signed in to change notification settings - Fork 70
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
Comments
defo +1 |
@rupa ping? According to the above comment this is free... |
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? |
@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. |
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). |
+1 for HTTPS. Any overhead argument is invalid. You are sending a few characters. 📜 |
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 |
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.
The text was updated successfully, but these errors were encountered: