title: “HTTPS considered harmful”, yes, but isn’t HTTP too?
url: https://medium.com/@MattiSG/https-considered-harmful-yes-but-isnt-http-too-1ee1f4a36358
hash_url: 5c4908deaee4ee1b6ddc32ffdca5c429

<p name="8e03" id="8e03" class="graf graf--p graf-after--h3 graf--trailing"><em class="markup--em markup--p-em">Since </em><a href="https://larlet.fr" data-href="https://larlet.fr" class="markup--anchor markup--p-anchor" rel="nofollow noopener" target="_blank"><em class="markup--em markup--p-em">David</em></a><em class="markup--em markup--p-em"> doesn’t allow public responses, I’ll try and follow his way of publishing letters in personal spaces.</em></p>

<div class="section-content"><div class="section-inner sectionLayout--insetColumn"><p name="5b65" id="5b65" class="graf graf--p graf--leading">Dear David,</p><p name="1d9c" id="1d9c" class="graf graf--p graf-after--p">Following on our conversation regarding your point that <a href="https://larlet.fr/david/stream/2018/01/06/" data-href="https://larlet.fr/david/stream/2018/01/06/" class="markup--anchor markup--p-anchor" rel="nofollow noopener" target="_blank">HTTPS is harmful</a>:</p><blockquote name="ba3c" id="ba3c" class="graf graf--blockquote graf-after--p">Encouraging everybody to switch to HTTPS promotes strong dependency to a third-party mafia, increases load time, makes your content inaccessible if you have any trouble reconducting your certificate, avoids migrating easily from one hosting platform to another, forces upgrading on a lot more security issues if you are hosting yourself. Even worse, when you switch there is no harmless turning back! <strong class="markup--strong markup--blockquote-strong">That’s not the Web I’m aiming for.</strong></blockquote><p name="430d" id="430d" class="graf graf--p graf-after--blockquote">To which I replied earlier a technical answer:</p><figure name="0796" id="0796" class="graf graf--figure graf--iframe graf-after--p"/><p name="9489" id="9489" class="graf graf--p graf-after--figure">There is now a <a href="https://larlet.fr/david/stream/2018/01/10/" data-href="https://larlet.fr/david/stream/2018/01/10/" class="markup--anchor markup--p-anchor" rel="nofollow noopener" target="_blank">new set of arguments</a> you’re putting forward. Here is my reply:</p><blockquote name="8294" id="8294" class="graf graf--blockquote graf-after--p"><em class="markup--em markup--blockquote-em">When you turn an oligopole into a monopole, it cannot be a mafia anymore, heh.</em></blockquote><p name="9288" id="9288" class="graf graf--p graf-after--blockquote">Let’s Encrypt not being a mafia does not mean it’s not a SPOF. The centralised model is bad. Question is not “is HTTPS perfect”, it is “is HTTPS better than HTTP”. Maybe we do not mean the same thing by “mafia”.</p><blockquote name="44a2" id="44a2" class="graf graf--blockquote graf--startsWithDoubleQuote graf-after--p"><em class="markup--em markup--blockquote-em">“0-RTT will reduce initial load time.” One day, maybe. But for now it’s quite limited to say the least.</em></blockquote><p name="137d" id="137d" class="graf graf--p graf-after--blockquote">We’ll see. TLS 1.2 did get a nice push forward thanks to Let’s Encrypt. With more cloud providers, docker images, shared Ansible configurations, and default Nginx setups, upgrading server setups goes faster than it used to.</p><blockquote name="22f1" id="22f1" class="graf graf--blockquote graf--startsWithDoubleQuote graf-after--p"><em class="markup--em markup--blockquote-em">“HTTP2 is good for performances.” […] HTTPS highly impacts my First Byte Time though.</em></blockquote><p name="deae" id="deae" class="graf graf--p graf-after--blockquote">Now we go into the details of what <em class="markup--em markup--p-em">is</em> performance. Of course if you consider TTFB, HTTP+TLS 1.2 is slower than HTTP. No argument here. Have you measured the difference in <a href="https://developers.google.com/web/tools/lighthouse/audits/first-meaningful-paint" data-href="https://developers.google.com/web/tools/lighthouse/audits/first-meaningful-paint" class="markup--anchor markup--p-anchor" rel="nofollow noopener" target="_blank">time to first meaningful paint</a> though? So often, that entails loading some CSS and images.</p><p name="a6cc" id="a6cc" class="graf graf--p graf-after--p">HTTP2 multiplexing allows me to keep CSS files split by components with no additional request cost, which then allows me to leverage cache at a very granular level, highly speeding up navigation.</p><blockquote name="5147" id="5147" class="graf graf--blockquote graf--startsWithDoubleQuote graf-after--p"><em class="markup--em markup--blockquote-em">“You have the guarantee your content is not altered.” Except if done once downloaded.</em></blockquote><p name="446d" id="446d" class="graf graf--p graf-after--blockquote">I don’t understand your point. Views being rendered on the client-side from controlled code is one thing, intermediaries injecting trackers or serving ads within your code is another.</p><blockquote name="9f6e" id="9f6e" class="graf graf--blockquote graf--startsWithDoubleQuote graf-after--p"><em class="markup--em markup--blockquote-em">“Don’t use HSTS!” I don’t get the point of providing content over HTTPS if you do not force it somehow</em></blockquote><p name="991a" id="991a" class="graf graf--p graf--startsWithDoubleQuote graf-after--blockquote graf--trailing">“somehow”, yes. A 301 or 302 is not the same as HSTS. That was a reply to your impression that having a certificate “makes your content inaccessible if you have any trouble reconducting your certificate”. Refusing to serve over HTTP but being able to do so if needed is not the same as explicitly forbidding recovery in case you cannot renew. One should use HSTS only if one has the resources to maintain that infrastructure properly, with recovery keys.</p></div></div>
<section name="d794" class="section section--body section--last"><div class="section-divider"><hr class="section-divider"></div><div class="section-content"><div class="section-inner sectionLayout--insetColumn"><p name="21f2" id="21f2" class="graf graf--p graf--leading">I don’t argue HTTPS is overkill for many uses, especially for websites that provide read-only, low-importance information, and I do agree with your underlying expectations of simplicity and performance. My replies are only there because you used several technical arguments that I consider slightly exaggerated. You mention “not in my case”, then it would be worth describing that case more precisely in the article (though I think I see the kind of small, server-rendered, simple website you’re talking about and that I also tend to ship).</p><p name="23a7" id="23a7" class="graf graf--p graf-after--p">I’d argue that there’s a flip side to the ethical arguments too, though, and these are the ones that personally convinced me to take the burden of the added complexity.</p><p name="b1c9" id="b1c9" class="graf graf--p graf-after--p graf--trailing">You’re right, “<em class="markup--em markup--p-em">That’s not the Web I’m aiming for</em>.”. But the Web where corps <a href="https://www.eff.org/deeplinks/2014/11/verizon-x-uidh" data-href="https://www.eff.org/deeplinks/2014/11/verizon-x-uidh" class="markup--anchor markup--p-anchor" rel="nofollow noopener" target="_blank">inject ad trackers</a> in traffic and where government agencies massively <a href="http://static.guim.co.uk/sys-images/Guardian/Pix/audio/video/2013/7/31/1375269604628/KS8-001.jpg" data-href="http://static.guim.co.uk/sys-images/Guardian/Pix/audio/video/2013/7/31/1375269604628/KS8-001.jpg" class="markup--anchor markup--p-anchor" rel="nofollow noopener" target="_blank">tap HTTP</a> isn’t either. And in this game, as a professional developer, I prefer to take on the complexity and work harder to optimise my content for performance in order to protect my users, and the users of the Web in general. For sure, certificate issuers are now honeypots, and we need to keep pushing for decentralised trust. But <a href="http://mattischneider.fr/h4yr/" data-href="http://mattischneider.fr/h4yr/" class="markup--anchor markup--p-anchor" rel="nofollow noopener" target="_blank">the IX were already</a>, and it has become way too easy for intermediaries to do anything they want on clear text to refuse taking care of the privacy of our users. I am glad Wikipedia is served over HTTPS, not because I’m afraid my ISP will change the birth date of Napoleon, but because I don’t want it to know which articles I’m reading at what time. The profiling power of aggregated metadata is too strong for us not to make it as hard as we can for spies to leverage it against our fellow netizens.</p></div></div></section>
