Evolving Chrome's security indicators
blog.chromium.org
blog.chromium.org
https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...
You can also think of this as an issue for any IoT device that wants to serve a webpage.
Let's Encrypt doesn't cover this use case because it only provides certs for domains so every IoT device would need it's own domain or subdomain and that domain would need to be blessed in the list of domains that Let's Encrypt doesn't put limits on certs since you need a cert per device.
Some company making a product (for example Plex) can pay to run the dynamic DNS and partner with a CA but at the moment there is no free and easy way for some open source project to this.
I wish I knew how to make it happen. Get a giant grant like Let's Encrypt got or something to enable a solution. I'd love all my projects running local servers to be able to use HTTPS but at the moment it's way too painful.
Basically I just setup [acme-dns][1] on a VPS, pointed the relevant _acme-challenge domains at that server via a CNAME entry, and gave each device on my LAN an account on the acme-dns server so they can fulfill challenges at will.
Unfortunately as you said that's probably a little too complex for the average user, not to mention domains and VPSes aren't free. Probably wouldn't be too expensive to offer as a service of some kind though; I'm only spending $3.50/month total, and I'm sure my VPS could handle _much_ more traffic than it currently does just fulfilling acme challenges for my LAN.
(* yes, you could simply tolerate the insecurity warning if you're ok with not using more recent JS/CSS features. I imagine though the warnings will become more obnoxious and the amount of features you can't use will grow.)
(* yes, you can install your own root CA cert. For admin pages, this is even a reasonable thing to do - however, you'll need to do it on any machine that is expected to open your page. So say goodbye to raspberry pi media experiments or kiosk systems.)
DNS is well suited for allocating unique, memorable names to devices, but, as you said, it _does_ rely on third party services (registrars, at the very least) to operate. If we don't want to rely on third party services, we'll need to come up with an alternative to DNS that accomplishes the same goals.
The browser could still displays a warning once, "Warning! We can't determine whether we should trust this site. It claims to be [Such and such local service.] Would you like to trust this site? [Yes, temporarily], [Yes, permanantly (installs local certificate)], [No, get me out of here!]
Firefox already does something like this, but its wording is kind of vague, and the strong assumption from browser vendors seems to be CA or bust. The truth is, encryption is useful in some very common cases where a CA or a domain name is simply not feasible, and we need workarounds for those use cases that don't feel like a dirty hack for techies only.
Part of me wants to say that the solution is to just accept that it's not secure and the warning is valid, and services only available behind my firewall don't need to be accessed over https. but that doesn't help when browser vendors are also making new features only available on secure origins. How are you supposed to build a serviceworker to run on your local server when serviceworker only runs on secure origins and there's no way to secure a local origin?
I think the problem is few IoT devices (except maybe IP cameras and NAS) provide a webpage. Most provide an app and that app and device talk to the cloud not the device
I don't expect this of anything else in my life. Why in the world would I expect the web to be safe?
To be clear: the only thing this is assuring is that your connection is secure. Your content may not be. Hell, the web server may not be. There's no way a browser can know these things. And they're going to assure the user they're secure by default?
Lots of phishing sites use valid connections to trick you into giving your SSN, credit card, and other data. This is not safe or secure. But the browser is telling me it is.
All of these things happen with some frequency, sure, but I personally expect that they don't, which is why I'm disappointed and upset when they do happen.
And the fact that the browser can't assure any other security besides transport security on its end is exactly why it shouldn't be displaying an indicator saying "Secure," when all it means is "In this particular way, it is not insecure; for everything else I have no idea." If it knows it's insecure in a particular way, it should display a warning or possibly an error. If it doesn't, it's meaningless to claim "Secure." That's how the rest of the world works: the State Department gives you warnings about high-risk travel areas, but it doesn't say that any place is safe and crimes won't happen to you there.
(What do you do at restaurants - pay with cash? Insist on walking up to the PoS device?)
It’s a really quick indicator that I’ve either set something up right or not.
Also if I’m on chase.com and I don’t see a lock of any kind I’m going to NOPE out. And I’m a tech person.
Imagine explaining to my parents that after all this training to look for the lock they now shouldn’t look for the lock, but look for this red text instead.
Bad move.
It's grossly misleading and it needs to go.
I understand why they don't want to show "Secure" for websites that may have already been breached and lost your plaintext password. But I don't understand why they need to remove https and http from the URL. Is that really a big UX step forward? Or one backwards? Sometimes removing too many interface elements causes a regression in intuitiveness and good UX.
Unless they're preparing for the replacement of the HTTP protocol, and they don't want people to freak out when they see the new labels? That could explain it. But other than that, I don't see a good reason for eliminating HTTPS/HTTP from the URL.
That indicator just changes to either showing nothing (good) or showing an info icon with "Not Secure" (bad). There's still an indicator there, it's just different.
By default, if you're not typing in a form, Chrome will show no major eye-catching colour-differentiation between HTTP and HTTPS. That's a major regression in user security.
The post indicates that by the time the lock disappears ("eventually"), then all HTTP sites will be marked as not secure in red. In the meantime it's removing the "Secure" text with the lock and HTTP sites will get their "Not Secure" turned red when you type in a text field. Those seem like fine steps.
> That's a major regression in user security.
Turning red is more functionality than today, not less.
That is, there is now nothing eye-catchingly different between HTTP and non-HTTPs aside from a small monochrome marker; I think OP's concern is that that will get lost in people's vision next to the URL — they won't notice it. (And I somewhat agree w/ that.)
Firstly, I didn't say it was a regression in functionality, just a regression in security (due to the loss of contrast by removing the green).
Secondly, I actually did think the red was currently in place. I'm not a Chrome user, so it seems surprising to me that there is no warning currently in Chrome for entering data into insecure forms!? Firefox currently shows a red slash in the URL and an additional popup on the form input element itself which appears on focus rather than only after you've actually entered text. The Chrome team has such a good reputation for improving security on the web, so it seems bizarre to me they'd be behind on something so simple (and also not even attempting to catch up).
I think it'd make more sense to just make it red if there is any input options on the page at all.
Displaying the indicator on user input seems much more difficult to bypass.
Combine this with marking HTTP sites as explicitly insecure and I fail to see any downsides with this becoming the new norm (assuming other browsers follow suit).
I don't think this has meaningfully changed today vs the past as you suggest. HTTPS has been cheap and _relatively_ (for an engineer anyway) easy to implement if you cared for quite some time, even before the advent of free SSL certificate services like Letsencrypt etc.
I certainly don't agree that widespread SSL/HTTPS has somehow devalued the significance of the green padlock as you are implying - the level of security it implies for your in-transit requests is still much the same as it always was, it just happens to be used on many more sites than in days past.
For this argument to hold, we would need to assume that for some reason in the past, only "good actors" of some kind used HTTPS due to its expense/complexity, and therefore the padlock was somehow certifying their good intent. This has never been the case, and HTTPS (perhaps with some small degree of exception for the newer Extended Validation certs...) continues to really only indicate your requests will be encrypted in transit only.
There's no reason to maintain a "no-indicator" state, UX or otherwise. Keep the green lock for sites which implement it correctly.
peterwwillis makes a good point in another top level comment -- and my own research in securing products suggests much of the same, specifically that many users don't assume things are secure. I'd extend that argument by stating most users don't assume things are insecure either unless the security of the system is specifically called out.
In other words, it's generally out-of-mind.
Considering this, you should be keeping green locks and red warnings going forward and never having a no-warning state except perhaps on private networks where the security of the connection is to be determined by the team which owns that private network. There's an entire industry of "Secured By" badges which CAs managed to market to draw attention to connection security in a space where standard indicators should be serving that role based on standard--not marketing--metrics.
(This will probably prepend a later letter I'll write up about Google Security's unilateral changes the past few years. This and HPKP are two that come to mind.)
Edit: A good point was raised by twitter user @akanygren on this topic, notably that since there's no assurance other vendors will share this same approach, this will immediately sow UX confusion. The corollary I'd attach to that is that with Chrome as a plurality player eliminating a decision-point in their UI, other browsers now gain a marketable competitive advantage by labeling secure connections as such and are dis-incentivized to follow suit because they stand to benefit by maintaining some variant of the status quo.
You may, for instance, be transmitting credentials that may be stored in plain text, be easily accessible to third-parties or may even be handed directly to black markets. The padlock itself says nothing about any of those details.
A better approach to no icon at all, I think, is simply “secure connection” wording. Trying to distill a lot of complexity and nuance into a single icon is what’s ultimately problematic. It works somewhat well, but not quite well enough.
The problem is, most people won't understand the difference between that and just "secure"; arguably, the people who understand what "secure connection" means are those for whom this change doesn't matter.
That would be the more useful change. If HTTPS fails (due to hostname mismatch for example), fall back to HTTP and warn, but trying HTTPS first would be fantastic and eliminate one round trip for many of my sites that are not in the HSTS preload...
Google already defaults to linking HTTPS versions of pages in its search results, which is a much better solution IMO. (Attacker can't intercept the connection to Google because of HSTS, and can't intercept the connection to the site you visit because it's a direct HTTPS link.)
Except that if the user is not visiting for the first time, then HSTS comes into play if the security headers are set, browsers can let the user know something is amiss.
We both agree that fail-open security is useless, but right now Chrome and other browsers default to going to port 80 for first visit instead of port 443. All I am asking is that the default becomes 443, and the fall-back, for first visit, is port 80.
This way I can stop running web servers on port 80 that do nothing but send a 303 with https as the protocol for that particular domain.
https://blog.mozilla.org/security/2012/11/01/preloading-hsts...
It's almost as if you didn't read my post.
Unless I can go register all my domains to be in the HSTS preload, I'd much rather Chrome tried HTTPS first, so I don't have to run a web server on port 80 that sends a 303 with https as the protocol.
If they’re going to change a status indicator during form entry, the indicator needs to be right in the user’s face (i.e. floating over the cursor). Anything else might be missed. Even so, pointless dynamics; mark the page red always, and stop trying not to offend those implementing blatantly-unsafe forms.
Also, a minimum of a green default checkmark seems in order, even in this wonderful secure-by-default future. Continue to train people to demand better security and look for safer-web indicators.
But unless you're entering a password, there's no color at all.
The difference between secure and insecure is far too subtle for non-experts like my mom.
I wonder how they're planning to handle EV certificates. They don't seem to be mentioned anywhere in this post. I seem to recall at least one person at Google advocating for removing EV indicators entirely.
Argument 1: this person was able to get an EV cert for "Stripe, Inc. [US]", an entity they registered in Kentucky, no relation to the Stripe, Inc. of California whose website is stripe.com. They were not able to get a certificate for stripe.com. (The CA revoked it, and then later apologized for revoking it because there was no reason by their policy to do so.) https://stripe.ian.sh/
Argument 2: the actual website for MasterCard's SecureCode is https://www.mycardsecure.com/ , whose EV cert is "Arcot Systems LLC [US]". The fact that it has a meaningless domain name is in no way fixed by it having a meaningless (but technically accurate, Arcot is the contractor for SecureCode) EV cert. How do you know you're actually supposed to type your personal information there?
Argument 3: the web's security model is based on origins (domain names), not on EV certs. If Stripe switches tomorrow to stripeiscool.com and a domain squatter gets stripe.com, my browser will still send cookies to stripe.com, even though it no longer has an EV cert, and it certainly won't send cookies to stripeiscool.com, even if it has an EV cert with the same organization. Even if EV were a good idea in the abstract, it lacks a plan to make it work with the web as actually deployed.
There are obviously issues with EV as it's currently implemented, but I believe the solution to that is to fix those issues, not to eliminate the indicator entirely.
Attack 1 makes me worry about whether this is solvable at all. There's a lot of "First Bank and Trust"s out there, and they'd all need an EV certificate for the same string, so avoiding the attack seems genuinely hard. Like social media (or curated app stores), the only way it can really work is if the "verified" marker creates first-class and second-class entities: the entities approved by the powerful as reasonable to do business with, and the entities that aren't. Someone makes a decision about which First Banks and Trusts are "real" and which ones aren't, and you can't appeal it.
A site you're looking at with an EV cert you're happy with might have an image that's supposed to say "Sorry, we're closed for maintenance" with the site's logo. But bad guys, who have a DV cert have substituted "Welcome, please use our new login system". They've also replaced the cool live map and fancy animated carousel below that with their "new" login form. So the site has the EV visuals, but bad guys who broke only DV can subvert it almost totally.
Do you know the thinking behind getting rid of the EV indicator? Is EV considered useless?
Edit: Just as I posted this, someone else answered my question: https://news.ycombinator.com/item?id=17093737
I think it's important to keep in mind that even if their certificates are free, they are still a permanent dependency of your site. Moreover the fact that they can offer certificates for free works because of the concerted industry effort going on currently to move the whole web to https.
They are well-supported but, for sites with no budget for commercial certs, will still stay a single point of failure. If they should, after the transition to 100% https is completed, not bevable to offer free certs anymore, what exactly would be the plan B?
"Your information (for example passwords or credit cards) is private when sent to this site"
That sounds so wrong because it implies you can trust the site... but writing something clearer is hard!
Hiding it, unhiding it, is too much magic. Yes, I believe web users need a certain level of technical understanding, so that they are savvy enough when they see it elsewhere, like in an email or some other document.
I am for hiding the inner workings of things, but I believe the URL is part of the user interface.
In the age of Let’s Encrypt I wouldn’t say that HTTPS implies safety. I can register a phishing site in 5 minutes with fake credentials, the configure let’s encrypt to get that little padlock icon. No questions asked.
HTTPS only guarantees that your traffic is not spied on or modified en route, but for ordinary users that wasn’t an issue in the first place.