Rethinking --ignore-certificate-errors

[Ryan Sleevi]

I'd like to reconsider how --ignore-certificate-errors works, and would hope for some feedback from the security-minded folks on this list.

This flag has long been a thorn in my side, precisely because it shows up time and time again in the Product Forums and on Q&A sites as the "solution" to your SSL problems. Of course, by --ignore-certificate-errors, it's effectively saying --make-https-a-silly-pointless-thing, which is bad. We also see it REGULARLY added by malware on a users machine, as a way of hijacking their traffic without admin privileges.

That said, it's introduction was for a specific purpose - namely, that of testing.

There are several options, and I'd love to get feedback and/or use cases from people to influence how this works.

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?

  - On most OSes, installing a root cert requires admin privileges, to reduce the risk of malware/underprivileged attacks. Having this Chrome flag is a way to actively abuse this security, without really effective mitigation strategies.

Possible Changes:

- Remove it entirely.

  - This is my preferred solution

- Redefine what "ignore" means

  - Right now, it has the effect of making it "as if" the user clicked through an HTTPS warning.

  - This means that some features are disabled (SPDY/QUIC coalescing, the HTTP cache, password autofill)

  - Instead, we'd change it to mean "As if there never was an error in the first place" (e.g. making this flag MORE dangerous)

  - This has been requested by some test teams at Google, but I'm not a fan of this

- Require that you supply an explicit list of trust anchor files from disk

  - That is, ONLY these trust anchors would be supported as trusted. Errors for other reasons (e.g. CN mismatch, expiry) would NOT be bypassed.

  - We have code in net/base/test_root_certs to do this, but have so far intended to keep this out of "Release" Chrome and only in unit tests for security/complexity reasons

- Require that you supply an explicit list of domains to ignore the errors for, rather than a blanket exception

[Chris Palmer]

On Thu, Oct 2, 2014 at 1:51 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

> Possible Changes:
> - Remove it entirely.
> - This is my preferred solution

I'm happy with this.

> - Require that you supply an explicit list of trust anchor files from disk
> - That is, ONLY these trust anchors would be supported as trusted. Errors
> for other reasons (e.g. CN mismatch, expiry) would NOT be bypassed.

I'm happy with this, too.

[Victor Costan]

Is there (can there be) any clean way to write a script that generates a root certificate and a server certificate signed by the root, then launches Chrome in a way that accepts that root certificate, in addition to the system-supplied certificates?

My use case is that I'd like to have other developers clone my git repository and launch the test suite via a script, using an https origin. I want the script to generate certificates in a .gitignored directory, as opposed to having certificates in the repository, so developers don't expose themselves by importing a root certificate with a known private key. Ideally, I wouldn't have to ask developers to import a certificate in their CA store, so the store doesn't become polluted as they contribute to different projects.

The case above doesn't handle the heavy debugging that you'd need a proxy for, but I claim that it works for day-to-day development for most projects.

It seems like your 4th proposal and a modified 3rd proposal would make this work, whereas the 1st and 2nd ones would break this case and make development harder.

    Victor

To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

[Peter Bowen]

On Thu, Oct 2, 2014 at 1:51 PM, Ryan Sleevi <rsl...@chromium.org> wrote:
> - Require that you supply an explicit list of trust anchor files from disk
> - That is, ONLY these trust anchors would be supported as trusted. Errors
> for other reasons (e.g. CN mismatch, expiry) would NOT be bypassed.

What about also allowing these as site certificates? For true
testing, the workflow could be generate self-signed cert, pass
--always-accept=mycert.pem

That doesn't solve the hijacking issue, but does limit the scope
considerably. You could even put in a requirement that it has a
not_before date in a certain window (now() - 5 days) to ensure they
are being regenerated routinely.

[Nasko Oskov]

On Thu, Oct 2, 2014 at 1:51 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

I'd vote for this. It will put Chrome in true testing more, where it will ignore all other trusted anchors, so it can't easily be used for general browsing.

It is possible to automate the generation of such certs, so it shouldn't be too complex for people that want to use this.

 

