Move to HTTPS... is it worth the stress?

[lee_sufc]

I have a site which is 50% advice and 50% eCommerce. The eCommerce section of the website is on HTTPS pages for obvious reasons. However, for me to change over the rest of the site it is going to be a massive headache.

I've been reading more and more about how Google could penalise non-HTTPS sites. Is it worth me stressing over and moving everrything to HTTPS or will it be OK to stay as I am?

[keyplyr]

In other words the vast majority of HTTP sites will (in all probability) NOT be marked as 'non-secure'.

@iamlost - I think you're missing the second part...

Google is planning to eventually mark all HTTP connections as unsecure ones, with the security indicator for such websites to be marked with a RED TRIANGLE

That's every site! Imagine a user seeing a big RED TRIANGLE warning icon next to your site... do you think they will visit?

The icons are explained here: [support.google.com...]

[iamlost]

Ah, thank you. I did miss that.

[iamlost]

On rereading the linked page I am not sure that 'every' HTTP page will show the red triangle.
Granted, the information is not explicit either way.
However, given the option list of green lock, circled i, and red triangle I see the logic as:
* green lock: cert is accepted, connection encrypted (aka HTTPS properly served).
* circled i: no cert, no encrypted connection (aka bog standard HTTP connection)
* red triangle: improper cert, imperfect encryption (aka HTTPS improperly served)

I now go back to my original comments and withdraw my 'missed' comment above.

[blend27]

@RedBar

Do you realise just how many millions of perfectly good Android tablets there are that cannot be updated?

I do.

I have Samsung Galaxy 8, can't view my own sites in default browser via HTTPS. Locked by Samsung from my understanding. My sites are hosted on IIS, hosting company does not support SNI. There is a proxy service available. The service throws Chrome into Disarray - no green lock.

Another site would not get indexed by Bing for some reason under HTTPS.

[iamlost]

I went direct from HTTP/1.1 to HTTP/2 which has the benefit of fallback serving HTTP/1.1 to those clients who can not handle HTTPS. So I handle ye olde tablets et al quite well.

Whether such a test and fallback exists for standard HTTPS I do not know. Personally, if considering the SSL switch from now forward not going HTTP/2 seems an extra if not pointless step.

Note: yes, I know that we are talking about SSL HOWEVER if the client can not handle it and there is an alternative for that diminishing group it needs best be offered.

[robzilla]

On rereading the linked page I am not sure that 'every' HTTP page will show the red triangle.

Not for a few years, probably, but it's where we're all headed.

[keyplyr]

iamlost - SSL supports HTTP/2 if your browser & server does.

Not for a few years, probably, but it's where we're all headed.

robzilla - They will start January 2017 (in a little over a month from now) with warning if the site has contact forms, search boxes or accepts credit cards. Date for the full implementation of the warnings is unclear, but I tend to think in months, not years. Google is pushing hard on this.

[JAB Creations]

I'm surprised no one bothered to mention mixed content. Serving some of the content securely (e.g. the text but not images, or vice-versa) will trigger a mixed-content warning (I think offhand Firefox and IE though this is not an issue I've pursued enough). What I can tell you is that your visitors will get an annoying and possibly "scary" warning that some content isn't secure (better (perception wise for them) to have no "scary" warning).

