Shared publicly  - 
From the end of January with Chrome 56, Chrome will mark HTTP sites that collect passwords or credit cards as non-secure. Enabling HTTPS on your whole site is important, but if your site collects passwords, payment info, or any other personal information, it's critical to use HTTPS. Without HTTPS, bad actors can steal this confidential data. #NoHacked
Read more about the update to Chrome in January and how you can enable HTTPS for your site→

Learn more about why enabling HTTPS on your site is important→
Jonathan Garbee's profile photoAmber Woods's profile photoSalvatore Capolupo's profile photoBryan Dehn's profile photo
Will this have any potential impact on PPC as well?
+Google Webmasters: Hello. Could you please specify when "end of January" exactly is? Thank you! 
Will it trigger for forms with just "email-id", no password or payment details?
+adam​ We don't know an exact date. The Chrome team handles deployment of that. Just assume the latter half of the month at some point. If this change affects your sites then it isn't something to delay on because of a release date.
The changes are supported in version 56 or later of the Chrome browser. Why not from old browsers?
+SozcukCevir Because the code changes are landing with M56. It is very difficult to backport certain patches and there is little reason to since Chrome auto-updates.
Couple of questions
1. By "sites that collect passwords or credit cards", do you mean the entire website or just the pages that collect the info? For example, only the registration and login page are required to be https

2. Some websites have universal login bar at the top. When someone is logging in via the bar, the information is redirected to https secured page. Do we have to make sure all pages that have this login bar to be https as well?
only part of our website is on https (the pages that collect sensitive information). will this result in our entire website being marked as non-secure? even tho we are protecting ppls data whenever it's entered
+Amber Woods This change should not affect that case. However, you aren't really protecting your users as going back to HTTP introduces the same man-in-the-middle vulnerabilities on their access credentials. For example, the Firesheep attack on Facebook a few years ago.

If you have HTTPS for important pages, then it should be turned on everywhere and forced to protect your users data fully.
+Eben Haezer Saputra If the page is HTTP but he form's action is to HTTPS, then it is still insecure as the credentials are input on a non-secure connection. That is exactly what this update is targeting for certain critical cases.

This update should just target pages in which the sensitive input fields are displayed on an insecure connection.

If you have HTTPS for some part of the sites actions, then it should be enabled by default everywhere.
is this still notified for ordinary pages i.e read-only pages of a blog? do we really need HTTPS on every single page and not just for login / payment ones?
+Salvatore Capolupo I think this is pretty straight forward: If you collect login credentials or CC numbers on any given page, it has to be over https.
"Eventually, we plan to label all HTTP pages as non-secure, and change the HTTP security indicator to the red triangle that we use for broken HTTPS...." - we have been warned!
+adam That part is straightforward. However the linked article says eventually every non-TLS site will be flagged, which understandably raises concern for those who don't work the nuts & bolts of encryption.
+Salvatore Capolupo Not yet, but yes, eventually.

Google's plan is to begin flagging certain sites at first for data processing issues, but ultimately warning users against ANY unencrypted site. It's actually good for the Internet community for everyone to become encrypted.

This is important not only for data security, but also for site identification and integrity. If your site is not secured by a certificate dedicated to your site, then a malicious middle man could pose as your site and serve incorrect information to visitors trying to reach you. Worse, they could change data as it passes from your site to the visitor's screen.

While this isn't necessarily a "national security" concern for pictures-of-my-dog-level posts, it does lend credibility to your site if you're encrypted.

Encryption is a bit intimidating but can be done with a little diligence and not much money. Many hosting providers can help, but probably for a fee. Look into it and get it rolling before it becomes a bigger issue--once the alert is raised on every insecure site, your visitors will wonder what you've done wrong...when you haven't done anything overtly wrong (besides neglecting this issue earlier of course). Good luck :)
+Jonathan Garbee my understanding is that going back to http on our site is not a vulnerability because we have a security cookie for every session..... while i do agree that it would be best to have https site-wide, that is not my decision to make :(
+Amber Woods How is the "security cookie" transmitted? If you go back to HTTP, then it is transferred in plain-text over the wire, which is not secure and can be intercepted easily by any man-in-the-middle.
+Jonathan Garbee tbh i dont know... this was the response i got from folks in I.T.:

On Session Start, a token will be issued, which is a random guid and will be stored as base64string in both session and a security cookie
On page preload event of each security page who only accessed by authenticated user,
will verify if the user is authenticated and compares token value between the security cookie and session too -> checking 2 conditions (machine and browser)
If user is NOT authenticated OR token value DOESN’T match, user will be redirected to login page after abandoning the session

1. token will be reissued on a new session start, login and logout
2. authenticated user have 15min lifespan before expired or logout
+Amber Woods Exactly, that isn't actually secure. The token can easily be intercepted in the middle and used by the attacker to act like they are the end client. The lifespan doesn't matter as the attack is actively in between the connection. New tokens on new sessions doesn't help either, as the new tokens are intercepted by the same man-in-the-middle. No matter how the id is obscured locally, it isn't relevant as a person in the middle has full access to see and then pass it along.
+Jonathan Garbee okay last question: i was told that as soon as a man in the middle person tries to access someones session, authentication would be denied because its not on the same machine/device... does that not work?
+Amber Woods No it doesn't. Because how is the device authorized? By the cookie. How is that cookie sent? In plain text. Which means, the attacker can intercept and re-use the cookie on behalf of the client. Your server will never know the end-user isn't the one connecting, because you'll still see the valid cookie.
+Bryan Dehn your point of view makes sense, of course, and this is an important step for any website involving i.e buying something.

But I was/am a little skeptic about making EVERY site with HTTPS, because i.e not all certificates are equally valid or "authoritative", not all SSL implementations are equally good (some are not updated and unsecure, for example).

This is a real problem and a valid reason for being some skeptic about this solution as generically "safe" and useful for anybody, and maybe will be understimated/misunderstood by the most of users, people that tipically do not really know nothing, or very little, about encryption.

Not very time ago, if you remember, users buy SSL because "it is good for SEO, Google said", and this is the critical point for me until now: are you getting SSL for the right reason?
+Salvatore Capolupo There are probably other factors which benefit Google, but I agree with them that the entire web should be encrypted,--and that it will help everyone once that's the case. Aside whether they're right or wrong of course is the fact that they have a popular browser--and they've decided that the clock is ticking. Also their search engine will likely favor sites that use encryption (probably the SEO thing you mention). Both are factors you and I can't influence.

They either gently remind us forever, or they must choose a cutoff date where they begin pushing toward the goal. I suppose whether one believes they've given us enough time will largely be determined by whether one is behind or complete on updating their sites. As for the different "levels" of security, the cost is insignificant to sites which move a lot of money--for the rest of us there are cheaper certificates.

I haven't seen anything to suggest they'll completely block visitors, but in the near future my personal blog will be labeled "NOT SECURE" by Google Chrome. I'll fix it soon, since I can't count on catching every visitor to explain the difference between "my site wasn't hacked" and "I merely haven't upgraded to SSL yet."
Add a comment...