- Require that you supply an explicit list of domains to ignore the errors for, rather than a blanket exception

Just a simple list of domains will be trivial for malware to use, just like the existing option. Requiring actual certs from disk at least causes some other artifacts on the machine. I'd rather option be completely removed than allow this one.

[Devdatta Akhawe]

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.

cheers
Dev


On 2 October 2014 14:37, 'Chris Palmer' via Security-dev

[Joel Weinberger]

On Fri, Oct 3, 2014 at 2:11 PM, Devdatta Akhawe <dev.a...@gmail.com> wrote:

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.

This would also be consistent with our other crazy flags, like --disable-web-security. 

[Daniel Vogelheim]

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.

I think the root problem is that testing people and security people should get together 

[Daniel Vogelheim]

Oops... fat fingered the "send" button. Continued below:

On Mon, Oct 6, 2014 at 2:52 PM, Daniel Vogelheim <voge...@google.com> wrote:

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 see 2.5 problems with installing a testing root cert:

- It causes friction to do performance testing; which we'd really like to reduce.

  - Most devs can't change the testing bots, so this is gated on work by other teams.

- Installing a root cert is a machine-level operation. Hence the testing root cert would have to be installed on many developers' machines, which means we end up with an eminently stealable root cert guaranteed to be installed on hundreds of Googler's main machines. That doesn't seem like superbest security; it fact, it seems quite exploitable once that test certificate leaks. (It's surely a different problem from what you're trying to protect against.)

I think the root problem is that testing people and security people should get together 

Well... sentence not finished, but I do think this is a problem. IMHO it would be very beneficial if Chrome security could meet with Chrome testing on this. I'd be super proud to help, but honestly I know neither side particularly well and so I might very well be overlooking something entirely obvious here.

Thanks,

Daniel

 

[Chris Palmer]

In the past I've heard complaints about the butter bar/infobar idea,
because it affects the layout of the page and the size of the
viewport. Some tests apparently rely on that to be correct or at least
not flaky.

That, combined with the concern about a stealable root that is likely
to be installed on many Googlers' machines, combined with the concern
that people should be able to control their own computers yet without
undue risk, point to the Create Security Exception... solution (i.e.
like Firefox: allow this cert to be used for this origin).

[Jochen Eisinger]

Chris, with this approach, malware can still create a security execption for say google.com via the command line, no? (and for telemetry, in the end, we want some automated way to configure those things).

-jochen

[Joel Weinberger]

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.

[Chris Palmer]

On Tue, Oct 7, 2014 at 9:08 AM, Jochen Eisinger <joc...@chromium.org> wrote:

> Chris, with this approach, malware can still create a security execption for
> say google.com via the command line, no?

Certainly. It is not possible to defend against an attacker who runs
with the same or greater level of privilege as Chrome.

> (and for telemetry, in the end, we
> want some automated way to configure those things).

I'm not sure what you mean.

[Jochen Eisinger]

I guess what I'm saying is, I'm not sure how this will be better than --ignore-certificate-errors. But I see how it makes the foot-gun more difficult to aim, which is probably a good thing.

best

-jochen

[Lucas Garron]

This isn't directly related, but https://support.google.com/chrome/answer/1342714?hl=en currently offers the following advice:

• Although not recommended, you can also use the command line flag --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've put in a help center request that (incidentally) asks for this to be removed: https://crbug.com/421270

Just thought I'd let y'all know, in case you weren't aware, or have any objections.

[Sigbjørn Vik]

Hi,

Some observations:

It seems that --allow-running-insecure-content should allow tools to
work with pages as easily as possible, ignoring any security errors.
The problem is that the current implementation makes insecure sites look
secure to users.

So the requirements for the flag seems like the following:
* Insecure sites look secure to tools
* Insecure sites look insecure to users

This is fairly easy to do, given that users look at icons and colors,
and tools look at values. When the flag allows a bypass of a security
check, change the green padlock into a red skull and crossbones (or any
similar display-only changes). Tools would never notice, but users
should not expect the page to be secure.

