I'm novice in security, but after reading the post Network-wide HTTPS: It's time I'm confused. As in the answer of Better HTTPS support for Stack Exchange sites, having an SSL certificate is not expensive anymore, so I can't imagine why we hadn't had it for a long time. I mean, I had thought that there was always a green padlock whenever I visited Stack Exchange.

I would like to have an answer that contains not so much technical terms, unlike the Network-wide HTTPS: It's time post.

  • 4
    "I'm novice here" Huh?? "I know that this is googlable ..." Research effort is essential for any SE site. – πάντα ῥεῖ Mar 26 '17 at 13:22
  • Is this better? – Ooker Mar 26 '17 at 13:33

having an SSL certificate is not expensive anymore, so I can't imagine why we hadn't had it for a long time

Certificates are cheap, but implementing HTTPS on a site that always has run under HTTP is not. There were a lot of issues the team had to deal with: links, images, meta sites, etc.

It is very well possible you've visited Stack Exchange main sites over HTTPS for a while. They have had a certificate for years, but support was not 100% well. Meta sites didn't work over HTTPS (they had an invalid certificate).

They did use HTTPS for critical parts of the site, like login, etc. Other parts were HTTP with no active support for HTTPS. Until now.

  • Thanks. I was under the impression that implementing SSL is cheap and easy. – Ooker Mar 26 '17 at 13:50
  • Not if you have a site with http:// in a dozen places in the code. – Patrick Hofman Mar 26 '17 at 14:01
  • The meta sites worked with https, so I used them years long. Although the invalid cert resulted, that you weren't protected from mitm attacks (but, against the usual, passive eavesdropping, yes). I used a patched https everywhere for that. – peterh - Reinstate Monica Mar 26 '17 at 14:21
  • @Pat but I guess you only need to search and replace them? Is that for large code even search and replace requires higher caution? – Ooker Mar 26 '17 at 19:30
  • 1
    Find and replace is often the fastest way to screw up your code without knowing it. – Patrick Hofman Mar 26 '17 at 19:48
  • 1
    @Ooker when Patrick says in about a dozen places in the code, he means closer to a few thousand places. And you've got to go through all of those without breaking anything, and keeping the site online while you're doing it. – angussidney Mar 27 '17 at 5:51
  • 1
    Indeed. And what about code that assumes an url starts with 7 characters that represents the protocol. Instead of 8 with HTTPS. – Patrick Hofman Mar 27 '17 at 5:54
  • ugh, there's even a code that requires the number of characters representing the protocol are exactly 7? Why don't they just assign the link to a variable/module, and fixing that variable/module instead? – Ooker Mar 27 '17 at 9:23
  • 1
    @Ooker - It's a nice thought. But your suggestion has the same problem as simply increasing the count by 1. It still has to work, on a live website, and without breaking it. – Ramhound Mar 27 '17 at 17:24
  • @Ramhound the more I know about coding, the more I naive about it... – Ooker Mar 28 '17 at 8:58
  • @Ooker I am not saying they didn't switch to a variable just saying they would have had to still test it because they hadn't originally used one. – Ramhound Mar 28 '17 at 11:41
  • @Ramhound I mean, even when I know that changing anything should go along with careful since the site is large, I just didn't expect that tiny change can be so time-consuming. – Ooker Mar 28 '17 at 16:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .