Published on July 3rd, 2017 | by Sunit Nandi

We’re 100% HTTPS From Today – And Why So

From today, you will notice that the URL in the address bar is a bit different. That’s because the Techno FAQ blog is now on HTTPS. We at Techno FAQ take our members’ and readers’ security very seriously. Over the last few years, we’ve rolled out HTTPS on our forums, followed by DNSSEC on our domain name and started hosting our email and internal services in-house. We have done all this to ensure privacy of our users’ and advertisers’ data and ensure authenticity of our site (i.e. the Techno FAQ you are viewing is exactly the one you want to interact with).

The improvements after the switch should be already visible to you, which is summed up below:

HTTPS ensures the site you’re visiting is the authentic one.
Faster page loads with no render blocking due to the parallel nature of HTTP/2.
Inability of middleboxes and proxies to manipulate the connection and interfere with HTTP optimizations.
Attackers and eavesdroppers can no longer capture data filled into contact forms on the site.
HTTPS in conjuction with DNSSEC ensures that our site is resistant to DNS poisoning and man-in-the middle attacks.

If you have been reading articles on HTTPS migrations on the Internet all this while, you might ask why “SEO benefits” and “extra WordPress features” aren’t included in the above list? Well, frankly speaking, at Techno FAQ they didn’t influence our decisions and they are of secondary concern for us. If a webmaster’s motivation to switch to HTTPS is “ranking” and “features”, then their priorities are probably misplaced. These kind webmasters are the ones who jump into implementing HTTPS with reverse proxies like CloudFlare’s Flexible SSL, without understanding the major caveat: that the connection between the proxy and the origin web server is unencrypted and can be tampered with. This has happened in the past, with Airtel sniffing and censoring traffic CloudFlare’s traffic in India for sites that use Flexible SSL.

The 100% HTTPS Story

We have come across lots of emails advising us to make the switch since last year. Many of the emails even say it is a 5-10 minute switch. Well it does not actually take 10 minutes when running a serious blog with a lot of partners involved. Whereas rolling out HTTPS on the forum was easier because the zone was fully in our control and DNSSEC doesn’t require any action from site visitors and advertisers/partners.

So what was holding us for so long? We had a roadmap to switch to HTTPS back in 2015, but it kept getting postponed over and over again. The primary reasons were:

Ad networks back then were reluctant to implement HTTPS. We repeatedly kept requesting our ad serving partners to switch to HTTPS so that we could switch too.
Close to 6% visitors were using Windows XP and legacy Internet Explorer. Enabling HTTPS with support for them meant enabling insecure TLS ciphers and settings.
Around 5% of visitors who came from corporate environments voted against HTTPS adoption as their workplace blocks port 443 for sites other than those on their whitelist. Going HTTPS-only meant Techno FAQ would no longer be accessible by them. What is rather suprising is that many of them were from the Forture 500 companies list (makes you wonder who runs their IT dept?).

This was the situation until last year (2016). Despite our urge to make the jump to HTTPS, our circumstances made us put it off. Everytime we got close to the tentative deadline, some issue with ads or visitors would crop up, the deadline would be extended and the cycle would repeat over and over again.

2017 came, and it changed the situation a lot. The major observations were:

Ad networks, coming under pressure from publishers, finally made the switch to HTTPS. That means ads can be served securely without switching to plain HTTP in a browsing session. Your session data is only shared between the site you’re visiting and the ad partners and not to any random dude trying to wiretap your packets.
Techno FAQ’s site features, layout template and anti-abuse mechanism (to eliminate bruteforcing and comment spam) now require a JavaScript version which is no longer supported by Windows XP with IE7/8.
A huge number of visitors emailed with complaints that the site was loading slower now than last year. After following up with them and running network diagnostics, we found out that they were on ISPs running carrier-grade NATs (due to lack of public IPv4 addresses). Their port 80 was passed through a transparent proxy that cached webpages, so that they can be served faster opon subsequent loads. However, the revelation was that the transparent proxies were poorly configured or too old for modern standards, making it counterproductive to deploy them in the first place. We discovered cases where the transparent proxy disabled keep-alive on HTTP/1.1 making the browser open a new TCP connection for every asset it wanted to fetch. Sometimes they would disable HTTP optimizations like chunked encoding, GZIP and pipelining making page loads slower. In other cases, the connection would be altogether be downgraded to HTTP/1.0. Major issues like these reported by visitors across the globe simply nullified the effect of our performance improvements brought about by webserver optimizations and CDN usage.

Considering the above major observations, we finally decided it was the right time to switch. We left one remaining ad network which didn’t switch to HTTPS yet. We also stopped using web services that do not integrate with HTTPS sites. We also decided to forego Windows XP and IE compatibility as they were no longer relevant. Coming to corporate visitors who come from behind firewalls that restrict port 443, we decided to forego support for them too. (In 2017, if your workplace blocks HTTPS and you choose to stay employed there despite of this, then it is your problem, not the webmaster’s. After all if it is a policy to block port 443, you should be working and not browsing this site.) Given that a much larger set of the readership faces performance issues due to CG-NATs and transparent proxies now, trying to satisfy a small collection of corporate visitors didn’t matter any more. HTTPS at this time proved to be better for the readership.

Switching to HTTPS was a trivial change as we already had a roadmap back from 2015. We made the necessary changes in the web server and the site was finally running on HTTPS. We also notified search engines about the change in the URL. Very soon, the search engines would show up HTTPS URLs rather than HTTP ones showing up now.

Immediately the performance benefits of HTTP/2 came to light from the very moment we ran internal benchmarks. We contacted the visitors who were facing issues with intercepting/transparent proxies, and they reported a massive improvement in load times. In fact, now running even HTTP/1.1 on TLS turns out to be faster than running unsecured HTTP on port 80 with a badly configured transparent proxy or NAT. Since HTTPS bypasses your ISP’s caching and throttling mechanisms, you will get consistent performance irrespective of the network you are on. To top that, all other major HTTPS benefits like privacy and authenticity are already present.

Some of you might notice that we’re behind CloudFlare and use their TLS termination. You would also raise privacy concerns of “flexible SSL” like I raised a few paragraphs before. We assure you that you do not need to worry. We only use the Full Strict SSL mode with a valid certificate. Your connection to CloudFlare’s edge as well the connection from the edge to the origin web server is properly encrypted and authenticated.

It also means that in the future, if we decide to switch to a different caching proxy or CDN or even drop CDNs completely, you will still see a HTTPS site at https://technofaq.org with a valid certificate.

We hope you have a better, faster and more secure reading experience at Techno FAQ. We also appeal to you to switch your sites to HTTPS so that we all together can achieve the goal of HTTPS Everywhere to bring speed and security to every internet user.

IPv6 adoption

Another announcement is that we now support IPv6. IPv6-only users (like T-Mobile users in the US and Jio users in India) can now access our site without spending CPU power and increased latency brought about by using IPv6-to-IPv4 translation techniques like NAT64 or 464XLAT. Even though we’re behind CloudFlare, we run native IPv6 at our origin web server and do not use the 6-to-4 gateway. It implies that even if we change CDNs or stop using CDNs altogether in the future, our site will still be accessible over IPv6.

Thanks for reading! If you have any queries or concerns regarding the changes we have made, feel free to comment below.

Tags: 100, HTTPS, HTTPS everywhere

About the Author

Sunit Nandi I'm the leader of Techno FAQ. Also an engineering college student with immense interest in science and technology. Other interests include literature, coin collecting, gardening and photography. Always wish to live life like there's no tomorrow.