21 ms·
Chrome 56 will mark HTTP pages with password fields as non-secure
- vladootz 10y agoI know the article is older, but it's January 2017, just a reminde. The message will appear in the address bar.
- foota 10y agoPm - "why is this page insecure" Developer - "chrome labels password fields as insecure over http" Pm - "what if it wasn't a password field"
- bsimpson 10y agoDon't you need to use type = "password" to get the -for-every-character treatment? I suppose you could implement your own (e.g. type = "text" with an onKeyDown listener that cached each keystroke and inserted a into the field), but that sounds like a terrible solution in so many ways. I would think the laziest possible way to workaround this would be to use a CDN like Cloudflare to proxy all traffic to your site. Looks like they have a service called Flexible SSL that terminates HTTPS at the CDN, and sends unencrypted traffic to your backend: https://www.cloudflare.com/ssl/ https://www.cloudflare.com/ssl/
- UnoriginalGuy 10y agoThat's literally what my router's login page does. It is a text box but has JavaScript which converts each non-* character into a * character and stores the actual value in a JS variable. Why? They added a "Show Password" radio and I guess they figured this hack made more sense than simply using JS to update the DOM to turn it from a type password to a type text.
- JoshTriplett 10y agoMy previous router did this to obscure password length, by inserting three stars into the field for every character typed. Which completely broke browser password managers, and the ability to paste the password.
- deleted 10y ago[deleted]
- duskwuff 10y agoIIRC, changing the 'type' of an input doesn't (or, at least, didn't) work in some browsers.
- guscost 10y ago> an onKeyDown listener that cached each keystroke and inserted a into the field... sounds like a terrible solution in so many ways. For anyone who is wondering what these ways are, here are a couple: 1) Backspace is a crufty special case 2) What happens when someone highlights text in the input box and types over it?
- skybrian 10y agoCodeMirror has figured this out. When you type it's actually into a hidden input, and it updates a separate display. Reimplementing CodeMirror (including highlighting, etc) is hard enough that most web developers probably can't do it. But it only takes one person to create a library.
- dTal 10y agoMore broadly: a text input box is in fact a small but surprisingly comprehensive text editor. It supports a cursor with insert, delete, and overstrike; highlighting, undo/redo, cut/copy/paste; and shortcut keys for all that. It supports every keyboard layout and every input method. It obeys standardized focus rules. It's even got word wrap and spell checkers these days. So, you want to go your own way? How much of that do you need to reimplement? And how confident are you that the subset you choose doesn't completely ignore some vital use case you forgot about? You certainly can't get away with just wiring keystrokes to a field.
- eru 10y agoYou can: you'll just get a buggy half-assed implementation. In a corporate envirnonment with bad politics, that might still be the only way to go. (Apart from quitting.)
- paulddraper 10y ago> onKeyDown Right-click paste from my password manager, and it doesn't work. Thanks. --- This idea is terrible in general, but if you do, against all that is holy, implement it, please, please use onInput.
- brak1 10y agoalso type='password' don't get their submitted values suggested for the autocomplete thing in broswers.
- Klathmon 10y agoYou can avoid this by using `autocomplete='off'`. Most browsers will still allow you to autocomplete the field because many were abusing that attribute, but they won't save what you put in it. It's still a horrible idea, but it'd work.
- dheera 10y agoA few solutions: - Create a font such that every character shows up as a * and use it for a text input. - make the input field use white text on a white background using a fixed-width font, monitor length, and display the correct number of *'s above it using a div. - implement the text box ground up from scratch using div's and JS, like google docs does. - implement a HTTPS password field in an iframe and communicate with it over post messages.
- Moru 10y agoBut what do you do when you have a page with form data that isn't sensitive and has no password on it and the users can't care less about the content of the form but chrome still warns about unsecure page?
- kevin_thibedeau 10y agoWhy would such a form need a password field?
- Moru 10y agoWell, that is the whole point I'm trying to make. Why does chrome think I'm using a password on the page when there is no password? Anyway, Chrome will mark all http as insecure sooner or later so will just have to force https on all connections... There seems to be many people with similar problems of false positives for nonexistant passwords so I guess it's a bug.
- Piskvorrr 10y agoWell...HTTP is insecure. That's what S in HTTPS stands for.
- comex 10y agoI haven't heard of this bug, but regarding the decision to mark all HTTP as insecure: Remember, HTTPS isn't just for security, but also privacy. And even if your site is such that there is no privacy advantage in hiding the exact URL you visited (as opposed to the hostname, which unfortunately must leak for now), even if there are no cookies sent to your site, or to any iframes it uses, which can be used for identification or profiling… Even then, there are the benefits that only accrue if a user's entire browsing session is HTTP-free, including hiding the user agent from a network attacker and preventing injection of everything from tracking cookies to DDOS scripts (China's Great Cannon) to zero-day attacks.
- PretzelFisch 10y agoyou can have a hidden text input and use * in the visible one, then just use javascript to push the real text into the hidden field. but the pm would probably be fine showing the password in plain text, since the threat of a visible password is low<sarcasm/>...
- dawnerd 10y agoI've noticed a lot of sites default to "show password" with a toggle so it wouldn't be insane to think they'd opt for plaintext the whole way.
- barnacs 10y ago> I would think the laziest possible way to workaround this would be to use a CDN like Cloudflare to proxy all traffic to your site. Interesting. Where are all these warnings when a CDN man in the middle attacks your connection? Or when google gets to access all the email communication of gmail users? Or when ad networks track you all around the web?
- djs070 10y agoIIRC, type=password also prevents copying saved input to clipboard
- nodesocket 10y ago+1 for using CloudFlare. I just deployed the front-end website for my new startup (https://elasticbyte.net https://elasticbyte.net) using Google Cloud Storage (like S3) and CloudFlare for custom SSL. CloudFlare also allows me utilize CNAME flattening, so the the root record for my domain simply points to c.storage.googleapis.com.
- 1qaz2wsx3edc 10y agoDeveloper - "any could see the password..." Pm - "put one of them modal over it" Developer - "but then how will anyone..." Pm - "we're switching to <completely different stack they heard about from someone in their uber last week>"
- AtheistOfFail 10y agoYay, plaintext input fields for passwords. /me opens a sake bottle.
- brettz 10y agoSo accurate. We had this exact discussion. Going to go with insecure warnings until we get https up shortly. For those wondering you can mask a normal text field in css input { -webkit-text-security: disc; }.
- mappu 10y agoMy colleague used a custom web font where every glyph was replaced with a filled circle. Better browser compatibility, you know. Although our reason was actually to do with password managers. At $DAYJOB we have a CRM/ERP system with lots of password fields for other entities (not the current cookie user). It's increasingly difficult to opt out of browser autofill, and LastPass in particular was corrupting password data in the system whenever forms were submitted.
- fdsaaf 10y ago> It's increasingly difficult to opt out of browser autofill Good. I hope browsers autodetect these web font tricks and pop up similar warnings. I can't stand when some random website make thinks it can do a better job of credential security than major browser makers.
- Symbiote 10y agoI think the point is more like an HR administrator who opens a web page, containing an employee's details. They need to update the employee's home phone number, but their password manager dumps the HR administrator's password into the "Set new password" field, which is therefore overwritten.
- icebraining 10y agoSo don't put the "set new password" field right in the employee's details page, use an extra page or popup for that.
- mappu 10y ago
- ranveeraggarwal 10y agoPm - "why can't you use some JavaScript to hide this?" Developer - "..."
- dawnerd 10y agoThe correct answer is always "IE doesn't support it"
- ranveeraggarwal 10y agoGood point. We use the Windows stack :D
- bradgessler 10y agoIt would be better if form is served up via HTTP it gets marked as insecure.
- nolite 10y agoThe Law of Unintended Consequences at its best
- JustSomeNobody 10y agoI laughed out loud. Then started crying. Sigh. Our industry in a nutshell.
- Aldo_MX 10y agoI've seen that: https://www.bancomer.com/index.jsp https://www.bancomer.com/index.jsp Click "Acceso a clientes" and write numbers.
- eru 10y agoI don't even get to that badness: the browser needs to accept third-party cookies first. (I wonder what badness is behind all there.)
- fdsaaf 10y agoI'm glad I'm not the only developer who can't stand the kind of PM you describe.
- madeofpalk 10y agoPm - "why is this page insecure" Developer - "chrome labels password fields as insecure over http" Pm - "what if it wasn't http?"
- technion 10y agoWell I'm fairly certain it will go like this for me. Pm - "why is this page insecure" Developer - "chrome labels password fields as insecure over http" Pm - "we'll need to setup encryption. It will need to be FIPS-140 certified or it's not secure" Developer - "But you didn't care when there was no encryption" Pm - "We don't need to certify plaintext, that should be obvious. You need to learn more about security".
- morenoh149 10y agowhere do you work
- msimpson 10y agoThey seem to be a government contractor.
- theandrewbailey 10y agoDeveloper - "FIPS-140 has been compromised by the NSA. We don't want government spies in our servers."
- drzaiusapelord 10y agoPm - "why is this page insecure" Developer - "chrome labels password fields as insecure over http" Pm - "what if it wasn't a password field" Pm - "If its important enough to hide, its important enough to stop from being intercepted. Think social security numbers, PINs, tokens, drivers license numbers, etc. Why aren't we encrypting things that matter?"
- lucideer 10y agoFirefox has started to do this recently and it's been fantastically informative and helpful. It's the one new browser feature I never really considered wanting/needing before, that's really stood out to me as being incredibly valuable since I've started to see the warnings pop up.
- johndoe4589 10y agoKinda like how your antivirus tells you about how the formidable threats it saved your ass from today? Or like "did you know your house COULD have been ransacked today, but it didn't happen!!" Now all my users are going to hear that my site is insecure, when nothing at all changed. How long ago did they announce that? I think just a couple months? They should have announced this much sooner. It's going to hit me hard as my site is pretty niche and driving even more people away is the last thing I hoped for :( My shared hosting doesn't offer Let's Encrypt, and makes me pay to "install" a free certificate anyway. So I have to move everything to a different web host.
- michaelmior 10y agoIt may not be an option for you, but you could consider using a free proxy service such as Cloudflare.
- bphogan 10y agoSeconding this, because this is what I do for one of my projects.
- angry-hacker 10y agoWhich is not really a true https, depends on your view, but the flexible plan is not encrypted to the source server as one might expect. But if it's possible to set up things that way, it is https, i guess.
- bsuh 10y agoWith the caveat that while the password will be encrypted from the browser to Cloudflare, it will still be transmitted as plain text from Cloudflare to your own server if your server doesn't support HTTPS. So it's an improvement but not entirely a fix.
- myf01d 10y agoAdvancing HTTPS is one of a few good things Google made in the recent years. Thanks Google.
- vortico 10y agoIt's one of the few things they do that I can't find a reason they would be financially motivated to do so, other than increase developers' opinions about the company as a whole, which is a good thing for all.
- clairity 10y agogoogle competes with the likes verizon, comcast and at&t, and the data google gathers on you is very valuable. why would they want to share that data with the line operators for free? sorry to say, but https is not an altruistic move by google.
- jjawssd 10y agounderrated comment
- phire 10y agoAnd since a large majority of websites import either google analytics or google words, google gets all the infomation for https websites anyway. I'm willing to bet that the terms and conditions for both services allow google to reuse use the analytics infomation.
- vortico 10y agoI can understand why they would want to convince everyone to use HTTPS to restrict access of your data from their competitors, but it limits the data they can collect as well. HTTPS has stricter cross domain policies so their ads would gather less information and their Fiber ISP would no longer be able to collect data by tapping connections. But on average, I think you're right that HTTPS would restrict more of your data to Verizon etc than to Google.
- a3_nm 10y ago
- jvehent 10y agoFirefox has a similar feature enabled in dev edition: https://blog.mozilla.org/security/2017/01/20/communicating-the-dangers-of-non-secure-http/ https://blog.mozilla.org/security/2017/01/20/communicating-t...
- bifurcation 10y agoActually, it's in Beta now, and will be shipping to Firefox release channel users on Monday or Tuesday.
- ams6110 10y agoIt should just label HTTP pages as "not secure", full stop. Because they aren't secure. Or at least, any page with a form. Never mind if it's a password field or not.
- sqren 10y ago"Studies show [...] that users become blind to warnings that occur too frequently." So right now it would be counterproductive to mark all http pages as "not secure". But it's the long-term goal.
- jakobdabo 10y agoThe majority of the big sites that people use (Google, GMail, Youtube, Facebook, Reddit, NYT, WaPo, etc.) are already being served using HTTPS. I think if a couple of HTTP sites an average user still browses start showing these warnings they will notice them. And what matters, the owners of those websites will notice them and will ask their "IT guy" hey "why our website is marked as insecure? I want a green lock like Gmail has".
- threeseed 10y agoAnd that IT guy will go well there isn't anything I can do about it. The user will then forever ignore it (because they like that web site) and the whole exercise is wasted.
- johndoe4589 10y agoTheir IT guy?? There are gazillions of people like me who have a blog, or some small project that has a small audience of tens to just a few thousand users. All these people now have to fork for SSL, or have to move everything to a different shared hosting that supports Let's Encrypt.
- the_duke 10y agoRight now, you can just put Cloudfront in between. It's free, and takes maybe 5 minutes to sign up and adjust your DNS entries. Of course relying on a provider that might cancel the free plan at any time is not ideal, but worst case you just have to revert your DNS and it's done.
- ktta 10y agoMods, can we please get the "?m=1" part of the url removed? I think the current link is for mobile.
- skybrian 10y agoBut that would make it worse for people on mobile.
- ChristianBundy 10y agoMan, someone should really invent a way to make webpages respond to the dimensions and capabilities of the user's device.
- amiga-workbench 10y agoPlain, un-styled HTML?
- nickik 10y agoStop making up technology
- AbrahamParangi 10y agoIf the page is loaded on a mobile device you'll get the mobile version anyway.
- Elrac 10y ago"Thanks, Captain Obvious!" Is there an option to turn this off, for those of us who feel we need it like a hole in the head?
- meta_AU 10y agoWhat should be done for routers and printers that are accessed by their IP address?
- infogulch 10y agoWell, they are insecure.
- witty_username 10y agoFor example, I've given the WPA2 password to many people; and that can be used to snoop on it passively (there's no forward security). Modems are anyways way more insecure due to the default password being admin or 123456, etc. And many are accessible from the public internet. I think my modem got hacked due to that (I saw some login attempts a little before the DNS got changed causing Youtube to stop working).
- joombaga 10y agoContinue to use them normally. What do you think needs to change?
- deleted 10y ago[deleted]
- nsgi 10y agoThe best solution is for them to be accessed through a publicly registered hostname e.g. https://router0123.netgear.com https://router0123.netgear.com (that would only resolve locally). They could provision certificates for themselves using the Let's Encrypt DNS challenge.
- rectangletangle 10y agoAbout time, this is an excellent feature.
- rectangletangle 10y agoAbout time, this is an excellent feature.
- polygot 10y agoI hope they do this for CC numbers too, because I know of a website I had to use that passed your Name, address, CC number, CC exp, amount; the whole shebang over plain ol' http to do a payment shudder.
- hk__2 10y agoThey do it for CC numbers too, as outlined in their page for developpers [1]: > To ensure that the Not Secure warning is not displayed for your pages, you must ensure that all forms containing <input type=password> elements and any inputs detected as credit card fields are present only on secure origins. [1]: https://developers.google.com/web/updates/2016/10/avoid-not-secure-warn https://developers.google.com/web/updates/2016/10/avoid-not-...
- kuschku 10y agoDo they also do it for IBAN?
- icebraining 10y agoThe people who decided that the new SEPA payments should include a way for creditors to take people's money using just public information and their signature should be fired. It's like they learned nothing from the billions of dollars wasted from fraud in the credit card system. Payments should always start after an explicit order by the payer to their bank, not just having the payee say "trust me, they totally want me to have this money".
- kuschku 10y agoWell, luckily, there is! SEPA is a bi-directional protocol – if you try to take money from a bank account, the bank can say "nope", and the transaction can fail (with the person trying to pull the money taking the loss). As banks allow you to configure this – mine allows me to disallow all direct debit, or disallow foreign direct debit, or only allow it from specific companies – this is not an issue.
- daryltucker 10y agoI'd like to see this with Adobe Flash and third party scripts. (Pandora!)
- deleted 10y ago[deleted]
- deleted 10y ago[deleted]
- SilasX 10y agoStupid question: Is the warning going to show up for localhost i.e. using chrome to see the local dev version of your website?
- tonymet 10y agosee chrome://flags to disable security warnings on localhost -- great for development
- petecooper 10y agoThat's…actually quite smart, I wasn't aware of that. Thanks -- this has solved an ongoing problem I was having with a couple of clients.
- notatoad 10y agoit's weird that the warnings aren't disabled by default on chrome for localhost: it's officially classed as a "secure origin" https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features https://www.chromium.org/Home/chromium-security/prefer-secur...
- lucideer 10y agoIt has for me with the Firefox version of this, and based on my experience of it sofar, this is fine. For one, it's an obvious differentiator between my local copy and live, but secondly I also think local certs are something that we really need to find a way to make easier for devs to set up and test with.
- slrz 10y agoWhere do you see the issue? Creating a certificate that no one else has to trust seems pretty easy already.
- lucideer 10y agoI guess a part of this is inconsistency between development environments as well, but generally speaking, while not completely impossible, the dev user experience is just that bit more fiddly. For a prod server, the process can be as simple as (Ubuntu/Apache being a common setup): apt-get install letsencrypt && certbot --apache Or more generally: $PKGMGR install certbot && certbot certonly For dev, you need to either select and install an SSL library, generate snakeoil certs and install them into each vhost you use, and thereafter go through every varying and occasionally unsurpassable browser warnings about unverified certs, OR - much, much more complex - install and maintain a boulder setup. Given the above, most devs will continue to take the chrome://flags easy way out, which doesn't really allow proper testing of a HTTPS setup locally.
- ai_ja_nai 10y agoThank God
- idbehold 10y agoHow does it handle password inputs that are added to the page with JS?
- throwaway6845 10y agoCountdown until a JS extension that takes a normal <input> field and uses • characters to make it look like a password field without tripping Chrome's detector...
- dawnerd 10y agoCan we just ban inputs being manipulated on input? It's really annoying for custom implemented types like phone numbers that do the '(___) ___-____'. Half the time it seems they break if you mess up.
- tomschlick 10y agoI'd be in favor of banning input manipulation but adding custom fields like phone which would accept regex formatters.
- lucideer 10y agoBrowsers already support that. Good look convincing managers/clients/designers that they're sufficient on their own though. The real problem is UI. Most of these plugins are changing the UI of forms to something that looks fancier (and more consistent) than the defaults.
- dawnerd 10y agoThere really does need to be a better way to style inputs. It's all over the place now. Hell, just making `type=search` look the same across browsers isn't as straight forward as it should be.
- wongarsu 10y agoYeah, but if you want something slighlty different that isn't solved by one of the existing input field types you would be completely out of luck. And even if what you need is in the HTML spec you might be out of luck. Firefox is only adding support for date inputs sometime this year (my estimate) [1]. 1: https://wiki.mozilla.org/TPE_DOM/Date_time_input_types#Roadmap https://wiki.mozilla.org/TPE_DOM/Date_time_input_types#Roadm...
- clamprecht 10y agoWhat if the <form> submits to an https page but the page is served up on an http page? The form submission will be secure, correct? Will Chrome still mark as insecure?
- dbbk 10y agoThe form submission is only half the issue. If the http page gets compromised the malicious party could simply read the contents of the password input.
- clamprecht 10y agothanks
- waskosky 10y agoTechnically it would be possible to use JavaScript to intercept the onSubmit event of such a form, and alter the submission location or send the data insecurely wherever you want with AJAX, completely ignoring the destination action that came with the initial HTML. This is one of the reasons people have needed to use forms within secure iFrames to circumvent PCI Compliance requirements when sending credit card numbers.
- gregmac 10y agoI was also thinking of the opposite: submitting from an https-loaded page to an http page. I can't imagine why any application would do this (other than by mistake), but it would ideally be flagged as insecure as well.
- Wilya 10y agoIt's already the case most of the time. If you submit via a plain form (without js), you get the (old) "This page is encrypted, but the information you submitted will be sent unencrypted" message. If you submit via an XMLHttpRequest, it should be blocked as Mixed Content.
- johndoe4589 10y ago> A substantial portion of web traffic has transitioned to HTTPS so far, and HTTPS usage is consistently increasing. We recently hit a milestone with more than half of Chrome desktop page loads now served over HTTPS Well OBVIOUSLY when the traffic is increasingly going to the same top ten sites like Faceboo, Twitter and Co.
- alex_dev 10y agoI've been paying rent with www.rentpayment.com which unfortunately serves up their home page with multiple logins over http. Naturally, emails and tweets to their support go ignored. Maybe they'll finally respond after more people ask them why they're "non-secure".
- metakermit 10y agoI wrote a short article on this topic with approaches for less tech savvy folks to set up HTTPS: https://medium.com/punk-rock-dev/https-new-year-avoid-the-not-secure-label-eefb99879980#.io1rzm367 https://medium.com/punk-rock-dev/https-new-year-avoid-the-no...
- malikNF 10y agoThis is such a dumb idea on google's part (and mozilla's) because people are now going to program dumb workarounds for this. Google seriously has to stop trying to police the god damn web.
- derimagia 10y agoWith free ways to encrypt web coming out, you really have no excuse to not use https for login forms. People should be informed.
- malikNF 10y agoThis is not the right way to educate people. This is a sort of like shaming someone in to doing something. Many small companies are going have an impact thanks to this. There are many companies I have personally witnessed that use a direct IP to access web based solutions to their inhouse software, how are these people supposed to get a ssl cert. We need to educate people, not shame them in to doing the things big google wants from them.
- lucideer 10y agoIn house software isn't an issue: internal staff are not going to go away and use a competitor if they see a security warning. They're just going to learn to live with it. As for saying "small companies", I really don't see how this has an impact on smaller companies more than others. Certs are free, and trivial to install for any public domain (others in the comments above have mentioned valid problems with non-public domains, which remain to be solved but they are somewhat less affected by this feature anyway).
- icebraining 10y agoA web developer or website manager has a responsibility to be informed. SSL/TLS is not a new development, it's been around for 20 years, and recommended for login forms for at least a decade. At this point, what exactly should they do? Send people to knock on the doors of every business with a site?
- 10y ago
- ifelsehow 10y agoWill this also apply to data URIs? Thinking of the recent data URI phishing exploits [1] [1]: https://www.wordfence.com/blog/2017/01/gmail-phishing-data-uri/ https://www.wordfence.com/blog/2017/01/gmail-phishing-data-u...
- beebeebush 10y agoGoogle gives penalty, hide search results, push you to "controlled" ghetto zones. But still some people call this evolution ?
- tehlike 10y agoWhat happens if the page is insecure, but the attacker places an iframe in the page with HTTPS url, which then tricks the user into sending their credentials (unsuspecting users will think they are logging into the site).
- joshstrange 10y agoI'm not sure that really fit what is changing here... If the forum is submitted it's going over https even if the iframe is on an http page. If an attacker has the ability to add code (iframe or other) to your site you've already lost.
- tehlike 10y agothat's exactly my point. I am hoping/assuming chrome would notify the user about this as well.
- joshstrange 10y agoWhy? IIRC cross-origin will prevent the http page from reaching into the https iframe and furthermore the password is being sent over https so google doesn't really care.
- tehlike 10y agoBut since top lev is insecure, an attacker could inject a legit looking form whose destination is set to steal passwords.
- joshstrange 10y agoI guess it depends on the attack this is supposed to stop. This change does prevent sniffing of passwords and protects them while in transit but no, it doesn't prevent MitM attacks. That said google plans on marking all HTTP pages as "Non-Secure" in the not-too-distant future which will help warn against the potential for MitM.
- HappyTypist 10y agoI'm in an A/B test group where all pages are marked either green 'Secure' or red 'Not Secure', password or not. I like it.
- ryandrake 10y agoNot a Chrome user, but this is a great feature, and is at least moving things in the right direction. Really they should go farther though. The UI treatment is almost un-noticable, even if they went with the "red triangle" version. How about a red-background interstitial page or a modal with a clear "Get Me Out Of Here" and "I Know What I'm Doing" choice for the user? And for all those "small businesses" that are going to get affected by this? It's hard to muster up much sympathy at this point. It's 2017, and you're still horsing around with vanilla http?
- iceman_w 10y agoInsecure websites could get around this by not marking the fields as password fields but using javascript to make them appear so to the user.
- KirinDave 10y agoI've got to say though, that this is a wee bit frustrating as a developer. SSL libraries are terrible, bug ridden, hard to work with, and there are huge sacrifices using a pass-through proxy to offer SSL. The brittleness of SSL libraries manifests not just in the form of security exploits, but also in the form of delaying the next generation of HTTP technology. Node doesn't support natively support HTTP/2 due to HTTP2 fitting issues [https://github.com/nodejs/NG/issues/8 https://github.com/nodejs/NG/issues/8]. Jetty was delayed for Java SLL changes. Same with Go. If Google wants to make the whole web secure? That's great. But we also need to work on making it simple to secure. So much research goes into novel ciphers and optimal ways to defeat timing attacks, and etc etc, but the spike in complexity means that we're reaching a point where almost no individual or group can approach a correct implementation. It worries me that we're approaching a point where we're utterly dependent on a security standard no one can understand.
- stanleydrew 10y agoAs with most things, progress isn't clean or easy. Shifts in policy or practice cause disruptions, and then people adjust. The world is a dynamic place. Software is no exception. SSL libraries will get better if they get used more. The developers will make them better. Or if they can't, we'll find a solution that works. The question is whether the benefit of the disruption outweighs the cost. Browser-makers decided that their users' needs were best served by this change. Mozilla and Google have been telegraphing their actions in this direction for years. They have attempted to make a responsible and gradual transition, and to a large extent have succeeded. Every once in awhile though, a break needs to be made and some folks will get left behind until they adapt, or don't.
- KirinDave 10y ago> SSL libraries will get better if they get used more. The developers will make them better. Or if they can't, we'll find a solution that works. I keep hearing this, but failing to see it. Since OpenSSL's inception.
- 10y ago
- LogicX 10y agoIt's great that Google wants to move more sites to https, and I'm in support of this, but it also creates challenges for security vendors such as myself. Currently DNSFilter and others Man in the Middle traffic destined for sites our customers have decided to block. This works great for http, but not https, as certificate warnings are presented. The standard work around is arguably less secure: adding a third-party CA to all end-points. This can still present problems with HSTS and certificate pinning. I'd like to work with Google to create a standard where vendors can either be on a whitelist or have new recognized SSL cert fields, not to MITM traffic, but just to present users with a friendlier message explaining whats happening, and providing a separate https:// https:// url to visit for information from the vendor about the block. Implementing such a standard in browsers would further increase user security, and provide a viable method for filtering on guest networks where there is no end-point access.
- scrollaway 10y agoRemoving insecure HTTP altogether is the road Google is taking. That should make this a non-issue.
- toast0 10y agoHow does removing HTTP solve the issue presented: When actively interrupting an HTTPS connection as a network element, there is no way to provide information to the user about the reason for the interruption or steps the user could take to prevent the interruption. This can be done with HTTP, where a filtering proxy could show a page 'our software thinks this page violates company policies, but click here to override or contact IT to fix', or see also captive portals. Maybe the right answer is simply there's no reasonable way to handle this use case in a secure manner, but taking away an established use is a real issue.
- thowfaraway 10y agoSo if we have an http page with a password field that posts via https, it will be marked non-secure?
- detaro 10y agoyes.
- netheril96 10y agoYes, because it is insecure.
- kyledrake 10y agoThere should be an HTTP Header (or a CSP directive) to allow servers to set sites as "Not Secure" manually. That would help a lot of people dealing with phishing attacks on web hosts. It would function in the same way - if Chrome detects CC/password forms, it labels the site as Not Secure.
- no_wizard 10y agoAlright, for what its worth everyone, if you haven't seen this already, here it is! The Cert bot from EFF! Get that HTTPS motor running. This really does make it easy. https://certbot.eff.org/docs/intro.html https://certbot.eff.org/docs/intro.html
- deleted 10y ago[deleted]
- agumonkey 10y agoDo they send a letsencrypt notice to these domains ? notifying users is awesome, helping "late" hosts into HTTPS would be perfection.
- stilliard 10y agoWorking on a new community site to help people move to HTTPS: https://blog.movingtohttps.com/dedicated-to-simplifying-the-move-from-http-to-https-97d80b08e4dd https://blog.movingtohttps.com/dedicated-to-simplifying-the-...
- Sarkie 10y agoI hope me trying to push this on G+ and Twitter for years helped. This was always my first install on a new Chrome. https://chrome.google.com/webstore/detail/unsecure-login-notifier/ledomejmbiemgdfiekmhoheabhonihmi https://chrome.google.com/webstore/detail/unsecure-login-not...
- egberts1 10y agoNeeds to start blocking form fields that have no corresponding input text box because...these unused fields still get autofilled with cached but personalized info.
- no_wizard 10y agoI'm going to go ahead and make another shameless plug, since a lot of folks who are hesitant about this new HTTPS stack are worried about deployment, and thats for the fantastic folks over at Caddy. They make an Apache/Nginx alternative that has built in letsencrypt renewal support and automatically encrypts your site by default and serves over https/2. https://caddyserver.com/ https://caddyserver.com/ I am not an affiliated developer, but I am a user, and have recommended this to others as well, its a solid product.
- ZeroClickOk 10y agoI think the title must be "Chrome 56 will mark non-HTTPS pages with password fields as non-secure"
- godDLL 10y agoWhat about services like Sellfy that let you add a button to your site's pages, that loads a shopping iframe? Will it change the indicator when the iframe appears after a user clicks the Buy button?
- cr0sh 10y agoUltimately, how is this plan by Google going to affect sites that are hosted on a virtual server hosting plan? For instance, I have a website hosted at Hurricane Electric on a virtual server plan. I've had hosting there for well over a decade. I like their service, the virtual host works well for most of my needs. There are two areas where it doesn't work, though (AFAIK): 1. I can't run a pure NodeJS website. 2. I can't set up HTTPS. Number one isn't relevant to this discussion; but as far as I know, the second one is a big deal. There isn't any way (AFAIK) to host multiple virtual servers each with their own certificate. So right now (well, with the release of v56 of Chrome) - if you have a Wordpress site or something on a virtual host that has a login - it's going to show something that says "unsecure" for the login/password form. Honestly, I am fine with that. My own site isn't a Wordpress site, but I do have a login/password box on the site, and having it show that it is insecure is not a big deal to me. While there isn't much or anything I can do about it, I do understand and support the reasoning. But... ...in the future, they want to mark -all- non-HTTPS sites as "insecure" - regardless of what the site does, presumably. It could just be a collection of static html pages (no javascript, no forms, nothing special), and it will still be marked as "insecure"? Does this sound reasonable? Suddenly, all of these pages will be deemed pariahs and non-trusted because they choose to use non-encrypted means of presentation? Is there any solution to this, as it stands? Or are all of us with virtual hosting solutions going to have to migrate to some cloud-based server solution, with it's own IP, then obtain our own certificate (easier today, I know - and cheap to free, too) - just to get around this? Is this the end of virtual private server hosting (or is it going to be relegated to third-tier)? I don't currently know what if anything Hurricane Electric plans to do regarding these changes. I don't want to move to another hosting provider if I can avoid it (while HE isn't the cheapest for what you get, they are nice in that they assume you know wtf you are doing - your hosting is basically access to the server via ssh and sftp - so you better know how to admin and set things up via a shell, because they aren't going to hold your hand). I'm thinking I should send an email to them to ask them what they're planning to do - if anything.
- Vendan 10y agoIf you are talking about this service: http://he.net/web_hosting.html http://he.net/web_hosting.html, then it's supported SSL since 2013, at least, with a simple admin panel to set it up... If it's an actual VPS, then SSL is fully on you, and trivial to set up with common stacks and LE.
- ArlenBales 10y agoI'd go a leap further and change the background color of the address bar to red if it's a non-HTTPS page. No excuse for any site to be HTTP in 2017, especially with LetsEncrypt. Your host doesn't allow LetsEncrypt? They need to get with the times, or you need to switch hosts. (Why would you want to use a host that doesn't see the value of HTTPS?)
- hughes 10y agoAs stated in the article, that is in fact the long term goal for treatment of the Google Chrome address bar.
- PaulBurke 10y agoI must say that this is the essential step that has been taken by Google in order to protect user’s information in the latest version of Google Chrome56. There are the number of hacks and vulnerabilities and the numbers have been increasing, and there the number of audience or people, who are not aware of this essential security. Hackers may breach their identities, including user_id, password, financial details, banking information, etc... Certainly, addressing a user about “Not Secure” page with little warning in the address bar will help them before they put their valuable information in a website. It’s prerequisite now that every website must have encryption to retain the interest of the user in a website. So, such steps from Google will make the user aware of their basic security needs.