On 08-Oct-14 09:41, 'Lucas Garron' via Security-dev wrote:
> This isn't directly related, but
> https://support.google.com/chrome/answer/1342714?hl=en currently offers
> the following advice:
>

> * Although not recommended, you can also use the command line

> flag |--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

> <http://www.chromium.org/developers/how-tos/run-chromium-with-flags> (English

> only).
>
> I've put in a help center request that (incidentally) asks for this to
> be removed: https://crbug.com/421270
> Just thought I'd let y'all know, in case you weren't aware, or have any
> objections.
>
> On Wed Oct 08 2014 at 12:21:46 AM Jochen Eisinger <joc...@chromium.org

> <mailto:joc...@chromium.org>> wrote:
>
> I guess what I'm saying is, I'm not sure how this will be better
> than --ignore-certificate-errors. But I see how it makes the
> foot-gun more difficult to aim, which is probably a good thing.
>
> best
> -jochen
>
> On Tue Oct 07 2014 at 7:55:44 PM Chris Palmer <pal...@google.com

> <mailto:pal...@google.com>> wrote:
>
> On Tue, Oct 7, 2014 at 9:08 AM, Jochen Eisinger
> <joc...@chromium.org <mailto:joc...@chromium.org>> wrote:
>
> > Chris, with this approach, malware can still create a security
> execption for

> > say google.com <http://google.com> via the command line, no?

>
> Certainly. It is not possible to defend against an attacker who runs
> with the same or greater level of privilege as Chrome.
>
> > (and for telemetry, in the end, we
> > want some automated way to configure those things).
>
> I'm not sure what you mean.
>

> To unsubscribe from this group and stop receiving emails from it, send
> an email to security-dev...@chromium.org

> <mailto:security-dev...@chromium.org>.


--
Sigbjørn Vik
Opera Software

[Ryan Sleevi]

[Sorry, this was sitting in a draft for a long time because I forgot how to press "Send" several weeks ago]

Thanks everyone for the feedback. Having looked at this more, some of the options originally proposed don't exactly work as well as I'd hoped.

My current feeling is something like

--ignore-cert-error="domain:file,domain2:file2,domain3:file3"

With domain matching the host rules syntax used in --host-rules

e.g.

--ignore-cert-error="*.domain.com:myfile.pem,*.example.com:myotherfile.pem,testing.whatever.com:thirdfile.pem"

There's still some challenges with this syntax - namely, supporting HTTPS via IPs and figuring out an appropriate separator character (I used "," and ":" here, although ":" may appear both in filenames and in IPv6 addresses)

[After Daniel pointed out today I failed to send this, and discussing more with him]

The other alternative is making --ignore-certificate-errors no longer affect the IOThread Globals, but only affect the Profile's URLRequestContext (via the CertVerifier). The benefit here is that secondary services (translate, sync, sign-in, etc) won't be affected by --ignore-cert-errors, generally speaking, because they don't use the main profiles URL request context. However, the downside is anything that does copy from that profile is potentially at risk of being MITM'd.

Regarding the malware discussion, on Windows/Mac/Linux (but not iOS, Android, or ChromeOS), there are other ways for malware to disable cert checking, so I agree, it's a poor argument. It's more about avoiding giving developers a footgun that, if misconfigured, can cause their credentials to leak across the network or hostile software to be installed to their machines. In that sense, I favour the per-host whitelist vs the blanket-exceptions.

Thoughts?

[willi....@gmail.com]

really good I found this flag after long hours of searching... please don't brake it. and I'm happy you discuss about ways to improve the product. 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.

In general a certificate provided by "not trusted CA"=self-signed doesn't provide less security it's only less trusted compared to another another one. 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!

thank you.

[Ryan Sleevi]

On Tue, May 12, 2015 at 1:25 PM, <willi....@gmail.com> wrote:
> really good I found this flag after long hours of searching... please don't brake it. and I'm happy you discuss about ways to improve the product. 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.
>

If you're an IT professional working with systems using internal
certs, you should be able to replace them or mark them trusted using
your enterprise controls.

