At $previous_job we once turned on HTTPS for our entire customer website and online store, only to have our customer support team be bombarded by phone calls claiming that our "website was down."<p>After much teeth gnashing and research, we determined that a large segment of our user base was still using WinXP and the encryption protocols we offered weren't available to them.<p>We didn't think this would be a problem because the current version of the software wasn't compatible with WinXP any longer.<p>There was some debate internally whether the better fix was to including the legacy encryption protocols or just leave the HTTP version of the site running and use Strict-Transport-Security to move capable browsers to HTTPS.<p>In the end we had to include the legacy protocols so those customers could use our online store.
> The password to our data center is pickles. I didn’t think anyone would read this far and it seemed like a good place to store it.<p>You ought to have more confidence in your writing. BRB stealing all your servers.
This is incredibly detailed; in short, CDNs, cookies/authentication , tons of subdomains, and 3rd-party/user-generated content make it a pain to move onto HTTPS.<p>I was chatting with a non-engineer friend about why it's hard to estimate how long tasks often take, and this seems like a prime illustration: the dependencies are endless.<p>I also love the Easter egg:<p>"The password to our data center is pickles. I didn’t think anyone would read this far and it seemed like a good place to store it."
Stack Exchange is no longer available from my workplace due to this change. We have a strict no-posting-code-fragments policy, and SE was viewed as too risky to allow without some restriction in place to make it read only. Before HTTPS, the IT department had worked out such a read-only restriction by blocking the SE login with firewall rules. But with HTTPS that kludge is no longer possible, so the site is blocked.
If you like working on these kinds of projects, the SRE team at Stack Overflow is hiring and we allow remote work full time! <a href="https://stackoverflow.com/jobs/143725/site-reliability-engineer-generalist-stack-overflow" rel="nofollow">https://stackoverflow.com/jobs/143725/site-reliability-engin...</a>
Just a reminder, HTTPS isn't enough. Be sure to turn the other security knobs with headers...<p><a href="https://securityheaders.io/?q=https%3A%2F%2Fstackoverflow.com&followRedirects=on" rel="nofollow">https://securityheaders.io/?q=https%3A%2F%2Fstackoverflow.co...</a>
Despite the "Google gives a boost to https" reasoning, which comes from Google itself, in practice I've read several first-hand accounts of how traffic (non XP) dropped significantly right after the switch.
It would be better if scripts like jquery were not encrypted. This forces users to use e.g. a google service instead of caching/hosting the scripts themselves or getting them from another CDN. I do not understand why so many people do not consider the privacy implications of every single webpage requiring calls to google services. There are ways to avoid this, but it gets a lot more complicated when that requires MITM methods for SSL. Please: use a non-tracking CDN, host it yourself, or at least leave it HTTP.
Regarding the section "Mistakes: APIs and .internal"<p>Why wouldn't they use split horizon DNS for this? Seems like the perfect use case
Funny how the main reason for lack of SSL is said to be the lack of support from 3rd party services... and the first service quoted is ads.<p><a href="https://nickcraver.com/blog/2013/04/23/stackoverflow-com-the-road-to-ssl/" rel="nofollow">https://nickcraver.com/blog/2013/04/23/stackoverflow-com-the...</a>
I work at a government facility. Stack Overflow and github are now both blocked (in addition to all social media and webmail). But Hacker News is apparently ok.