No matter what your scenario, you should be able to run a full copy of your site (unless database driven where you'd have a local copy of the database that may be behind by days/weeks/months) that you can test changes to your code first. Keep in mind that lower levels of SSL won't count and will trigger JavaScript console error messages (and eventually even the "scary" JavaScript alert modal messages).

John

[keyplyr]

I'm surprised no one bothered to mention mixed content

Yes, I use Firefox and see that yellow warning a lot at sites (Webmasterworld included)

[robzilla]

They will start January 2017 (in a little over a month from now) with warning if the site has contact forms, search boxes or accepts credit cards. Date for the full implementation of the warnings is unclear, but I tend to think in months, not years. Google is pushing hard on this.

I don't believe contact forms and search boxes are part of that first step, actually. Only passwords and credit cards for now. Search and contact forms may be a logical next step, but I feel that marking all HTTP webpages (with or without forms) as insecure in 2017 is just too early and borders on scaremongering. They'll get there, and they'll push it, no doubt, but I don't think it will be quite so soon. We'll see!

[keyplyr]

robzilla - I'm pretty sure I read somewhere that all form data was part of the first wave, but I guess we'll see in a few weeks.

[robzilla]

There's probably a lot of speculation going around, but here's what the source says:

Starting January 2017, Chrome 56 will label HTTP pages with password or credit card form fields as "not secure," given their particularly sensitive nature.

In following releases, we will continue to extend HTTP warnings, for example, by labelling HTTP pages as “not secure” in Incognito mode, where users may have higher expectations of privacy. Eventually, we plan to label all HTTP pages as non-secure, and change the HTTP security indicator to the red triangle that we use for broken HTTPS.

Moving towards a more secure web [security.googleblog.com]

They'd like to get other browser vendors in on it, too, which, historically viewed, could take a while...

Clearly, HTTPS is the way forward, but even without the above, HTTPS is still very much worth the "hassle".

[Wilburforce]

Google also makes the point - certainly worth considering, whatever your site's content - that "when you load a website over HTTP, someone else on the network can look at or modify the site before it gets to you" (my emphasis added).

The page linked from that comment ([webpolicy.org ]) makes a pretty good case for switching.

[keyplyr]

Regarding HTTPS and HTTP/2

Although the HTTP/2 standard does not require usage of encryption, most client implementations (Firefox, Chrome, Safari, Opera, IE, Edge) have stated that they will only support HTTP/2 over TLS, which makes encryption de facto mandatory.

HTTP/2 has accelerated speed making your site load much faster, but only if your site is HTTPS it seems.

[toidi]

How long will this last when consumers go to websites with the green circle, which tells them they are safe, but the website is hacked and they get a virus? Seems to me (vague memory) g tried something similar a while back which they soon abandoned.

[No5needinput]

Don't forget the possible reluctance (myself included) of people with https sites to link to NON https sites due to triggering warnings.

[Wilburforce]

Don't forget the possible reluctance (myself included) of people with https sites to link to NON https sites due to triggering warnings.

What browser are you seeing that in? Posting an image that is hosted on a non-SSL site in one of your own pages (i.e sponging) would cause it, but simply linking to a page on a non-SSL site doesn't trigger a warning in any browser I have checked.

[IanM]

This whole HTTPS-on-all-sites nonsense is one massive Straw Man. If you are managing a banking or e-commerce site, then yes you should be using HTTPS. Otherwise, it is not only pointless but dangerous, because it creates a completely false sense of security in both the webmaster's and the end user's mind.

HTTPS does not prevent SQL code injection exploits, which are by far and away the main reason why webhosts get hacked and malware planted on them. It does not prevent passwords sent in plaintext from being harvested by malware running on the webserver, or for that matter being stolen by a dishonest staffmember. It does not prevent javascript malware or malicious downloads from being launched on the site visitor's computer.

The only thing it does do, is to protect data in transit from being read or modifiied. In other words,a MITM attack. It's hard to get any definite stats on MITM attacks, but they seem statistically to be a very minor aspect of IT security.

When you consider the man-hours which have been spent globally on implementing HTTPS on sites that don't need it, you have to ask, what other more effective security measures could have been implemented, had all that working time not been wasted on tilting-at a straw man?

[lucy24]

Chrome 56 will label HTTP pages with password or credit card form fields

How will it know what a form field is for?

[keyplyr]

@IanM - I don't recall Google making any claim SSL stops any of the various hacking methods you mentioned. It is but one layer of security the web is moving to as standard.

[IanM]

@keyplyr- I disagree. If Google indicates that a page is unsafe if it has a password field and HTTP, but that the padlock closes and all is apparently well if HTTPS is used, then that implies that HTTPS has made the password field safe to use.

If in fact the password is sent as plaintext and stored on a database server as plaintext, then that is dangerously incorrect advice. It is not safe to use that page.

I could draw a parallel with an investigation into nitrogen tyre inflation. The garages selling this expensive gimmick were claiming that it gave lower leakage so your tyres didn't need checking so often. Which was true, except the difference was tiny. The end result, as you can imagine, was numerous cars running on near-flat tyres because the owners thought there was no need to check them.

[keyplyr]

unsafe and unsecure are two different things in internet terms

[edited by: keyplyr at 11:04 pm (utc) on Nov 29, 2016]

[robzilla]

How will it know what a form field is for?

Passwords are easy, assuming type=password is used, or maybe even name=password. As for credit cards, I believe Chrome blocks autofill for numbers matching a credit card regex on insecure connections, but marking a page insecure beforehand is a different matter (i.e. I dunno)

If in fact the password is sent as plaintext and stored on a database server as plaintext, then that is dangerously incorrect advice.

I see how it might give some people a false sense of security in some cases, but upon clicking the padlock the browser clearly states it is the connection that is secure. And what's your alternative? No HTTPS? Talk about throwing the baby out with the bathwater. One thing at a time.

[keyplyr]

In other words the vast majority of HTTP sites will (in all probability) NOT be marked as 'non-secure'.

That's a fair assumption, at least at first. But later (who knows how long) all HTTP pages will be marked as non-secure if not using SSL.

But with Certs costing so little, or even free, and hosting companies making it so easy to switch, why not just do it and get it over with instead of spending so much effort finding excuses to why you shouldn't?

As I said earlier, it took less than an hour for me to switch a 300 page static site. Then imagine the fun you'll have telling others how easy it was :)

[graeme_p]

https is also a barrier to mass surveillance. Google are worried that privacy issues will deter people from using the web for some things.

[Broadway]

I have an informational website that collects no user information at all, the kind of site where switching to https has the least need.

I switched to https and feel great about it. I certainly noticed no ranking or traffic loss (and really felt I noticed the opposite when it comes to traffic).

This site is only about 400 pages or so and I unfortunately had hard linked some anchors with http.

To hunt those down, I exported tables from my database where I knew offending links might be. I then searched that file using a standard text editor to identify on which pages they were on. I then went to my CMS to correct them.

[System]

The following message was cut out to new thread by robert_charlton. New thread at: google/4827476.htm [webmasterworld.com]
9:24 pm on Nov 30, 2016 (PDT -8)

[Dimitri]

Considering the increase of hacking worldwide, I think we should not minimize the risks of "man in the middle" hacking , and the possibility that a router/proxy/nsa black boxes/etc... by which the traffic is transiting can be compromised and injects malicious code into a page.

The server push is also a nice feature of HTTP/2.

[jambam]

Surely if some one is "tampering with your connection" then you have bigger things to worry about than if a site is https or not.

[Wilburforce]

Surely if some one is "tampering with your connection"

The point of SSL/TLS is that nobody is able to tamper with your connection: https means the connection is secure; http means it isn't.