To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.
- Require that you supply an explicit list of domains to ignore the errors for, rather than a blanket exception
I really like the sentiment in option 3 that we should clearly put
chrome in "testmode" (as nasko puts it). But, having tried generating
certs, I know this is non-trivial; especially for multiple sites etc.
How about "If you supply the --ignore-certificates flag, we will show
a TESTMODE or INSECURE" (or something like that) in the URL bar (hide
the URL bar completely by default a la origin chip). Or show test mode
in an info bar right below the URL bar, always on and forever visible
through out the session. We can also disable extensions or use a new,
separate short-lived profile. I think there is huge value to a command
line flag that makes testing easy. Relying on the UI for explaining
this is test mode and is unsafe seems a minimally disruptive change.
Hi Ryan,Thanks for including me in this discussion. I'm not entirely convinced you have exhausted the available options:To support testing but discourage abuse, we could- apply --ignore-certificate-errors (and other debug flags) only to programmatically launched tabs, e.g. tabs launched via the debugger protocol,- have a security-is-broken butter bar, as suggested elsewhere in this thread, but disable the --i-c-e as soon as the butter bar is closed,[That is, closing the butter bar has an effect, so that even an unwitting user is likely to do the right thing.]- disable interactive use once --i-c-e is set (e.g. no more typing into URL bar), or maybe alternatively disable --i-c-e as soon as true interactive use is observed,- have a Release-Testing build (in addition to Release and Debug) that is identical to Release except for allowing testing flags.Honestly, I have no idea how good and/or realistic those options are; but I think there are more options than what you're looking at.
Use Cases:
- Automated Testing where you have an HTTPS proxy acting as an active MITM, and you do not wish to make persistent state changes to that machine
- If this is your use case, please tell me why you can't install the root cert, as most MITM proxy software (Charles, Burp, etc) recommend?
I think the root problem is that testing people and security people should get together
I don't think this is particularly about malware. Malware's going to turn off interstitials no matter what we do. I think this is more about discouraging using this flag as a way to get rid of those pesky interstitials by regular users and developers.
--allow-running-insecure-content
to prevent Chrome from checking for insecure content. Instructions on how to add a command line flag can be found on our Chromium site (English only).I'm a IT guy working with number of systems using internal certs (not from my org), self-signed certs and so on. I understand you try to make Chromium more secure for end-users but the way you do it affects professionals in bad way.
and bad cipher is still better than no encryption so it makes no sense to punish sha1.
Why don't you add few flags/options where the user could select which SSL errors she don't worry about? For me this SHA1 warnings, self-signed warnings or especially "certificate valid too long" and so on are really useless, just need lot more clicking and raises my adrenaline. You could still show red address bar and similar hints but don't stop the website from loading!
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.
But there should be an option for an advanced user to say "i know what i do and i don't want to see warnings for self-signed/mismatched fqdn/validity too long certs".
this is why I can't follow your argumentation that an IT pro could add exceptions. For sure I can, I know how to do so but this doesn't work for me - I would have added hundreds of exceptions over time and would never know which exception is valid or not.
And this approach wouldn't even work for number of cases: say you access a device via it's IP address - this will always raise an error...
This why I ask for usable interface which WARNs about errors but doesn't stop me from accessing the web page. Like it works now when --ignore-certificate-errors was added: address bar shows https in red letters and stoke through but i can access a website without two more clicks just because certificate is valid for more then 5 years.
In real life we use Windows OS, connect with internet and use Facebook - when we provide all our data to some huge internet company it makes no difference if we do this using good encryption or not :(
you should point out that browser could not verify connection security and provide easy way to proceed when the user doesn't care about security for this service or could be lucky to know the certificate is broken for a reason.
In real life we have lot of certificates which use outdated technologies but I prefer to use them rather provide content using plain http - just to know NSA will need few cpu cycles more to see the content - this is where your "total security view" brakes user experience completely and forces user to such bad things like using the ignore flag all the times.
And trust me no end user will stop accessing malicious website just bacause a warning is shown it just takes few seconds longer.. Nobody even read this warning..
It's good you are aware of the problem and try to address the issue. Limiting warnings to "external" networks could be a step in right direction but still doesn't address lot of situations like places where you sit in the client network and access a server/router/aplliance in different subnet - you get a certificate warning.
Hope you will take the user view on certificate handling into account for further developement. It's not the certificate security or validation check I worry about - it's the more and more restrictive handling of certificates which forces the user to do 2-3-4 more clicks to access the webservice in case the certificate is not perfectly valid...
On Jun 3, 2015 12:09 PM, <willi....@gmail.com> wrote:
>
> hello together,
>
> you all pointed me to good solutions in terms on increasing security and explained how to achieve more security by spending lot of time for requesting/trusting internal certificates. All this points are 100% correct but this is still not what I'm looking for. Say I spend only 5min per device to request/issue/install internal cert per device - I spend 17 days (say better 52 working days) to add this certificates to a population of 5k ip phones. Do you think a minimal security improvement is worth spending two months of your working time? And 5k of ip phones is big but still not a huge customer. Plaese understand that reasons you need such flag/setting in developement could be pretty valid in production. From my point of view it's really sad you are not willing to provide users with good interface to adjust the level of security he needs and even discuss removing the only chance to get rid of this blocking and disracting security warnings.
Alternatively, couldn't it be argued your 5K IP phones are holding back the security of Chrome users?
Please understand that being able to centrally administrate those 5K IP phones will save you from needing to spending two months of time on.
And yes, the overall security of over a billion Chrome users is generally more worthwhile. If every one of those users had to spend just 5 seconds thinking about whether or not they were secure, that would be over 57,870 days of thought given to the matter. That certainly is far greater than than 52 days to reconfigure - or hopefully the week spent to put in a central administration solution.
I'm not trying to be overly dismissive, but since you wanted to encourage contemplating perspective, I wanted to show the several orders of magnitude difference.
And that setting does exist, except it isn't provided by Chrome. It's provided by your OS as a way for a duly empowered administrative user to configure their machine to trust certain certificates.
The need for a Chrome-specific option isn't there, and having one puts users at risk (from themselves and from malware), since any Chrome configuration, setting, or flag can't achieve the same security protection and enforcement the OS provides. Having the option, and making it usable, thus does put others at risk.
And if you don't care about usable, then why not just rewrite the runtime memory of Chrome? It's an option, hidden, but not terribly usable ;)
And I think, no, I KNOW, the root problem is that ever more people believe they are allowed to, and even should, police other people!
Chrome, Firefox, ... all follow this RUDE and IDIOTIC path.
It is NOT your business to entirely prevent every VISIBLE possibility for the OWNER of a computer to ACCESS the websites he or she desires!
Because: You as "developer" will never grasp the REASONS WHY this or that computer OWNER desires to access this or that website.
As so often now, Google folks AGAIN have WASTED DAYS of MY lifetime that I am spending to search for a working solution. And can't find it, so foolishly locked up those "developers" have made chrome.
You seek to "secure" "ordinary" users?
1. When did you get their permission?
2. What makes you think you don't need their permission?
3. Since clearly you disregard 1. AND 2., at the very very very least, LEAVE OPEN clearly visible and multiple solutions how computer OWNERS can decide for THEMSELVES what website they need to visit.
Like I said, for REASONS you folks will never understand.
Like you never understand that serving Google ads in languages I don't understand and have never use for any search ... makes ZERO sense.
I will not ever click one, and you will not ever earn anything from being so foolish.
I trust these clear words, bolded, get you to WAKE UP, you "developer".
--- No replies sought nor PERMITTED. Now I police you, let's see how much YOU seek to comply.
I hope more people stop using Chrome because of such useless limitations like blocking of self-signed or untrusted certs.
best wishes
willi