> In general a certificate provided by "not trusted CA"=self-signed doesn't provide less security it's only less trusted compared to another another one. and bad cipher is still better than no encryption so it makes no sense to punish sha1.
>

Unfortunately, we'll have to agree to disagree.

> 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!

Because this actively harms security.

[Chris Palmer]

On Tue, May 12, 2015 at 1:25 PM, <willi....@gmail.com> wrote:

> 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.

Unfortunately, 'legitimate' self-signed certificates are essentially
impossible to distinguish from attacks without special, out-of-band
knowledge, such as what you have as a person with a special
relationship with these outside organizations and with your technical
expertise. We have to make Chrome work safely for everyone, mostly
people who cannot (and should not have to!) distinguish the safe cases
from the unsafe cases.

It's a fundamentally hard problem. We need friction-free cryptographic
introductions such as certification authorities provide. (And we seek
to strengthen the introduction with Certificate Transparency, and to
harden its security after the fact with key pinning.)

Therefore, I would urge you to urge the people you work with to issue
their certificates from a real CA of their own creation (preferably
name-constrained!), and then you can add that issuer to your
computers' trust anchor stores.

> In general a certificate provided by "not trusted CA"=self-signed doesn't provide less security it's only less trusted compared to another another one.

But it does, for the reason I gave above. If you happen to know for
sure the certificate is OK, that's extra special good luck for you.
But in the general case, we can't expect that luck.

> and bad cipher is still better than no encryption so it makes no sense to punish sha1.

Perhaps counter-intuitively, that is not the case. Bad cryptography
can indeed be worse than no cryptography. One reason is that with bad
cryptography, people can develop a false perception of safety.

As an example, see http://www.win.tue.nl/hashclash/rogue-ca/. MD5 was
definitively broken for the purpose of authenticating certificates,
and yet it lived on for years because we had not developed a gradual
transition plan away from it. People were vulnerable in the real world
for years to the attack that site describes.

So, with SHA-1, which we know is subject to attack, we are doing this
gradual phase-out plan. As it happens, just recently a leading
researcher has advanced the state of the art of attack against SHA-1:
https://marc-stevens.nl/research/sha1freestart/. This kind of attack
will get increasingly better, gradually and then suddenly.

(Note that we are marking SHA-1 as bad when it is used to sign
certificates — i.e., to prove their authenticity. We are not marking
SHA-1 as used for data integrity, in the particular way that TLS does
this, as bad.)

> 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!

Again, we have to make the web safe for most people, most of the time,
by default. Experts have options available to them, such as generating
properly-signed test certificates from an organizational CA.

We have found that people, both experts and non-experts, will use and
have used loopholes like --ignore-certificate-errors to decrease their
effective security without really understanding the consequences.

[MSI Team]

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.

Chrome is a browser designed for speed, simplicity, and security. Security includes blocking insecure, dangerous, and potentially malicious certificates. Administrators and professionals can trust particular blocked certificates via the Certificate Viewer (Windows only).

and bad cipher is still better than no encryption so it makes no sense to punish sha1.

Chrome warns the user prior to opening a SHA-1 website due to SHA-1 security issues. Chrome does not remove the SHA-1 from the website; it only displays a warning. Additionally, SHA-1 is not the only option. Other options include SHA-2, S-256, and more (all SHA-2+ certificates are more secure than SHA-1).

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!

Some users might enable trusting insecure options they do not know.

On Tue, May 12, 2015 at 1:25 PM, <willi....@gmail.com> wrote:

To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

[willi....@gmail.com]

Hello Guys,

thank you for valuable answers but unfortunately you still don't get the point. The discussion is primary not about security but about usability.

You are absolutely right when you say a normal user could not understand if the cypher is secure enough, if self-signed cert is valid or sign of MITM attack - the browser should warn and block the connection BY DEFAULT. 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".

