Be HTTPs by October or Chrome will show "not secure" flag

[goodroi]

Google Chrome 56 has been labeling http password & credit card inputs as "not secure". Starting in October, Chrome 62 will flag any http form & all http pages in incognito mode with a "not secure" warning. This was first announced in April and now Google is reminding http webmasters that October is quickly approaching.

Scared that https will hurt rankings? This is false. Https migration does not hurt rankings when properly implemented. Don't take my word for it, check it out for yourself. The initial wave of complaints was due mostly to a combination of Google reducing the value of redirected links & webmaster error (ie redirect loops, mixed content pages, & orphaned pages). Google has resolved the redirected link juice issues and webmasters now have many https guides to help them avoid mistakes. So start migrating before October is here.

[SEOLeeds]

Will this mean that sites that are linking to my website, that are just http, will be devalued, hence reducing my websites ranking?

[keyplyr]

SEOLeeds I've not seen any official announcement that HTTPS is to be factored as an additional ranking factor above the existing site security ranking indicators, but that could be something coming in the future given the motivation Google seems to have with this.

What is imminent is the
Mobile-First Index [webmasterworld.com] ranking update coming up in a couple months. That should shake things up :)

[SEOLeeds]

keyplyr, thanks for the response, it seems like the next natural progression, at the end of the day they want to make the whole of the internet "safer", not just the most popular sites.

[nomis5]

All pages, whether you publish Adsense or not, must be secure. All pages, whether they have a Log In or not, must be secure. All pages, whether they accept payment or not, must be secure... so all pages.

To be slightly pedantic, the October deadline applies only to pages with an input form and only when the user attempts to enter data into the form?

The "all pages" aspect of what you say has no stated date as to when it will be applied - from Google anyway.

Is my understanding correct?

[keyplyr]

Yes nomis5, you're correct that there is no published deadline yet for "regular" pages to be secure AFAIK.

But there was no deadline for this either until now... it was always just something we expected.

However IMO it's easier to switch all pages on a site rather than a few. If you do all the pages then you can just install the cert, fix the link protocols, install the 301 redirect and be done with it.

If you just change a few pages to be secure you can't use the site-wide 301 redirect. Then you'll end up with an odd mix of secure and unsecure pages that the browser has to negotiate... and you're basically just kicking the can down the road.

[Whatagreatdayitis]

I made the switch to https and my earnings are taking a hit. Friday evening is not the best time to gauge this, but traffic also seems to have been affected.

[keyplyr]

@Whatagreatdayitis - changing protocol to HTTPS has no affect on earnings since all Adsence units are HTTPS anyway. As far as traffic loss, only users on very old OS (example: Windows XP) may get filtered out since they don't support SNI.

Another site-wide tool to make your site safer for your visitors (and to get a higher security rating) is to use the HSTS* header field:

Strict-Transport-Security "max-age=63072000"

And if you have subdomains...

Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

For Apache sites using an htaccess, it can be installed by adding this line:

Header append Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

*The HTTP Strict-Transport-Security response header (often abbreviated as HSTS) is a security feature that prevents any communications from being sent over HTTP to the specified domain and will instead send all communications over HTTPS. It also prevents HTTPS click through prompts on browsers.

- - -

[lucy24]

max-age=63072000; includeSubDomains; preload

Given that those three are all the possible components of the STS header, what's the advantage of "Header append" rather than "Header set"?

[keyplyr]

No advantage, just different methods of including the field in the server response header.

Use "header set" if you like. Not much difference when adding a *new* field that's part of the STS. Although you're right, "append" is best when adding mixed elements.

set - The response header is set, replacing any previous header with this name. The value may be a format string.
append - The response header is appended to any existing header of the same name. When a new value is merged onto an existing header it is separated from the existing header with a comma. This is the HTTP standard way of giving a header multiple values.

source: [httpd.apache.org...]

[keyplyr]

Also, and this may be important, Chrome and Firefox are going to require that all certificates issued in October 2017 and onward will have to be logged in CT logs or they won't be trusted.

Certificate Transparency: [scotthelme.co.uk...]

Expect-CT is an HTTP header that allows sites to opt in to reporting and/or enforcement of Certificate Transparency requirements, which prevents the use of misissued certificates for that site from going unnoticed. When a site enables the Expect-CT header, they are requesting that Chrome check that any certificate for that site appears in public CT logs.

Source: The Expect-CT header: [chromestatus.com...]
More info: [httpwg.org...]

For Apache sites using an htaccess, the header field can be installed by adding this line:

Header set Expect-CT "enforce; max-age=3600;" 

This is using a short time-span and omitting the optional CT log location since that needs to be determined.

For a log destination you can use a local or remote (3rd party) location.:

Header set Expect-CT "enforce; max-age=3600; reportUri: http://example.com/report;" 

- - -

[keyplyr]

A working CT log you can use in your header is: https://crt.sh

If you've had active security certificates assigned to your domain, you are likely already logged there. Try it.

[Peter_S]

Apparently, with Let's Encrypt, there will be no need to add an extra header (I guess the information will be embed into the certificate itself) : [community.letsencrypt.org...]

[keyplyr]

@Peter_S - good find. Hopefully that's the way many CAs will do it.

[Peter_S]

@keyplyr - thank you

[jetteroheller]

Just making the transition. Only problem, I realized too late, that there is at Let's encrypt a limit of 20 subdomains per week.
So I went through all the sub domains of my main domain in alphabetic order.
At 'P', I run into the 20 subs limit.

