HTTPS as a ranking signal(googleonlinesecurity.blogspot.com)
googleonlinesecurity.blogspot.com
HTTPS as a ranking signal
http://googleonlinesecurity.blogspot.com/2014/08/https-as-ranking-signal_6.html
43 comments
So Google's position is that SSL is such a high priority for content sites that they will officially incite a mad scramble for every content site on the planet from big media companies to hobby blogs to secure their page behind https to keep their ranking, but yet doesn't see anything wrong with the fact that every Blogger blog and even the Google Online Security Blog that it is announced on, is insecure. Nice.
"A journey of a thousand miles begins with a single step"
In my country, the cost of a SSL certificate is around 60% of my hosting costs, per year. I run a low-traffic blog with comments disabled, so users do not "interact" with the site in any way - except consume the content. I don't see any benefit from this.
I see the benefits but I have to agree. This is a very real barrier to entry, and not just financially. Making SSL a global standard is just one more thing new web developers have to appreciate.
StartSSL is pretty harmful as evidenced by the events after Heartbleed. The certificates are free but they charge you to revoke them, and after we found out about Heartbleed and realized a lot of those free certs were compromised a lot of people refused to pay up for their free keys and continue using the compromised ones. What's more is that StartSSL refused to do the right thing and revoke them, leading a lot of folks to even go as far as petitioning to remove StartSSL from Firefox's Certificate Authorities because any given site using their free certs could be compromised. [0]
[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744027
[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744027
Do any current browsers even correctly support CRLs?
Erm... Heartbleed has absolutely nothing to do with what version of OpenSSL you use to generate the cert.
No, but if your SSL certificate has been exposed by Heartbleed, it would be sensible to revoke that certificate to prevent potential spoofing attacks, wouldn't it?
StartSSL charge you for revoking that exposed certificate, so your choices are you pay for the revocation, or wait until the certificate expires.
StartSSL charge you for revoking that exposed certificate, so your choices are you pay for the revocation, or wait until the certificate expires.
In there defence this their treatment of revocation requests is made quite plain in their policies, and any heartbleed exposure was not their fault (their signing certs were not affected IIRC).
Now if there had been a problem with their signing certificates then I would have expected them to revoke anything affected for free and offer replacements similarly at no cost.
OK, they could have done that anyway (or perhaps offered a discount on the revoke charge) as an good will gesture, but they didn't, so what.
Now if there had been a problem with their signing certificates then I would have expected them to revoke anything affected for free and offer replacements similarly at no cost.
OK, they could have done that anyway (or perhaps offered a discount on the revoke charge) as an good will gesture, but they didn't, so what.
Leaving aside the question of whether their response was reasonable (I see the arguments either way), it turned out that using their service to secure your website was not free.
> it turned out that using their service to secure your website was not free
All they claim is to provide free certificates for non-commercial use, and that they do provide. If people read something else into that it isn't because they were deliberately led to.
Though many people picking up a cert without really knowing the infrastructure won't know about revocation infrastructure and such so might have mislead themselves by having not read the Ts&Csm.
All they claim is to provide free certificates for non-commercial use, and that they do provide. If people read something else into that it isn't because they were deliberately led to.
Though many people picking up a cert without really knowing the infrastructure won't know about revocation infrastructure and such so might have mislead themselves by having not read the Ts&Csm.
actually, what i think is.. they're as near 'free' as it gets, probably. at least there's no up front cost using them. then its a lottery as to when u need to pay them to revoke... it could still end up cheaper than paying yearly fees for other certs, i imagine.. total cost of ownership or something..
You're right, so I fixed my post. What I meant was that my particular cert wasn't compromised. Either way, the StartSSL/Heartbleed fiasco is a real thing and I've added a link to the original discussion I was citing.
Cheers HN for downvoting a factually correct statement because the parent post got edited after I pointed out an error...
Get a free cert instead?
Free certificates tend to result in ugly warning messages in browsers …
Cheap certificates are available, however, they are still not for free. And hosting more than one domain with SSL is a problem too with most hosting providers if you do not want to book additional hostings.
Cheap certificates are available, however, they are still not for free. And hosting more than one domain with SSL is a problem too with most hosting providers if you do not want to book additional hostings.
> Free certificates tend to result in ugly warning messages in browsers
StartSSL is free, and as long as you correctly bundle the intermediate cert (something you have to do with many, many other CA's anyway) your SSL will look no different than a $100+/year one from an A-list provider.
StartSSL is free, and as long as you correctly bundle the intermediate cert (something you have to do with many, many other CA's anyway) your SSL will look no different than a $100+/year one from an A-list provider.
Another advantage to we masters with money … why?
SSL does not come cheap. Certificates have become cheap but you need your own IP, i.e., shared hosting is a problem and hosting becomes more expensive. Certificate sellers, hosters etc. on the other hand are certainly happy about these new business opportunities – although we all know that SSL is inherently broken.
OK, probably still better than nothing! :)
SSL does not come cheap. Certificates have become cheap but you need your own IP, i.e., shared hosting is a problem and hosting becomes more expensive. Certificate sellers, hosters etc. on the other hand are certainly happy about these new business opportunities – although we all know that SSL is inherently broken.
OK, probably still better than nothing! :)
> but you need your own IP
Not anymore, unless you need to support antiquities like IE7 on Windows XP or some ancient Java-based software. SNI works just fine in other cases.
Not anymore, unless you need to support antiquities like IE7 on Windows XP or some ancient Java-based software. SNI works just fine in other cases.
OK, good to know – although there are apparently still some restrictions according to comments by other HN users.
SSL is still more expensive, though. For most small content websites (< 500-1000 visitors a day), a shared hosting is sufficient with costs of maybe around 100 USD/year. For SSL, you usually need a more expensive hosting, you have to buy a certificate (OK, available for less than 10 USD if you don't care about it's quality but need mainly browser support without an ugly warning window) and most hosters allow SSL only for one domain in a hosting.
Example:
Shared hosting with 4 WordPress blogs, SSL is active but only to access the control panel since the hoster allows SSL only for one domain. Costs incl. a cheap SSL certificate: 110 USD/year.
All 4 WordPress blogs with SSL, i.e., 4 shared hostings plus 4 cheap SSL certificates: 440 USD/year.
(And caching with a Wordpress plugin is probably no longer possible …)
SSL is still more expensive, though. For most small content websites (< 500-1000 visitors a day), a shared hosting is sufficient with costs of maybe around 100 USD/year. For SSL, you usually need a more expensive hosting, you have to buy a certificate (OK, available for less than 10 USD if you don't care about it's quality but need mainly browser support without an ugly warning window) and most hosters allow SSL only for one domain in a hosting.
Example:
Shared hosting with 4 WordPress blogs, SSL is active but only to access the control panel since the hoster allows SSL only for one domain. Costs incl. a cheap SSL certificate: 110 USD/year.
All 4 WordPress blogs with SSL, i.e., 4 shared hostings plus 4 cheap SSL certificates: 440 USD/year.
(And caching with a Wordpress plugin is probably no longer possible …)
StartSSL is 0 USD/year. There should be more providers like them, and if the barriers to entry ($$$$) weren't so insurmountable, I'd happily start one myself. But they do a good job, and I've used several free certs from them with no issues.
https://www.startssl.com/?app=1
You also don't need "expensive" hosting, it just needs to support SSL which is free from a technical perspective. You no longer need a dedicated IP either.
https://www.startssl.com/?app=1
You also don't need "expensive" hosting, it just needs to support SSL which is free from a technical perspective. You no longer need a dedicated IP either.
> available for less than 10 USD if you don't care about it's quality
A cert with a larger key is better than one with a smaller key, but other than that, what's the "quality" of a SSL certificate?
A cert with a larger key is better than one with a smaller key, but other than that, what's the "quality" of a SSL certificate?
> a shared hosting is sufficient with costs of maybe around 100 USD/year
Galopping gargoyles, where do you host that shared costs you $100? A small VPS costs half.
Galopping gargoyles, where do you host that shared costs you $100? A small VPS costs half.
PositiveSSL Multi-Domain certs allow enterprises and web hosts to secure multiple websites by including up to 100 domains within a single certificate.
$29.88/year.
$29.88/year.
Link? The numbers I see for this service are:
"Base certificate costs $165.00 for three domains"
"After the third domain, each additional domain costs just $45.00"
http://www.positivessl.com/multi_domain_ssl_certificate.php
"Base certificate costs $165.00 for three domains"
"After the third domain, each additional domain costs just $45.00"
http://www.positivessl.com/multi_domain_ssl_certificate.php
That's only for 3 domains, not 100. 3 domains at $30/year is $10/year/domain which is no different than buying individual certs.
The multidomain cert supports up to 100 domains, but the cost is $29.88/year for the first 3 included, plus an additional $12.88/year for each additional domain.
Under this price structure, you could have 100 domains covered with one certificate, but it would cost you $1,279.24 per year for that single certificate.
The multidomain cert supports up to 100 domains, but the cost is $29.88/year for the first 3 included, plus an additional $12.88/year for each additional domain.
Under this price structure, you could have 100 domains covered with one certificate, but it would cost you $1,279.24 per year for that single certificate.
That's only for 3 domains, not 100.
Nobody said otherwise.
3 domains at $30/year is $10/year/domain which is no different than buying individual certs.
The problem was that shared hosting plans didn't support multiple certs, forcing people with a few sites to purchase a plan for each. The multidomain cert solves this problem.
Nobody said otherwise.
3 domains at $30/year is $10/year/domain which is no different than buying individual certs.
The problem was that shared hosting plans didn't support multiple certs, forcing people with a few sites to purchase a plan for each. The multidomain cert solves this problem.
Thanks!
The shortage of IPv4 addresses and the horribly slow adoption of IPv6 is a big issue.
SNI works fine, but when it doesn't it fails horribly. Apache defaults to the first vhost on an IP which can result in non-SNI clients being redirected to the wrong site.
As for XP/IE7 usage, I have a client in an aerospace related industry with most of their customers still on XP/IE7.
SNI works fine, but when it doesn't it fails horribly. Apache defaults to the first vhost on an IP which can result in non-SNI clients being redirected to the wrong site.
As for XP/IE7 usage, I have a client in an aerospace related industry with most of their customers still on XP/IE7.
Check your own stats before you assume you don't still have Win XP/IE users. I have quite a few.
Here's a list of browsers that support it...
http://en.wikipedia.org/wiki/Server_Name_Indication#Browsers...
http://en.wikipedia.org/wiki/Server_Name_Indication#Browsers...
Except with the most popular version of Python
Works fine if you use requests, or any other HTTP library which hasn't been left to rot like the one in the 2.x stdlib.
Out of the box, requests on Python2.7 doesn't support SNI.
It is documented, and all you have to do is install additional packages to enable it, but still, that's not automatic.
It is documented, and all you have to do is install additional packages to enable it, but still, that's not automatic.
It will be available in the future maintenance release http://legacy.python.org/dev/peps/pep-0466/
I am more than happy to migrate my site to https and I took a two days to watch your youtube video to ensure i do not miss anything
But I got one very valid concern. Most websites running some kind of affiliate links and banners. Most of the affiliate links and banners is not on the https platform. This will cause mixed content error message by the browser. First, is using protocol relative urls solve this mixed content error issue? Second, can the non-https affiliate links and banners work correctly(tracking etc) on https website?
I am sure this is the one big hurdle need to be addressed or else more than 50% of the websites in existence will have difficulty to migrate.
But I got one very valid concern. Most websites running some kind of affiliate links and banners. Most of the affiliate links and banners is not on the https platform. This will cause mixed content error message by the browser. First, is using protocol relative urls solve this mixed content error issue? Second, can the non-https affiliate links and banners work correctly(tracking etc) on https website?
I am sure this is the one big hurdle need to be addressed or else more than 50% of the websites in existence will have difficulty to migrate.
Hey Pierre,
Quick question. Is the type of certificate also a signal? i.e. self-signed vs plain vs EV?
Quick question. Is the type of certificate also a signal? i.e. self-signed vs plain vs EV?
Self-signed is worse than not having one. Don't do that.
Please stop spreading this lie. It's been debunked many, many times. Just because something doesn't provide 100% security doesn't mean you should give up and use nothing.
Once again, self-signed SSL raises the cost of an attack from "basically free" passive monitoring to a much more expensive[1] MitM attack. It's a travesty that apache doesn't simply auto-create a self-signed certificate if it doesn't have one so plain HTTP can be retired forever.
Note: this is about transport security, and the UI presented should not suggest any kind of authentication has been achieved. In firefox, this means not showing the "locked padlock" and other changes usually associated with SSL.
So please, stop undermining the security of the web. We could have been all-HTTPS a long time ago if this nonsense wasn't brought up each time.
[1] and hard to use against everybody simultaneously
Once again, self-signed SSL raises the cost of an attack from "basically free" passive monitoring to a much more expensive[1] MitM attack. It's a travesty that apache doesn't simply auto-create a self-signed certificate if it doesn't have one so plain HTTP can be retired forever.
Note: this is about transport security, and the UI presented should not suggest any kind of authentication has been achieved. In firefox, this means not showing the "locked padlock" and other changes usually associated with SSL.
So please, stop undermining the security of the web. We could have been all-HTTPS a long time ago if this nonsense wasn't brought up each time.
[1] and hard to use against everybody simultaneously
Why? The crypto is just as strong with a self-signed cert as a "name brand" cert. The only downside is teaching users to ignore SSL errors, which is bad.
I assume self-signed will be treat as having no certificate at all, if the reason for the difference in ranking is that a certificate implies the user will more definitely read what the server sends, as a self-signed certificate protected site is just as easy to MitM as one without a certificate at all.
I mean, I understand their argument against it, but I think this is one of those cases where the pros definitely out-weigh the cons, this is great.
Usefulness of SSL aside, is anyone else terrified that Google can essentially dictate what it wants developers to do, with low search rankings as the penalty for not following them? In my opinion, this sets a scary precedent.
Yes. Fortunately, they're doing it in the name of improving the web.
So far.
So far.
Google has a strong case to have HTTPS implemented:
It prevents ISPs etc. from being able to profile your traffic, but not Google's, since you're probably visiting a site with Adsense or Analytics running on it anyway.
Through HTTPS, Google is the only one with a profile of your traffic, and your ISP is no longer a competitor to them.
It prevents ISPs etc. from being able to profile your traffic, but not Google's, since you're probably visiting a site with Adsense or Analytics running on it anyway.
Through HTTPS, Google is the only one with a profile of your traffic, and your ISP is no longer a competitor to them.
Hm. I think this is the real answer.
It probably bugs me the way it does, because this "signal" has nothing to do with the contents or the usability of the web site (unlike speed, validity of HTML or, well, content itself), but is purely a "we just think you should do X" situation.
I would definitely prefer to use a site that supports HTTPS over HTTP. For personal safety reasons in addition to privacy and general welfare of the web.
If you're searching for something and roughly the same content is available at safedomain.com vs. notoriouslysketchy.ru, I'd think you'd prefer to be shown the former above the latter. I don't see how this is much different.
If you're searching for something and roughly the same content is available at safedomain.com vs. notoriouslysketchy.ru, I'd think you'd prefer to be shown the former above the latter. I don't see how this is much different.
HTTPS is relevant to the content because it will ensure that Google's search results direct users to the same content providers seen by Google's web crawlers.
It has to do with preventing mass surveillance by default.
Do you have to throw out all your social rankings?
I've been wanting to switch to HTTPS but have been avoiding it due to significant accumulation of Facebook likes and some +1's. Last I checked, you had to do some big hacks to maintain your Facebook like count. Has anybody found a good way to handle this or do you just have to start over?
I've been wanting to switch to HTTPS but have been avoiding it due to significant accumulation of Facebook likes and some +1's. Last I checked, you had to do some big hacks to maintain your Facebook like count. Has anybody found a good way to handle this or do you just have to start over?
I'm going to come out and say it. HTTPs is borked, in a functional way. On a social/technical level, it has become a false sense of security. The PRISM revelations let us know that the three letters and any corporate wannabe was doing MITM not just on http but on HTTPS whenever possible. I would say the ISP's and the CA's should all be considered compromised.
We need something new and better, not to push HTTPs on everything as an imagined stop gap...
That being said though, I do understand that if this was pushed to wider adoption, it would create a higher cost to perform such attacks, for ISP's and three letters?
We need something new and better, not to push HTTPs on everything as an imagined stop gap...
That being said though, I do understand that if this was pushed to wider adoption, it would create a higher cost to perform such attacks, for ISP's and three letters?
I don't buy the 'this is for your own safety' nonsense. Having said that, when are Google going to improve their search algorithm? These days there are so many shitty content farm results that clog up the first page itself. How about improving that first?
Unfortunately, Google is pretty much a monopoly when it comes to online advertising and search that few companies will have a choice in this matter. Google unilaterally forcing them to buy stuff doesn't sit well with me.
Unfortunately, Google is pretty much a monopoly when it comes to online advertising and search that few companies will have a choice in this matter. Google unilaterally forcing them to buy stuff doesn't sit well with me.
After you buy an SSL certificate, Heroku charges $20/month to use it. You can circumvent this with Cloudflare, but they also charge $20/month for SSL. Is there any easy way to use SSL on Heroku for $0-5 / month?
(See http://www.quora.com/Is-there-any-way-to-use-HTTPS-on-Heroku... for one possibility.)
(See http://www.quora.com/Is-there-any-way-to-use-HTTPS-on-Heroku... for one possibility.)
I guess this article from a month ago was right when they observed a boost of their ranking: https://blog.httpwatch.com/2014/07/07/google-has-given-https...
I hope that at least one site runs without https so that when I am using airport/airline/FlyingJ/Starbucks/etc wifi, I can access it and be presented with the button I need to press to access the network.
I currently use http://xkcd.com for this purpose.
I currently use http://xkcd.com for this purpose.
Funny; google.com works fine for me for this, even though it's definitely https.
Excellent move by Google that should push people to use HTTPS more.
Hopefully this will take into account the supported TLS versions and ciphersuites as well. It's sad to see sites that only supports TLS 1.0 and prefers a CBC ciphersuite.
Hopefully this will take into account the supported TLS versions and ciphersuites as well. It's sad to see sites that only supports TLS 1.0 and prefers a CBC ciphersuite.
We recently changed our existing clients site to 100% SSL when we launched their new site.
If only webmasters had an option to change http:// to https://, the entire move would have been slightly easier as "fetch as googlebot" returns "redirect" since we direct http:// to https://.
Apart from that, we've had no ranking loss for their keywords.
If only webmasters had an option to change http:// to https://, the entire move would have been slightly easier as "fetch as googlebot" returns "redirect" since we direct http:// to https://.
Apart from that, we've had no ranking loss for their keywords.
Take a look at HSTS. It effectively tells clients to try HTTPS first when a user types in your domain.
http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
... after the first visit...
Unless your site is on the HSTS list (https://src.chromium.org/viewvc/chrome/trunk/src/net/http/tr... for Chrome, Firefox use the same list by verifying by connecting via HTTPS and checking for a long HSTS time.)
Right, unless your site is on the HSTS list AND all your users are using Chrome or firefox....
Which was basically my original point, which is that if you want your site to be generally accessible by just typing in the domain name, you still can't just turn off port 80...
Which I guess is why google.com itself is still reachable on port 80.
Which was basically my original point, which is that if you want your site to be generally accessible by just typing in the domain name, you still can't just turn off port 80...
Which I guess is why google.com itself is still reachable on port 80.
I don't get it. I have a website that is purely content and available to everyone. It has no user accounts, no sign-ups, no nothing but static pages. Why should I use HTTPS for that? To prevent man-in-the-middle attacks?
Using HTTPS will let you know if the website you're visited is being messed with by a company, country, or regionally controlled firewall or content filter. If someone operating one of these filters took issue with your site, they could block certain content and users wouldn't necessarily know that it's happening.
Not only attacks, but anyone on the same network on hops in between can see what sites and pages are being visited, the less data you leak, the less likely someone can build a case against you.
Is there a chance someone might modify the way your site appears for censorship or other gain?
The irony is that this will help Symantec, Comodo and Godaddy who are well known for stuffing their users sites with anchor-text (followed) links back to their own SSL pages.
A good move. Well done for pushing the world towards a safer internet.
Quick question though. There was no mention of the type of certs used. Will plain certs be worth less than EV certs?
Hopefully Matt or any other Google search representative here can comment.
Quick question though. There was no mention of the type of certs used. Will plain certs be worth less than EV certs?
Hopefully Matt or any other Google search representative here can comment.
Newb question: Is plain cert locally generated certificates (free), while EV certs are those you pay for from a "trusted authority"?
No. A plain cert is one you normally buy, an EV cert stands for Extended Validation which only specific CAs can give out and there's extra guidelines for that, plus they're generally much more expensive. Browsers generally show the identity of the certificate in the URL bar when they are EV, which they otherwise do not.
This link should explain the difference: http://security.stackexchange.com/q/15865/10211
Makes sense. The reason seo spam is effective is because it's so cheap to get a new site (or ten thousand new sites) up and running. If you make that cost $50 per domain for the ssl cert, that will help ensure all those sites sift nicely down to the bottom of the rankings.
Bonus points if they allow a single bad site to tarnish the reputation of all sites under a milti domain cert.
We could have had this from the start if domain names weren't essentially free via domain tasting. But hey, better late than never.
Bonus points if they allow a single bad site to tarnish the reputation of all sites under a milti domain cert.
We could have had this from the start if domain names weren't essentially free via domain tasting. But hey, better late than never.
I do agree, however remember that you can get SSL certs from $9 (e.g. from NameCheap). You might be able to pay lower if you shop around too.
Also even if it was used as a fairly strong ranking signal, if Google still approach their rankings like they do now, spammers might still have sufficient ranking 'weight' to overcome a lack of SSL certificate.
Also even if it was used as a fairly strong ranking signal, if Google still approach their rankings like they do now, spammers might still have sufficient ranking 'weight' to overcome a lack of SSL certificate.
Don't forget you have to manage your certs. It's an extra burden.
Let's say I am a freelancer, I make website for small restaurant. Until now I could make a website with frontpage, menu and gallery put it on a server and be done with it and collect a monthly fee.
Now, you have to manage the cert, that is say every year re-issue a new cert and invalidate the old. It adds costs. Without much if any benefits for some class of websites.
Let's say I am a freelancer, I make website for small restaurant. Until now I could make a website with frontpage, menu and gallery put it on a server and be done with it and collect a monthly fee.
Now, you have to manage the cert, that is say every year re-issue a new cert and invalidate the old. It adds costs. Without much if any benefits for some class of websites.
I'm a freelance web developer for dozens of restaurants. They pay for the site, then a yearly hosting fee every year after launch. They get a basic CMS so they can update their hours/menus/etc.
I host all their sites on a few VPS servers. Some of my contracts require support for IE 7 or IE 8 on Windows XP, and those browsers don't support SNI. So in addition to what you've mentioned - maintaining certificates and losing more of what little money I make on hosting (I basically charge a small % of the VPS cost plus a few hours' worth of work), I now will need to figure out another solution. It seems like a waste to spin up a new VPS for each site that requires XP support.
Clients look at the <10% of visitors coming from Safari and IE7+8 on XP and say "those are potential customers." It's difficult to argue with that.
For now though, I'm going to do nothing new. All indications are that HTTPS is going to be maybe 1% of the ranking, and I know my market well enough that the sites rank highly for local searches - which is the important part. They're responsive and they've all got social media presences, so until SSL is more important for PageRank, I'll wait it out.
I host all their sites on a few VPS servers. Some of my contracts require support for IE 7 or IE 8 on Windows XP, and those browsers don't support SNI. So in addition to what you've mentioned - maintaining certificates and losing more of what little money I make on hosting (I basically charge a small % of the VPS cost plus a few hours' worth of work), I now will need to figure out another solution. It seems like a waste to spin up a new VPS for each site that requires XP support.
Clients look at the <10% of visitors coming from Safari and IE7+8 on XP and say "those are potential customers." It's difficult to argue with that.
For now though, I'm going to do nothing new. All indications are that HTTPS is going to be maybe 1% of the ranking, and I know my market well enough that the sites rank highly for local searches - which is the important part. They're responsive and they've all got social media presences, so until SSL is more important for PageRank, I'll wait it out.
A few people I've talked with told me the same. For now they won't care. But as told me a friend, if too much client start to ask for it will be troubles for him.
But that is to be kept in mind : "But over time, we may decide to strengthen it, because we’d like to encourage all website owners to switch from HTTP to HTTPS to keep everyone safe on the web."
But that is to be kept in mind : "But over time, we may decide to strengthen it, because we’d like to encourage all website owners to switch from HTTP to HTTPS to keep everyone safe on the web."
[R]emember that you can get SSL certs from $9 (e.g. from NameCheap).
NameCheap provrides a wide range of certs. I'm sure this is true of other SSL-cert offerings.
Are they all at least adequate for Google's SEO purposes?
NameCheap provrides a wide range of certs. I'm sure this is true of other SSL-cert offerings.
Are they all at least adequate for Google's SEO purposes?
Yes, any certificate sold by them would trigger this "boost".
I'm all about this but what about third party static sites like everything on Github Pages? We're using Github to host http://kili.io which has all of our marketing material but there's no way to upload a certificate there. I'd rather not move off of Github Pages for the main site because it's easy to just push changes, it's fast, it makes it easy to tie into the rest of our open code (https://github.com/kili), and it's free.
Nice organization and cause, looks really interesting. Not being snarky at all but asking - you provide hosting but aren't able / won't host your marketing site on your own servers? Even if you don't have your own infrastructure, even grabbing a VPS from digital ocean or linode and throwing up a cert there could solve your problem.
You could use a CDN like CloudFlare or CloudFront to proxy and add in SSL
I'm not sure I agree with this. I don't see a point in HTTPS for 100% static sites.
The NSA and other state actors can use non-secure pages to inject code to exploit the browser and compromise your visitors.
http://en.wikipedia.org/wiki/FOXACID#QUANTUM_attacks
http://en.wikipedia.org/wiki/FOXACID#QUANTUM_attacks
State actors are probably irrelevant in this discussion; few of them won't be able to get a certificate to any website they want, in my opinion.
This is a known issue and being addressed as well.
http://tools.ietf.org/html/draft-ietf-websec-key-pinning-11
http://dev.chromium.org/sts
http://tools.ietf.org/html/draft-ietf-websec-key-pinning-11
http://dev.chromium.org/sts
That 100% static site can be monitored. Which pages you visit on it and what that says about you.
Privacy is always valuable.
Privacy is always valuable.
I'm not sure about "always".
I run a site that provides counter information for League of Legends (http://www.championcounter.com/) and I doubt very much my users will benefit at all from me moving over to HTTPS.
I run a site that provides counter information for League of Legends (http://www.championcounter.com/) and I doubt very much my users will benefit at all from me moving over to HTTPS.
A lot of work routers might flag that site url as "GAMING" and with too much use could potentially contribute to someone losing their job.
Also some isps have been caught injecting ads into plain text web sites [1]. Do you want more ads on your site that you didn't put there?
[1] http://zmhenkel.blogspot.com/2013/03/isp-advertisement-injec...
Also some isps have been caught injecting ads into plain text web sites [1]. Do you want more ads on your site that you didn't put there?
[1] http://zmhenkel.blogspot.com/2013/03/isp-advertisement-injec...
Switching over to HTTPS in and of itself shouldn't stop much data leakage given that the hostname - at least at current - isn't difficult to obtain (and really gives the game away for the content you're visiting as far as my site is concerned), but I suppose it's a step in the right direction and will stop primitive tracking attempts.
Protecting against code injection is actually a fair point though.
Protecting against code injection is actually a fair point though.
Sure they would benefit. They could check whatever is on your site without anyone in between noticing (WLAN e.g. at starbucks, corporate LANs and the proxies used etc etc). There are companies out there, who buy surf-habits (read: browsing logs of URLs visited) and mine it for valuable data.
Encrypt.
Encrypt.
You're seeing HTTPS as a move from HTTP with a burden.
Let's see it the other way: any sane webserver allows you to easily activate TLS, and generating a certificate is both free and easy. What's the point of going back to HTTP at this point ?
Let's see it the other way: any sane webserver allows you to easily activate TLS, and generating a certificate is both free and easy. What's the point of going back to HTTP at this point ?
Static sites can have their content modified silently in a MITM attack as well.
I'm interested in statistics (especially from websites with non-technical and international audiences) about what percent of visitors are using browsers/devices that don't support SNI.
I don't know how representative this is, but it looks like StatCounter Global Stats [1] says that slightly over 10% of recorded visitors are still using Windows XP, and many of these users won't have SNI support.
Small websites without strict security requirements often use shared hosting, where SNI is the only practical way to implement HTTPS. Alienating something like 10% of visitors with a security warning is probably not desirable. I imagine this could be a not insignificant roadblock to widespread SSL adoption on small websites, but would like to see more detailed stats.
[1] http://gs.statcounter.com/#os-ww-monthly-201307-201407
I don't know how representative this is, but it looks like StatCounter Global Stats [1] says that slightly over 10% of recorded visitors are still using Windows XP, and many of these users won't have SNI support.
Small websites without strict security requirements often use shared hosting, where SNI is the only practical way to implement HTTPS. Alienating something like 10% of visitors with a security warning is probably not desirable. I imagine this could be a not insignificant roadblock to widespread SSL adoption on small websites, but would like to see more detailed stats.
[1] http://gs.statcounter.com/#os-ww-monthly-201307-201407
http://www.utilitydive.com/ is a US-based news site for the electric utility industry. About 4.5% of visitors are on Win XP and most of those people are using XP. It's trending down pretty sharply; it was nearly twice that at the start of the year.
[deleted]
My issue with SSL everywhere is that I have to effectively buy my domain twice: once for the domain, and one again for the certificate. My registrar should give me a wildcard certificate good for the time I've paid for my domain.
Maybe because there isn't much of demand for that, yet.
Shall the transition come and we'd all perceive HTTPS as a default, it's very likely registrars would also offer certificate signing.
Shall the transition come and we'd all perceive HTTPS as a default, it's very likely registrars would also offer certificate signing.
The price wars for domain registration pushed the cost way down over the past few years. Certs are starting to move in the same direction. As volume picks up, they can cut margins. And some guys will start to treat it as baseline feature and not a buy-up.
This is my concern too. I manage 100+ clients registered and hosted in a variety of places (often because I'm inheriting their choice of host, registrar, etc). It's painful enough without adding SSL to the mix for even the littlest of sites.
Don't have a ton of experience with SSL and only recently started messing with TLS on my Apache server but question: Google makes mention of a 2048 bit certificate but most of the certificates I see are 128/256. Is this number referring to something else other than the strength of the encryption?
Messages like "your connection is encrypted with 256-bit encryption" don't tell you anything about the size of the RSA keys in use.
During the TLS handshake, your browser and the server do public-key crypto to authenticate each other and share private information without a previously-known shared secret. Because public-key crypto is really, really slow, they then share a small secret (say, 128 or 256 bits), and use that secret as the key for a traditional symmetric encryption algorithm like AES. That's the number you're seeing.
Take a look at https://en.wikipedia.org/wiki/Transport_Layer_Security
During the TLS handshake, your browser and the server do public-key crypto to authenticate each other and share private information without a previously-known shared secret. Because public-key crypto is really, really slow, they then share a small secret (say, 128 or 256 bits), and use that secret as the key for a traditional symmetric encryption algorithm like AES. That's the number you're seeing.
Take a look at https://en.wikipedia.org/wiki/Transport_Layer_Security
thank you both, that really makes sense. I thought it was a little peculiar that Google decided to mention the whole 2048 bit thing, I couldn't have been the only one that was thrown off by that a bit.
http://security.stackexchange.com/questions/19473/understand...
TL;DR: 2048bit is for the RSA keys, 128/256bit is the the key used in the SSL connection.
TL;DR: 2048bit is for the RSA keys, 128/256bit is the the key used in the SSL connection.
2048 is the RSA key size. 128 or 256 is the AES key size (or more generally the key size for the symmetric cipher). Nowadays the latter doesn't depend on the cert, but in the 90s it artificially did thanks to U.S. export policy. CAs still advertise as if we were stuck in the 90s.
[deleted]
Would be more awesome if they offered free certificates and an API to renew them.
Right now enabling https is not a one-time investment, since a new certificate has to be requested and installed each time the old one expires.
Computers are supposed to bring down cost and automate tedious tasks, for https the opposite is the case.
It’s worth mentioning that https://www.startssl.com/ does offer free certificates. But without a paid account they last only a year and cannot be issued to wildcard domains, so you quickly end up with a lot of certificates that has to be manually renewed each year.
Right now enabling https is not a one-time investment, since a new certificate has to be requested and installed each time the old one expires.
Computers are supposed to bring down cost and automate tedious tasks, for https the opposite is the case.
It’s worth mentioning that https://www.startssl.com/ does offer free certificates. But without a paid account they last only a year and cannot be issued to wildcard domains, so you quickly end up with a lot of certificates that has to be manually renewed each year.
The SSL CA model is deeply flawed, so it bothers me that I have to pay into this broken cartel.
An effective social network for website trust, combining cryptographic assurances with trust networks that already exist, is my dream.
(Edit: Clarify that the SSL CA model is flawed for the Internet at large, but has many useful applications elsewhere.)
An effective social network for website trust, combining cryptographic assurances with trust networks that already exist, is my dream.
(Edit: Clarify that the SSL CA model is flawed for the Internet at large, but has many useful applications elsewhere.)
> Would be more awesome if they offered free certificates and an API to renew them.
If someone were able to do this and pull the rug out from under the SSL cartel overnight, that would be awesome.
If someone were able to do this and pull the rug out from under the SSL cartel overnight, that would be awesome.
Many "free" certificate services don't give reissued certificates for free, though, so if something like Heartbleed happens again, you might still pay a fee.
What about a kickstarter to subsidize SSL costs? Or how about one to buy a root CA and make it free?
There is already a community-driven CA: http://www.cacert.org/
The problem is that it's not only about money. You need to follow certain procedures or browsers and OSs won't include your root certificate.
The problem is that it's not only about money. You need to follow certain procedures or browsers and OSs won't include your root certificate.
I don't think anyone has confidence in CACert anymore. IIRC they bombed their internal audit...
They are free to get, but you have to pay money if you need to revoke that certificate.
Which you don't really need to. Sure it disables all the security, but if you only care about the speed boost/cover your ass part it is a non-issue.
Yes, you do. If there is another Heartbleed, your certificate is worthless if someone has the chance to grab it.
I'm sorry, but this simply isn't something a search engine should be dictating. Turning enabling SSL into some arms race that panics small businesses into buying millions of new, pointless certificates just isn't very fair.
This kind of policy needs to be discussed openly in a suitable forum, e.g. the IETF, not handed down to us by a single company who think they have a right to dictate how the Internet works - and have provably done a horrible job of it in the past (websocket over SPDY, anyone? Yeah, I'm not even sure which version combination of SPDY and websocket I'm talking about either - pick one of the hundred)
There are strong arguments for not enabling privacy by default - not least since it prevents any kind of decentralization or caching of content. At a time when OpenSSL just suffered one of its worst bugs in history, forcing small sites to assume the risk of running code like this, which they inevitably will get wrong, materially worsens security for all, it doesn't improve it.
This kind of policy needs to be discussed openly in a suitable forum, e.g. the IETF, not handed down to us by a single company who think they have a right to dictate how the Internet works - and have provably done a horrible job of it in the past (websocket over SPDY, anyone? Yeah, I'm not even sure which version combination of SPDY and websocket I'm talking about either - pick one of the hundred)
There are strong arguments for not enabling privacy by default - not least since it prevents any kind of decentralization or caching of content. At a time when OpenSSL just suffered one of its worst bugs in history, forcing small sites to assume the risk of running code like this, which they inevitably will get wrong, materially worsens security for all, it doesn't improve it.
> At a time when OpenSSL just suffered one of its worst bugs in history, forcing small sites to assume the risk of running code like this, which they inevitably will get wrong, materially worsens security for all, it doesn't improve it.
OpenSSL is not the only SSL stack you know. I run one of my websites on Tomcat so I can benefit from the pure-Java TLS stack it uses (the default one actually). Something like heartbleed is impossible for such a stack.
OpenSSL is not the only SSL stack you know. I run one of my websites on Tomcat so I can benefit from the pure-Java TLS stack it uses (the default one actually). Something like heartbleed is impossible for such a stack.
This is _exactly_ the kind of thing that only a player as heavy as Google can kickstart.
We need to "reset the net", encrypt everything possible, and Google's help is more then welcome.
We need to "reset the net", encrypt everything possible, and Google's help is more then welcome.
[deleted](1)
I think your description of the situation is rather overblown. Having HTTPS support will only get you a very minor boost in rankings.
Additionally, discussing things in a forum usually doesn't get things moving. It's coming out with actual advancements like the original Chrome beta with V8 that drives innovation.
I think that the solution to harmful dictatorship should be good alternatives, not more laws to shackle progress to humongous councils.
Additionally, discussing things in a forum usually doesn't get things moving. It's coming out with actual advancements like the original Chrome beta with V8 that drives innovation.
I think that the solution to harmful dictatorship should be good alternatives, not more laws to shackle progress to humongous councils.
"Having HTTPS support will only get you a very minor boost in rankings."
If your livelihood depends on getting traffic from Google - and a lot of sites do - then even a minor boost may equal a lot of money. Plus the fact that you can never know quite how much, so to be safe you must assume it's worthwhile.
The problem I have with this move is that to me it appears as Google are furthering their own political agenda. They want the web to be https, so they penalise sites that are not. It would be different if the argument was that sites on https tend to hold more quality content than non-https sites, but that doesn't seem to be the reasoning.
If your livelihood depends on getting traffic from Google - and a lot of sites do - then even a minor boost may equal a lot of money. Plus the fact that you can never know quite how much, so to be safe you must assume it's worthwhile.
The problem I have with this move is that to me it appears as Google are furthering their own political agenda. They want the web to be https, so they penalise sites that are not. It would be different if the argument was that sites on https tend to hold more quality content than non-https sites, but that doesn't seem to be the reasoning.
Why is "quality content" an objective measure and "user security and privacy" a political agenda?
I agree that it's dangerous for one entity to have so much power over the web, but I don't see how is this particular signal any different from any other they already use, including those which define the quality of the content.
I agree that it's dangerous for one entity to have so much power over the web, but I don't see how is this particular signal any different from any other they already use, including those which define the quality of the content.
This kind of policy needs to be discussed openly in a suitable forum, e.g. the IETF, not handed down to us by a single company who think they have a right to dictate how the Internet works
I don't see how is this any different from any other signal that Google uses to prioritize sites. Forcing small businesses to buy certificates doesn't seem any different than forcing them to have faster websites, for example.
There's an argument for more diversity in search engines, but I don't see how is that specific to this signal.
There are strong arguments for not enabling privacy by default - not least since it prevents any kind of decentralization or caching of content.
How does it prevent decentralization?
At a time when OpenSSL just suffered one of its worst bugs in history, forcing small sites to assume the risk of running code like this, which they inevitably will get wrong, materially worsens security for all, it doesn't improve it.
How many people could exploit Heartbleed before it was publicly announced compared to how could sniff traffic on open networks, as countless tutorials explain how to do?
Heartbleed was bad, and OpenSSL is a mess, but let's pretend that unencrypted logins are somehow less bad.
I don't see how is this any different from any other signal that Google uses to prioritize sites. Forcing small businesses to buy certificates doesn't seem any different than forcing them to have faster websites, for example.
There's an argument for more diversity in search engines, but I don't see how is that specific to this signal.
There are strong arguments for not enabling privacy by default - not least since it prevents any kind of decentralization or caching of content.
How does it prevent decentralization?
At a time when OpenSSL just suffered one of its worst bugs in history, forcing small sites to assume the risk of running code like this, which they inevitably will get wrong, materially worsens security for all, it doesn't improve it.
How many people could exploit Heartbleed before it was publicly announced compared to how could sniff traffic on open networks, as countless tutorials explain how to do?
Heartbleed was bad, and OpenSSL is a mess, but let's pretend that unencrypted logins are somehow less bad.
>any other signal that Google uses to prioritize sites
they don't just own the signals and sites... the own access to data about your digital life and their algorithms process it as another signal in mining your life.
Google said "don't be evil":
http://www.reuters.com/article/2014/04/25/us-apple-google-la...
they don't just own the signals and sites... the own access to data about your digital life and their algorithms process it as another signal in mining your life.
Google said "don't be evil":
http://www.reuters.com/article/2014/04/25/us-apple-google-la...
heartbleed was much much worse than unencrypted logins.
I agree that the worst case scenario is much worse; I don't see how it was much worse for the average website of a small business.
> I don't see how is this any different from any other signal that Google uses to prioritize sites.
«Oh, they're screwing up before, too? Then I guess it's alright»
> How does it prevent decentralization? Because only a handful of companies can issue certificates.
> How does it prevent decentralization? Because only a handful of companies can issue certificates.
«Oh, they're screwing up before, too? Then I guess it's alright»
How is it screwing up? How are they supposed to run a search engine without prioritizing? "Here's 30000 results, we've randomly sorted them for you"?
Because only a handful of companies can issue certificates.
Fair enough.
How is it screwing up? How are they supposed to run a search engine without prioritizing? "Here's 30000 results, we've randomly sorted them for you"?
Because only a handful of companies can issue certificates.
Fair enough.
Apologies, I haven't made myself clear with that idiotic of a snarky remark :) What I meant is that their actions in the past shouldn't be an excuse to their actions today.
The principles behind PageRank are based on unbiased reputation, and provide for a good ranking system (spammers aside). Whatever's thrown on top needs to be carefully considered not to enforce biases towards any group in particular.
The principles behind PageRank are based on unbiased reputation, and provide for a good ranking system (spammers aside). Whatever's thrown on top needs to be carefully considered not to enforce biases towards any group in particular.
> How are they supposed to run a search engine without prioritizing?
Maybe quality of content? If the best info gets buried because they can't afford a cert or don't have a need for one then this hurts the Internet.
Maybe quality of content? If the best info gets buried because they can't afford a cert or don't have a need for one then this hurts the Internet.
> I'm sorry, but this simply isn't something a search engine should be dictating.
Damned if you do, damned if you don't. If the announcement from Google had been that they wouldn't want to use their considerable clout to promote SSL, they'd been criticized for putting their profits over improving the general long term health of the internet.
> have provably done a horrible job of it in the past
That's a single example of a new technology that didn't work out well. How about pioneering certificate pinning for a counter example? Nobody's perfect, if you never break anything it means you never try anything new. Also, websockets and SPDY isn't even close to "dictating" anything, it's a new technology that you can use or not use as you want to.
Damned if you do, damned if you don't. If the announcement from Google had been that they wouldn't want to use their considerable clout to promote SSL, they'd been criticized for putting their profits over improving the general long term health of the internet.
> have provably done a horrible job of it in the past
That's a single example of a new technology that didn't work out well. How about pioneering certificate pinning for a counter example? Nobody's perfect, if you never break anything it means you never try anything new. Also, websockets and SPDY isn't even close to "dictating" anything, it's a new technology that you can use or not use as you want to.
Google is free to use any metric to score their ranking. The difference is this one they are telling us about.
HTTPS is also used to upgrade connections to stuff like HTTP2 and SPDY which give a substantial improvement to speed, which in turns improves satisfaction. So it makes sense to priotise https sites.
HTTPS is also used to upgrade connections to stuff like HTTP2 and SPDY which give a substantial improvement to speed, which in turns improves satisfaction. So it makes sense to priotise https sites.
This is great, but it should also be a reminder that SSL is currently not possible for custom domains hosted on GitHub: https://konklone.com/post/github-pages-now-supports-https-so....
I hope a solution materializes eventually.
I hope a solution materializes eventually.
It's still expensive to offer SSL when you have a CDN in front unless you go with just SNI support (which could cost a significant portion of your visitors).
We have CDN backed HTTPS for custom sites on BitBalloon (https://www.bitballoon.com) if you're interested in a Github pages alternative that supports SSL.
We have CDN backed HTTPS for custom sites on BitBalloon (https://www.bitballoon.com) if you're interested in a Github pages alternative that supports SSL.
Yup - Akamai must be rubbing their hands in glee at this announcement. I've already started the conversations here about how much this is going to cost for big CDN hosted projects...
Now you can contact Github with this announcement and voice your concerns. Now they have more incentive to change it (if people actively voice their issues to Github).
I don't have the best experience with submitting feedback to GitHub and getting good responses, so hopefully someone like @konklone can make that case to them - again.
Lol, they are not using HTTPS to serve that content. Look who's talking...
If this change is here to stay they should update their Adsense SSL advice... https://support.google.com/adsense/answer/10528?hl=en-GB
Just doing a little more research. It appears as though many of these EV certs require you to verify your company information, domain registration, phone number and even address. With Google using however many hundred or thousand ranking signals, this makes sense. It is essentially another layer of trust and really great for UX as well. Online shoppers trust a site with the "green location bar" much more than ones without it, and I could definitely see how Google might reward this type of website.
This is great, it's just a fact that ssl will not have major adoption unless there's a clear UI or business reason for it.
I hope google takes it one step further and updates chrome to show an insecure warning when it detects a password field on the page and it is sent plain over http.
I hope google takes it one step further and updates chrome to show an insecure warning when it detects a password field on the page and it is sent plain over http.
Considering the importance of HTTPS to, in Google's words, "[making the] Internet safer more broadly", this seems like a good time to again suggest that Google enable HTTPS for Google Analytics by default[1].
Google Analytics is on 50.8% of the top million domains on the Internet, and on 26.96% of a randomly selected 48.5 million domains[1]. Of the 42 billion links analyzed in my research, over 48% of them had Google Analytics on either the start or the end. That's a lot of information leakage.
Anyone who is eavesdropping on HTTP connections to the Google Analytics endpoints can observe a web user's traffic history trivially. This enables simple mass surveillance by specifically looking for these connections and recording them. HTTPS would prevent that.
I should note, whilst there is an option to specifically force SSL in the new Google Analytics[2], it must be enabled by default in order to have a positive impact. We can't rely on the owners of millions of domains to upgrade to ensure an end user's privacy.
[1]: http://smerity.com/articles/2013/google_analytics_and_nsa.ht...
[2]: https://developers.google.com/analytics/devguides/collection...
Google Analytics is on 50.8% of the top million domains on the Internet, and on 26.96% of a randomly selected 48.5 million domains[1]. Of the 42 billion links analyzed in my research, over 48% of them had Google Analytics on either the start or the end. That's a lot of information leakage.
Anyone who is eavesdropping on HTTP connections to the Google Analytics endpoints can observe a web user's traffic history trivially. This enables simple mass surveillance by specifically looking for these connections and recording them. HTTPS would prevent that.
I should note, whilst there is an option to specifically force SSL in the new Google Analytics[2], it must be enabled by default in order to have a positive impact. We can't rely on the owners of millions of domains to upgrade to ensure an end user's privacy.
[1]: http://smerity.com/articles/2013/google_analytics_and_nsa.ht...
[2]: https://developers.google.com/analytics/devguides/collection...
Friendly reminder - there's a free, pro-privacy and open-source solution available:
http://piwik.org/
http://piwik.org/
Sorry to jump in with a tangential reply, but BEWARE of the following!
Google treat the http and https versions of a domain as SEPARATE PROPERTIES. This means that even if you 301 every http page to https when you transition, all of your current rankings and pagerank will be irrelevant.
You can verify this behaviour for yourself in webmaster tools.
I suppose this is because it's possible to serve up different content on http/s, but really, who does that?!
In short, don't do this until google rethink their stance on what counts as a property. I'm currently nursing a client with a 30% revenue hole as a result of this.
Google treat the http and https versions of a domain as SEPARATE PROPERTIES. This means that even if you 301 every http page to https when you transition, all of your current rankings and pagerank will be irrelevant.
You can verify this behaviour for yourself in webmaster tools.
I suppose this is because it's possible to serve up different content on http/s, but really, who does that?!
In short, don't do this until google rethink their stance on what counts as a property. I'm currently nursing a client with a 30% revenue hole as a result of this.
> Google treat the http and https versions of a domain as SEPARATE PROPERTIES.
That's not quite accurate. It's on a per-URL basis, not properties. Webmaster Tools asks you to verify the different _sites_ (HTTP/HTTPS, www/non-www) separately because they can be very different. And yes I've personally seen a few cases - one somewhat strange example bluntly chides their users when they visit the HTTP site and tells them to visit the site again as HTTPS.
> This means that even if you 301 every http page to https when you transition, all of your current rankings and pagerank will be irrelevant.
That's not true. If you correctly redirect and do other details correctly (no mixed content, no inconsistent rel=canonical links, and everything else mentioned in the I/O video I referenced), then our algos will consolidate the indexing properties onto the HTTPS URLs. This is just another example of correctly setting up canonicalization.
By the way, if you're moving to HTTPS, following our site moves guidelines:
https://support.google.com/webmasters/topic/6033102?hl=en&re...
specifically, the site moves with URL changes:
https://support.google.com/webmasters/answer/6033049?hl=en&r...
But you did say you have a client with an issue. I suspect they either implemented the move to HTTPS incorrectly or something else is going on. Please ask for more help at our forums:
https://productforums.google.com/forum/#!categories/webmaste...
That's not quite accurate. It's on a per-URL basis, not properties. Webmaster Tools asks you to verify the different _sites_ (HTTP/HTTPS, www/non-www) separately because they can be very different. And yes I've personally seen a few cases - one somewhat strange example bluntly chides their users when they visit the HTTP site and tells them to visit the site again as HTTPS.
> This means that even if you 301 every http page to https when you transition, all of your current rankings and pagerank will be irrelevant.
That's not true. If you correctly redirect and do other details correctly (no mixed content, no inconsistent rel=canonical links, and everything else mentioned in the I/O video I referenced), then our algos will consolidate the indexing properties onto the HTTPS URLs. This is just another example of correctly setting up canonicalization.
By the way, if you're moving to HTTPS, following our site moves guidelines:
https://support.google.com/webmasters/topic/6033102?hl=en&re...
specifically, the site moves with URL changes:
https://support.google.com/webmasters/answer/6033049?hl=en&r...
But you did say you have a client with an issue. I suspect they either implemented the move to HTTPS incorrectly or something else is going on. Please ask for more help at our forums:
https://productforums.google.com/forum/#!categories/webmaste...
Nope, we followed the instructions to the tee. Straight 301 redirects from http to https, appropriate canonicals on all pages referencing https, and their SEO has seemingly started from scratch - used to be in position 1 for a variety of important keywords and searches, now they're beyond page 10.
Oh, and you can't do a change of address from http://www.whatever.com to https://www.whatever.com - you don't allow it!
Oh, and you can't do a change of address from http://www.whatever.com to https://www.whatever.com - you don't allow it!
This suggests something else is going on. Please post in the forums with the site details.
Done. Thanks.
The IO talk covers this. There's a few steps involved beyond just sending a 301 such as putting a rel=canonical on the https site.
Yeah, did everything that's possible within the document - although a few steps (Change Of Address) are actually impossible - GWT disallows it within the same domain. Still, SEO in the can.
The Google blog says that TLS is a (presumably positive) ranking signal, they do not state whether leaving the site available unencrypted is a negative signal.
Until they clear up that ambiguity it seems risky to go TLS only for exactly the reason you cite.
Until they clear up that ambiguity it seems risky to go TLS only for exactly the reason you cite.
If X is a positive signal, then not-X is a negative signal.
That does not follow logically. not-X is typically zero, just like not having an inbound link from a high pagerank page is not a negative. Besides, there are three situation: no-https, both http/https and http-only, which makes your claim that the middle one is negative seem less likely.
Say there are five sites that would normally be returned for a query and they have scores A:20 B:18 C:10 D:8 E:4. The results will look like "A, B, C, D, E". Say none of them support https, and then the search engine adds https as a positive ranking factor worth +3. Site C turns on https, the order still is "A, B, C, D, E". Now site B turns on https, the order is now "B, A, C, D, E".
Imagine instead they had added "lack of https" as a ranking factor worth -3. The rankings on the page would have changed exactly the same way.
"not having an inbound link" can be thought of as a negative without changing rankings. In the example above, if getting an inbound link from apple.com would move you up 4 points, then if B got a link from apple that would put them at 22 to A's 20. If instead "not having a link from apple" was worth -4 points, then A would be at 16 and B at 18.
Imagine instead they had added "lack of https" as a ranking factor worth -3. The rankings on the page would have changed exactly the same way.
"not having an inbound link" can be thought of as a negative without changing rankings. In the example above, if getting an inbound link from apple.com would move you up 4 points, then if B got a link from apple that would put them at 22 to A's 20. If instead "not having a link from apple" was worth -4 points, then A would be at 16 and B at 18.
There is no doubt that https adds a positive value, and not having it would put you at a disadvantage. But that is not what is being discussed here, the question is whether having BOTH https and http is a negative.
the default noted there seems fine? if HTTPS, then GA uses HTTPS, if HTTP, GA uses HTTP
with firefox adding in mixed-content-complaining not too long ago [1], along with IE having it for a while, and apparantly chrome having it too, its best to match protocol to minimize issues for the user
[1]: https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-bloc...
with firefox adding in mixed-content-complaining not too long ago [1], along with IE having it for a while, and apparantly chrome having it too, its best to match protocol to minimize issues for the user
[1]: https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-bloc...
Browsers only complain if you go from HTTPS=>HTTP, not the other way around, so there is no mixed content warning. The article itself, hosted on Blogger, demonstrates this if you check the source code -- whilst the website is HTTP, it uses JS hosted on HTTPS, with no mixed content issue.
To reiterate on the issue with HTTP default, the issue is that Google Analytics being HTTP on all HTTP sites results in a far easier man-in-the-middle target. An attacker only needs to eavesdrop on messages being sent to the Google Analytics endpoints, a far smaller and simpler task than observing and parsing all HTTP traffic.
As such, a default of HTTP even if the website itself uses HTTP is something I'd term a major issue. An ISP or government agency could track the web traffic of an enormous number of users without having to perform any real processing of their own. Admittedly, they'd only see a subset of what Google sees, but that's still a lot.
To reiterate on the issue with HTTP default, the issue is that Google Analytics being HTTP on all HTTP sites results in a far easier man-in-the-middle target. An attacker only needs to eavesdrop on messages being sent to the Google Analytics endpoints, a far smaller and simpler task than observing and parsing all HTTP traffic.
As such, a default of HTTP even if the website itself uses HTTP is something I'd term a major issue. An ISP or government agency could track the web traffic of an enormous number of users without having to perform any real processing of their own. Admittedly, they'd only see a subset of what Google sees, but that's still a lot.
If only..... there are numerous browser bugs out there where HTTP=>HTTPS ends with warnings or failures.
e.g. in IE9, see point 7 on http://blogs.msdn.com/b/ieinternals/archive/2010/05/13/xdoma...
e.g. in IE9, see point 7 on http://blogs.msdn.com/b/ieinternals/archive/2010/05/13/xdoma...
It doesn't show up if you have an HTTPS script on an HTTP page.
I'm surprised by the amount of negative comments. Independently of what do you think about HTTPS and CAs in general. Given there the alternative currently is plain text, I'm actually surprised that it wasn't a signal before.
I see this has negative for several reasons :
* Certificates are expensive (to buy _and_ to manage)
* Crypto is hard and there will be a lot of screw up with inadequate certs in the wild for a long time. Just having a certificate does not mean much if it weak or broken.
* Can't help the feeling it's an indirect push for cloud business hence possibly eating the margin of freelancers / ISV
* Security Theatre : a lot of critical information for business still transit by email. Will Google force encrypted emails for the greater good ? I don't think so.
* Certificates are expensive (to buy _and_ to manage)
* Crypto is hard and there will be a lot of screw up with inadequate certs in the wild for a long time. Just having a certificate does not mean much if it weak or broken.
* Can't help the feeling it's an indirect push for cloud business hence possibly eating the margin of freelancers / ISV
* Security Theatre : a lot of critical information for business still transit by email. Will Google force encrypted emails for the greater good ? I don't think so.
Google is not "enforcing" anything, people react like if you are not going to show up in the results at all, or Chrome won't work via HTTP. HTTPS is signal, just like having a link from a well ranked website like HN is a signal, and probably dozens other.
The points you mention are in fact indicators that someone has put care and resources to make their site work more securely, which says a good thing about the site, which google rewards with some points in their algorithm. Makes perfect sense to me that this will somewhat improve the quality of their results. Would you also complain about google using fast response times as a signal because that "forces" people to pay for better servers?
About your security point, google can not do that without loosing 50% of its customers, I really don't understand what that has to do with the rewarding HTTPS being good or bad. Looks like a red herring.
The points you mention are in fact indicators that someone has put care and resources to make their site work more securely, which says a good thing about the site, which google rewards with some points in their algorithm. Makes perfect sense to me that this will somewhat improve the quality of their results. Would you also complain about google using fast response times as a signal because that "forces" people to pay for better servers?
About your security point, google can not do that without loosing 50% of its customers, I really don't understand what that has to do with the rewarding HTTPS being good or bad. Looks like a red herring.
Right, you will not disappear from the results. The reaction (granted maybe overreaction) is about Google pushing HTTPS hard for security (which could be good but not automatically so) and not caring in areas where it is as important if not more.
You are just proving my point. Google rewards the richest, those who have the resources as you say. As for care, I would be clad if people were not going to do it for the wrong incentives. Will Google just check if HTTPS is available and reward or will it also check for broken cipher and penalize ?
I am not against HTTPS. Just saying that rewarding HTTPS is not enough. It's worst actually, some will set it up quickly and badly just for the extra ranking points and not the actual security it should be providing.
To me the red herring here is pretending doing it for security. What is the point of HTTPS if I receive my password by mail ? To me email is more important to secure first. Google could perfectly incentive security practices in Gmail without loosing a single customer. I would even settle for just signing instead of encrypting mails.
As for enforcing, HTTP2 (that is SPDY) IS enforcing HTTPS.
IMO, Good HTTPS where it matters is more important then Crappy HTTPS everywhere just is ridiculous and could even be dangerous thanks to a false sense of security.
You are just proving my point. Google rewards the richest, those who have the resources as you say. As for care, I would be clad if people were not going to do it for the wrong incentives. Will Google just check if HTTPS is available and reward or will it also check for broken cipher and penalize ?
I am not against HTTPS. Just saying that rewarding HTTPS is not enough. It's worst actually, some will set it up quickly and badly just for the extra ranking points and not the actual security it should be providing.
To me the red herring here is pretending doing it for security. What is the point of HTTPS if I receive my password by mail ? To me email is more important to secure first. Google could perfectly incentive security practices in Gmail without loosing a single customer. I would even settle for just signing instead of encrypting mails.
As for enforcing, HTTP2 (that is SPDY) IS enforcing HTTPS.
IMO, Good HTTPS where it matters is more important then Crappy HTTPS everywhere just is ridiculous and could even be dangerous thanks to a false sense of security.
> Google rewards the richest, those who have the resources as you say.
Google doesn't care who is it rewarding, google cares about the users that search, they've said that multiple times. And yes, people with better resources build on average better things than people without them.
> I am not against HTTPS. Just saying that rewarding HTTPS is not enough. It's worst actually, some will set it up quickly and badly just for the extra ranking points and not the actual security it should be providing.
Even then, still 10 times better than plain text HTTP so my whole office can see what I'm browsing with a simple console command.
> What is the point of HTTPS if I receive my password by mail ?
Your email inbox should be accessed via TLS, it's something up to you. And while you don't control the origin (nobody can without breaking compatibility) intercepting a message in transit like that if not exactly something most people I know can do. While getting that password over HTTP is almost trivial for anyone sitting around me.
> As for enforcing, HTTP2 (that is SPDY) IS enforcing HTTPS.
The day you can only see a website via SPDY then I would call that enforcing it. Yes if you want to carrot (performance) you have to pass through the hop (security), nobody forces you to eat the carrot.
> IMO, Good HTTPS where it matters is more important then Crappy HTTPS everywhere just is ridiculous and could even be dangerous thanks to a false sense of security.
I really can not get which scenario you are picturing here. Setting it up is not rocket science.
Google doesn't care who is it rewarding, google cares about the users that search, they've said that multiple times. And yes, people with better resources build on average better things than people without them.
> I am not against HTTPS. Just saying that rewarding HTTPS is not enough. It's worst actually, some will set it up quickly and badly just for the extra ranking points and not the actual security it should be providing.
Even then, still 10 times better than plain text HTTP so my whole office can see what I'm browsing with a simple console command.
> What is the point of HTTPS if I receive my password by mail ?
Your email inbox should be accessed via TLS, it's something up to you. And while you don't control the origin (nobody can without breaking compatibility) intercepting a message in transit like that if not exactly something most people I know can do. While getting that password over HTTP is almost trivial for anyone sitting around me.
> As for enforcing, HTTP2 (that is SPDY) IS enforcing HTTPS.
The day you can only see a website via SPDY then I would call that enforcing it. Yes if you want to carrot (performance) you have to pass through the hop (security), nobody forces you to eat the carrot.
> IMO, Good HTTPS where it matters is more important then Crappy HTTPS everywhere just is ridiculous and could even be dangerous thanks to a false sense of security.
I really can not get which scenario you are picturing here. Setting it up is not rocket science.
> Google doesn't care who is it rewarding, google cares about the users that search, they've said that multiple times.
Hum, well I've grown wary of what Google say. Like puting comercial mail in a separated inbox is to help the user. It also happens to indirectly help Adsense.
> And yes, people with better resources build on average better things than people without them.
Does that mean content created by association without a dime for instance is on average inferior ?
I happen to like cooking. I often find websites with great content by word of mouth. They are generally badly ranked because they look like they were done on Frontpage and from Geocities ages. Yet the content is very good and even sometime quite unique. They rank badly because they are not speedy and in beautiful html5. That's elitism. Maybe they should by Adwords.
> Even then, still 10 times better than plain text HTTP so my whole office can see what I'm browsing with a simple console command.
That is one of the few good arguments for HTTPS everywhere : privacy.
> And while you don't control the origin (nobody can without breaking compatibility)
You can encrypt or even just sign emails without breaking compatibility. Put commercial email in a separated inbox is OK but put unencrypted and/or unsigned email in a separated inbox is not ?
> While getting that password over HTTP is almost trivial for anyone sitting around me. > I really can not get which scenario you are picturing here. Setting it up is not rocket science.
Is it better to have open WiFi or WiFi with WEP ? It's the same because WEP is nowadays easily broken by script kiddies with simple tools.
That the scenario I'm picturing here. A web full of weak/broken certs to comply for ranking, people feeling safe (it's encrypted right ?) and script kiddies with trival tools to break the WEP equivalent of weak/broken HTTPS certs.
Granted, maybe I'm over-pessimistic here but the trend annoy me. i don't take Google at face value anymore. You know they excel at long play.
On the bright side, maybe people will use their certs for more than HTTPS ... say mail server for instance :)
Hum, well I've grown wary of what Google say. Like puting comercial mail in a separated inbox is to help the user. It also happens to indirectly help Adsense.
> And yes, people with better resources build on average better things than people without them.
Does that mean content created by association without a dime for instance is on average inferior ?
I happen to like cooking. I often find websites with great content by word of mouth. They are generally badly ranked because they look like they were done on Frontpage and from Geocities ages. Yet the content is very good and even sometime quite unique. They rank badly because they are not speedy and in beautiful html5. That's elitism. Maybe they should by Adwords.
> Even then, still 10 times better than plain text HTTP so my whole office can see what I'm browsing with a simple console command.
That is one of the few good arguments for HTTPS everywhere : privacy.
> And while you don't control the origin (nobody can without breaking compatibility)
You can encrypt or even just sign emails without breaking compatibility. Put commercial email in a separated inbox is OK but put unencrypted and/or unsigned email in a separated inbox is not ?
> While getting that password over HTTP is almost trivial for anyone sitting around me. > I really can not get which scenario you are picturing here. Setting it up is not rocket science.
Is it better to have open WiFi or WiFi with WEP ? It's the same because WEP is nowadays easily broken by script kiddies with simple tools.
That the scenario I'm picturing here. A web full of weak/broken certs to comply for ranking, people feeling safe (it's encrypted right ?) and script kiddies with trival tools to break the WEP equivalent of weak/broken HTTPS certs.
Granted, maybe I'm over-pessimistic here but the trend annoy me. i don't take Google at face value anymore. You know they excel at long play.
On the bright side, maybe people will use their certs for more than HTTPS ... say mail server for instance :)
> Google rewards the richest
Oh come on.. if multiplying your ranking by 0.01 (now) means that much to you, then probably you're making enough money you can afford a cert - or you probably have one in place.
Oh come on.. if multiplying your ranking by 0.01 (now) means that much to you, then probably you're making enough money you can afford a cert - or you probably have one in place.
Some refuting instead of down voting ?
upside: security, further migration to HTTP/2 easier (when it's ready)
downside: HTTPS negotiation time overhead (slower website) (as long as we use HTTP 1.1), costs (certificate, technical migration)
all in all i think it's a great move by google, thx
downside: HTTPS negotiation time overhead (slower website) (as long as we use HTTP 1.1), costs (certificate, technical migration)
all in all i think it's a great move by google, thx
Only the first connection should be delayed a bit
http://vincent.bernat.im/en/blog/2011-ssl-session-reuse-rfc5...
[deleted]
"Security is a top priority for Google. We invest a lot in making sure that our services use industry-leading security, like strong HTTPS encryption by default."
-- Says Google site that forces HTTP.
-- Says Google site that forces HTTP.
People that write content for websites are not always the same people that build those websites. In this case, the search engine team is entirely separate from the Blogspot team.
> People that write content for websites are not always the same people that build those websites.
Wow Seriously? You don't say.
Seems the irony escaped you: announcement was made on a Google site that forces (i.e redirects from HTTPS) you to read it over HTTP.
If you read closely enough it refers to all of Google, not just "the search engine team" or (Google - Blogspot).
Wow Seriously? You don't say.
Seems the irony escaped you: announcement was made on a Google site that forces (i.e redirects from HTTPS) you to read it over HTTP.
If you read closely enough it refers to all of Google, not just "the search engine team" or (Google - Blogspot).
Internet law: Your good post will be ruthlessly torn apart. Agreement is drivel. The best you can hope for is a slightly different point which happens to agree.
Btw, I agree with you, and I think this phenomenon is dumb.
Btw, I agree with you, and I think this phenomenon is dumb.
Another internet law: Do as Google says, not as Google does.
>Seems the irony escaped you
Oh no, I commented on it directly. By the way I noticed you comment on Hacker News, you should probably stop using table-based layouts on your websites.
Oh no, I commented on it directly. By the way I noticed you comment on Hacker News, you should probably stop using table-based layouts on your websites.
there is something odd about this announcement. since it is no harder for a black hat publisher to switch to https than a white hat publisher, this signal will likely get noisy very quickly. i think google knows this, and its why they rarely specify ranking signals.
so, then really, they are just using their dominance in search to effect change. now, you may agree with the change (they did something similar by announcing pageload time as a signal), but it makes me a little uneasy for google to leverage their dominance in this way even if i happen to agree with the goal.
so, then really, they are just using their dominance in search to effect change. now, you may agree with the change (they did something similar by announcing pageload time as a signal), but it makes me a little uneasy for google to leverage their dominance in this way even if i happen to agree with the goal.
This wouldn't be so bad if there were more support for CAcert. It's great news for the commercial certificate authorities, though.
After some interaction (including assuring people), my impression of CAcert is much more negative than my impression with any of those big bad CAs everyone likes to complain about.
They are so far off this side of "sane" it's really not funny.
They are so far off this side of "sane" it's really not funny.
Are you able to elaborate? If not that's fine, but I just don't think paying for a cert makes it somehow better, so I liked the idea of CAcert. If I should be concerned about using them to secure personal sites (in this sense really only used by myself and a few friends who have the CA root cert) I'd be interested in knowing.
Here's the big differentiation that the now still beta and invite-only Google Domains could take on: assign free wildcard SSL certificate for every domain registered/transferred there.
I've just signed up for a 5 year certificate using https://www.gogetssl.com/comodo-ssl-certificates/comodo-posi... for $18 - I know there's annual free ones, but at that price is it worth the hassle of renewing?
Never used them before, but they're just a Comodo reseller, and they take Paypal, so there seemed little that could go wrong.
Has so far gone smoothly, certificate installed, passes the SSL test google mention, https://www.ssllabs.com/ssltest/ so it all seems good
Never used them before, but they're just a Comodo reseller, and they take Paypal, so there seemed little that could go wrong.
Has so far gone smoothly, certificate installed, passes the SSL test google mention, https://www.ssllabs.com/ssltest/ so it all seems good
But this site is still on HTTP. When I tried HTTPS it redirected to HTTP. Even they are not ready it seems.
So what reasonable options does a small to medium site operator now have to buy SSL certs?
For example there is Comodo "FREE" certificate and the one that costs 64.95 Euros.
What is the catch with the free one?
For example there is Comodo "FREE" certificate and the one that costs 64.95 Euros.
What is the catch with the free one?
Likely nothing relevant - you just can't revocate it, but it should still give you the speed boost.
Let's kill small ISV and raise the bar of entrance to the internet. Oh certificate management is too complex and expensive for too little ROI ? Well see, here we have a nice "cheap to the eye" cloud solution just for you.
Security isn't the priority here. Selling cloud is.
Edit: IMHO, same goes for SPDY/HTTP2 by the way
Security isn't the priority here. Selling cloud is.
Edit: IMHO, same goes for SPDY/HTTP2 by the way
Wow. For those needing to support non-SNI browsers, this is going to become a real IPv4 address land-grab.
IPv6 is disturbingly uncommon still...
IPv6 is disturbingly uncommon still...
supporting non-SNI browsers is less common. Over the last two years i've seen a huge drop off in ie8/XP traffic on my sites.
Android 2.x doesn't support SNI either, it's not just IE. (20% of Android users: https://developer.android.com/about/dashboards/index.html)
But I agree, it has dwindled rapidly. :-)
But I agree, it has dwindled rapidly. :-)
20% of android devices, but definitely not 20% of any website's android traffic. the amount of web traffic that comes from those android phones is approximately 0 unless maybe you're in africa or china - the people who still have android 2.x phones aren't browsing the internet with them.
> the people who still have android 2.x phones aren't browsing the internet with them.
Not true. Only devices with regular Google Play store access get shown in those statistics.
The 20% are users with at least regular Wi-Fi access.
Not true. Only devices with regular Google Play store access get shown in those statistics.
The 20% are users with at least regular Wi-Fi access.
But did it drop to zero? Are you willing to serve those people a big scary error message?
it's definitely not zero. as for whether or not i'm willing to serve those people a big scary error message, i'm not sure yet. It's something we're actually going to have to come to a decision on in the next couple weeks though, this isn't a hypothetical for me.
a lot of my traffic is repeat, so we'll probably do a good campaign to push users off IE8 this fall and officially declare it unsupported in Nov/Dec.
a lot of my traffic is repeat, so we'll probably do a good campaign to push users off IE8 this fall and officially declare it unsupported in Nov/Dec.
Yeah, I didn't mean for that to come off as flip. We struggle with it too. Unfortunately we've still got 3 or 4 percent IE/XP on some sites, which feels like a lot to lose.
Perhaps more people would be more inclined to get nudged by Google in this direction if Google got in the CA game and sold certificates themselves, 2048 bit, right on Google Play, Chrome Optimized certs, NFC and QR code-enabled. How about that?
Some webmasters say they have "just a content site", like a blog, and that doesn't need to be secured. That misses out two immediate benefits you get as a site owner:
1. Data integrity: only by serving securely can you guarantee that someone is not altering how your content is received by your users. How many times have you accessed a site on an open network or from a hotel and got unexpected ads? This is a very visible manifestation of the issue, but it can be much more subtle.
2. Authentication: How can users trust that the site is really the one it says it is? Imagine you're a content site that gives financial or medical advice. If I operated such a site, I'd really want to tell my readers that the advice they're reading is genuinely mine and not someone else pretending to be me.
On top of these, your users get obvious (and not-so-obvious) benefits. Myself and fellow Googler and HNer Ilya Grigorik did a talk at Google I/O a few weeks ago that talks about these and a lot more in great detail:
https://www.youtube.com/watch?v=cBhZ6S0PFCY