I'm dealing with dozens of different home/smb routers every day and all of them use https to encrypt their webinterface but don't have a valid certificate for it (sometimes don't even fqdn just IP address). This is real world for most of system engineers - lot of boxes where producers think "we make our box more secure by using https only" - even Microsoft forces 3rd party phone manufacturers to disable http on their phones when they connect with MS LYnc - but how should each IP phone in organisation receive a valid cert? 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. Maybe you could make the warning even more recognizable when you color the complete address bar yellow/red so everybody would immediately detect if there is a problem with certificate but the website should load immediately if the user choose the specific option.

[Craig Francis]

On 13 May 2015, at 15:48, willi....@gmail.com wrote:

> I'm dealing with dozens of different home/smb routers every day and all of them use https to encrypt their webinterface but don't have a valid certificate for it (sometimes don't even fqdn just IP address). This is real world for most of system engineers

Hi Willi,

Not sure if you read Ryan's reply, but he suggested using internal certs.

This should solve your problems, and make it *much* safer than your current approach of just switching off certificate checking (which is very dangerous, and makes it trivial to perform a "man in the middle" attack for any website).

For a brief overview, you should create your own CA (certificate authority), and push its certificate out to every computer that will need this setup (basically telling them to trust your CA).

The private key for this new CA should never leave the computer you set it up on (you really don't want it to fall into the wrong hands).

Then you will need to connect to each box that is doing HTTPS, and create a new public/private key (you might as well)... copy the new public key to your CA computer, where it can create a certificate for that box... and you just need to copy the certificate back to the box, and update its config to use it, and the new key.

That's it :-)

Now any time one of the computers need to connect to one of these boxes, the box will use its new key and certificate (signed by your CA), and the computer (who has been told to trust that CA) will accept that certificate without any errors.

Craig



PS: if "--ignore-certificate-errors" is being used like this, maybe it should be removed? are there any good reasons for it to exist?

[Chris Palmer]

On Wed, May 13, 2015 at 7:48 AM, <willi....@gmail.com> wrote:

> You are absolutely right when you say a normal user could not understand if the cypher is secure enough, if self-signed cert is valid or sign of MITM attack - the browser should warn and block the connection BY DEFAULT. 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".

I understand. There are 2 problems with this, though: technical people
are sometimes not as well-versed in the particulars of the Web PKI and
cryptography as they imagine — in fact, very few people understand the
full impact of any given crypto protocol change, because it's an
extremely difficult area of specialization* — and many non-technical
people are tricked or confused into disabling all security by using
loopholes like --ignore-certificate-errors. (Read the comments in tech
blogs, the Google Help Center discussions, and so on. You'll see that
sad phenomenon in action.)

In fact, attackers often trick people into inserting malicious
JavaScript into the Developer Tools console. It got so bad that
Facebook started logging a giant warning to the console (see attached
screenshot). Yow!!

(* Note that I do not consider myself 1 of the few people who
understands the full impact of any given crypto protocol change.)

> I'm dealing with dozens of different home/smb routers every day

Ahh, you didn't mention that specific use case before. 3 thoughts on that:

1. You can just click through the interstitial page, for most
self-signed routers.

2. If a router's cryptography is so severely broken that you can't
click through — e.g. certificates signed with MD5WithRSA, for example
— that's a sign that many, many other things are likely to be
sub-standard about the router. Flash its firmware with a more recent
open source router OS, or buy a better brand of router.

3. The problem of authentication for small, private servers — home
WiFi routers are just 1 example — is a problem that we (Chrome
Security team, but also lots of other people in the industry) are
working on. In fact I have an overdue draft of a plan open in another
tab that I should really switch to after this...

> 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. Maybe you could make the warning even more recognizable when you color the complete address bar yellow/red so everybody would immediately detect if there is a problem with certificate but the website should load immediately if the user choose the specific option.

Do you do this in your main Chrome profile, or in a separate No
Security Here profile? I hope for your sake it's the latter. :)

In the next email, Craig Francis asks:

"""PS: if "--ignore-certificate-errors" is being used like this, maybe
it should be removed? are there any good reasons for it to exist?"""

Exactly. It should be removed. Perhaps not just yet, but eventually.

[MSI Team]

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".

An internal cert would be a better option.

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.

Removing old exceptions, or preferably, using internal certs. You could remove exceptions as you no longer need them. However, a better strategy is to use internal certs.

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...

Maybe we can file a feature request requesting that accessing manually *trusted* devices connected to the *same* network (defined by router) via IP address does not prompt a warning.

 

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.

*Some* website[s] *might* be vulnerable to "man-in-the-middle" attacks that could potentially affect or infect the visitor prior to entering or submitting any data. For example, a website could use a forged SHA-1 certificate valid for 10 years to perform a man-in-the-middle attack to its visitors loading various malware onto the visitor's computer[s]. *No guarantee* this particular type of attack/trick actually exists, but it's (always) good to be secure from vulnerabilities prior to them being actively exploited.

On Wed, May 13, 2015 at 7:48 AM, <willi....@gmail.com> wrote:

[willi....@gmail.com]

Hello again,

Cris, Craig and MSIteam, thank you for the answers but once again: you are looking at the problem from security point of view only.

For sure I'm not the PKI pro who could detect issues with certificates with one view and for sure I understand using internal CA is preferred option for security but there is big difference between theoretical security and real life. 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 :(

Certificates just provide a tranport layer security - they has nothing to do with security of content on both sides server and client they don't protect against user faults like running malicious scipts and they should be threated in this way - 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 general even valid certificates don't protect against malware placed on websites - they only raise a cost of seeding malware to the cost of the cheapest certificate trusted from a big number of devices. No CA checks if the website is good or bad they only do basic checks if the certificate requestor is the owner of the webserver (or has enougth power to change DNS or place some file on the webpage) - a good certificate could protect really bad contents.

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...

regards
willi

[Alexey Baranov]

I think one of the main purposes of the browser as a platform is to give a chance to websites who *want* to provide security to actually do it. You can write XSS/XSRF/whatever-injection-safe webapp, use latest tls, hsts+static pinning/ocsp-must-staple/CT/*, but this mere flag undermines all that.

Adding this flag to the browser startup cmdline (windows file shortcut) requires no elevated rights from the malicious software. Unlike adding trusted root to the system.

Security is not binary, everything can be broken/misused, it's just a matter of cost. And all we can do is to maximize those costs for the attackers. This flag is a big hole in all transport security efforts, it's really need to be re-designed (or even deleted, but unfortunately it is actively used in development).

 

 

17.05.2015, 16:00, "willi....@gmail.com" <willi....@gmail.com>:

[Andreas Mirbach]

> On 17.05.2015, at 15:00, willi....@gmail.com wrote:
>
> 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…

just make it valid. It’s not the users fault when a page provider failed to do his job. So the blame is on them.
If the users don’t see when something is wrong with the websites certificate they will never ever complain that and every website will stay as they are right now.

> 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.

That’s the reason why the --ignore-certificate-errors should be disabled after a period of time. So every users sees when a certificate is invalid and has the chance to blame the provider. By the way user experience doesn’t always mean speed, sometimes it means to stop the user an make him think of what he is doing.

> 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..

Our company got over 100 calls and mails within the first week, when chrome started to indicate the SHA1 certificate problem. A lot of customers are concerned about their security. I know a lot of companies that got feedback from their customers because of chromes new SHA1 indication, some of the companies didn’t know they had that problem but fixed it very quick. This is a very good thing and i hope it’s just the beginning.

I think there is NO excuse for bad certificates and bad security at all.
People seem to think it’s acceptable to stay with bad security because they are to lazy to do their job right.
And its important to indicate this clearly and publicly to the customer.

As far as I know, there is no reason not to use valid certificates in development.


Andreas Mirbach
a.mi...@me.com

[MSI Team]

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 :(

Not everyone. That's exactly the purpose of adblocking filterlists like EasyPrivacy; to block tracking and protect user privacy. i.e. it's not no difference for everyone.

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.

 Click "Advanced" then Proceed. However, this is highly unrecommended due to severe security risks.

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.

Not necessarily. The modern web consists of new certificate technologies and old certificate technologies. Additionally Chrome Security deprecates outdated certificate technologies to help reduce this. Hackers are always exceeding the protection of outdated security metrics, and today's threats, attacks, malware, and exploits could cause outdated security metrics to be as insecure as plain HTTP nowadays (and perhaps less secure with a false sign of security).

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..

Wrong. Some users never ignore warnings, while some sometimes ignore warnings, while still others always ignore warnings. There is a variety; some users will and some users will not. See https://docs.google.com/presentation/d/16ygiQS0_5b9A4NwHxpcd6sW3b_Up81_qXU-XY86JHc4

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.

Threats can be sourced from inside your internal network, e.g. a hacked device or some infected or insecure device on a large corporate network.

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...

2-3-4 clicks through a warning helps stop the user and have them think and decide if they really want to risk an attack, exploit, or snoop. Some users may not realize security issues and potential risks exist on the current page until they have already entered (and submitted) potentially sensitive information or Malwarebytes Anti-Exploit displays a red "Exploit Attempt Blocked!" warning message. Until we develop further concepts that respect security I do not think these suggestions are ready for development.

[willi....@gmail.com]

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.

[Ryan Sleevi]

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.

[willi....@gmail.com]

Hi Ryan
once again - I agree you want to provide highest possible security to each user - what users like me look for - is a setting (even a hidden one) where I can setup my own preferences. Which would never compromise security of others...

willi

[Ryan Sleevi]

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 ;)

[MSI Team]

If the --ignore-certificate-errors flag/switch is being used in ways that pose a potential risk to end users then it might need to be removed. When was it last used for a purpose we do not try to discourage?

[dbmgb...@gmail.com]

"I think the root problem is that testing people and security people should get together "

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.

[willi....@gmail.com]

As Chrome is limiting the ways to interact with devices without "perfectly valid public certificates" I switched to Firefox. This one is still bad and too noisy but at least some options exist to make it little better.

I hope more people stop using Chrome because of such useless limitations like blocking of self-signed or untrusted certs.

best wishes
willi

[mario3...@gmail.com]

On Thursday, October 2, 2014 at 4:51:34 PM UTC-4, Ryan Sleevi wrote:
> I'd like to reconsider how --ignore-certificate-errors works, and would hope for some feedback from the security-minded folks on this list.
>
>
> This flag has long been a thorn in my side, precisely because it shows up time and time again in the Product Forums and on Q&A sites as the "solution" to your SSL problems. Of course, by --ignore-certificate-errors, it's effectively saying --make-https-a-silly-pointless-thing, which is bad. We also see it REGULARLY added by malware on a users machine, as a way of hijacking their traffic without admin privileges.
>
>
> That said, it's introduction was for a specific purpose - namely, that of testing.
>
>
> There are several options, and I'd love to get feedback and/or use cases from people to influence how this works.
>
>
> 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?
>   - On most OSes, installing a root cert requires admin privileges, to reduce the risk of malware/underprivileged attacks. Having this Chrome flag is a way to actively abuse this security, without really effective mitigation strategies.
>
>
>
>
> Possible Changes:
> - Remove it entirely.
>   - This is my preferred solution
>
>
> - Redefine what "ignore" means
>   - Right now, it has the effect of making it "as if" the user clicked through an HTTPS warning.
>   - This means that some features are disabled (SPDY/QUIC coalescing, the HTTP cache, password autofill)
>   - Instead, we'd change it to mean "As if there never was an error in the first place" (e.g. making this flag MORE dangerous)
>   - This has been requested by some test teams at Google, but I'm not a fan of this
>
>
> - Require that you supply an explicit list of trust anchor files from disk
>   - That is, ONLY these trust anchors would be supported as trusted. Errors for other reasons (e.g. CN mismatch, expiry) would NOT be bypassed.
>   - We have code in net/base/test_root_certs to do this, but have so far intended to keep this out of "Release" Chrome and only in unit tests for security/complexity reasons
>
>
> - Require that you supply an explicit list of domains to ignore the errors for, rather than a blanket exception