I started to change at all my domains the links to my own domains from http to https
This is done by my self written CMS software.

But all the Links to https https://example.com will not work until next Friday, when I can get certificates for them.

So I thought on an emergency solution until next Friday:
to redirect all https to http

RewriteEngine On
RewriteBase /

RewriteCond %{HTTPS} on
RewriteRule ^(.*)$ http://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

But this does not work. When I go to https https://example.com
there is a big warning in Chrom instead of a redirect to http http://example.com

[edited by: not2easy at 6:43 am (utc) on Aug 27, 2017]
[edit reason] for readability use "example.com" [/edit]

[not2easy]

Try replacing that {HTTP_HOST} in your rule with {SERVER_NAME} and you may have success.

The {HTTP_HOST} means "whatever was requested". Read why here: [webmasterworld.com...]

[aristotle]

I just looked at Let's Encrypt website, and it seems to say that the certificates are only good for 90 days and then have to be re-newed. What a nuisance that would be, if it has to be done manually.

There's also a list of hosting companies that have added special support for Let's Encrypt, but most of the major companies, including both of mine, aren't on the list.

[lucy24]

if it has to be done manually

It doesn't. At least not with my host.

[jetteroheller]

Seems In have a very good host:
Domainlist -> Domain -> edit SSL
Create self signed cert, just enter some domain registration data in a form
Sign it by Let's encrypt
An other page:
Activate SSL - Yes - No
Force SSL - Yes - No
enable HSTS - No - Yes [.....] seconds

Seems it's difficult to make it more easy than this.

[aristotle]

Well I've looked at several options for ways to switch to https, but don't like any of them. So I'll keep my sites at http for now. Just because google wants me to do something doesn't mean that I will.

[Bluejeans]

It seems like an unreasonable hassle for a site where the only user input comes on a Contact page that uses an html form. It strikes me that I'd be better off rethinking how visitors get to contact me.

[lucy24]

It strikes me that I'd be better off rethinking how visitors get to contact me.

If your email host is anything like mine, it may be time to rethink it anyway. (Different thread.) But honestly, this cannot be said too often:

Switching to HTTPS is not difficult. It is not complicated. It is not time-consuming.

[aristotle]

Switching to HTTPS is not difficult. It is not complicated. It is not time-consuming.

Just because something might be easy to do doesn't mean that everyone should do it. Each person can make their own decision depending on their individual circumstances.

It strikes me that I'd be better off rethinking how visitors get to contact me.

I just put the email contact address on a gif image at the bottom of the page.

[Jon_King]

@NickMNS Thanks... Lets Encrypt worked perfectly.

[Peter_S]

Don't forget that if you switch to HTTPS, you'll also be able to enjoy HTTP/2 by the same occasion, we are in mid 2017, I don't know if there are still hosts not proposing it.

From my experience HTTP/2 is faster than HTTP 1.1 (now I don't know if it's the case for everybody). And speed is not to be neglected, it improves user experience, with pages loading faster, it also means ads showing sooner, without counting that it has/will have "some kind" of impact on ranking, etc...

Later this year, or next year, we'll have TSLv1.3 which will again improve speed, and "one day" QUIC too, which is also an HTTPS protocol.

[keyplyr]

Don't forget that if you switch to HTTPS, you'll also be able to enjoy HTTP/2 by the same occasion, we are in mid 2017, I don't know if there are still hosts not proposing it.

I just finished checking a bunch of hosts and asking about this.

Most all Dedi, VPS, Colo, Cloud and Managed server plans are offering Nginx & Apache OS version capable of handling HTTP/2 traffic.

Where the problem lies is with Shared Hosting, which is a huge chunk of the web. These are servers that are often older & running OSs that will not support HTTP/2... and because this hosting product is a lower level income maker for hosts, this is not their priority. They all say they have plans to upgrade to Apache 2.4+ and want to support HTTP/2 but few have a target date to accomplish this.

[Peter_S]

Most all Dedi, VPS, Colo

Since you have a shell access on these offers, you can install everything you want, so yes, you can have HTTP/2 easily.

The problem lies is with Shared Hosting, which is a huge chunk of the web. These are servers that are often older & running OSs that will not support HTTP/2.

HTTP/2 doesn't depend of the OS, it only depends of the web server software which has to implement this protocol. All major web servers support it since mid 2015, early 2016.

But there are chances that this kind of old server used for shared hosting will not support HTTPS well. They might not have enough CPU resources for the encryption process.

[keyplyr]

All the hosts I spoke with said basically the same thing, that Apache versions prior to 2.4 will not support HTTP/2

...make sure you have Apache >=2.4.17, Earlier version does not supports HTTP/2 protocol.

[tecadmin.net...]

That's just one resource I quickly found on my phone. There's a doc somewhere at Apache.org saying the same.

[Peter_S]

Yes, but it depends of the "web server" software , and not the OS.

[lucy24]

All the hosts I spoke with said basically the same thing, that Apache versions prior to 2.4 will not support HTTP/2

Do you have any sense of how far behind shared-hosts tend to lag? I remember that when I first started reading WebmasterWorld--in, I think, 2011--some people were still on Apache 1.3. If that's typical, I can expect an upgrade around, oh, 2023* or so.


* I just made that up; further searching suggests I may have exaggerated by a few years. But not many. (And why the heck is it impossible to find a simple version history?)