rdevlin: This is working as intended/intentionally designed when we exposed the socket API (further context: read http://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html )

I'd like to close explicitly as WontFix/WAI, but I'll let you make the call. Expect much pushback though if that isn't the case ;)

I'd be inclined to agree.  I'm cc'ing some other folks who may have opinions, but I'd say this is WAI.

rpaquay@ - sockets API OWNER
xiyuan@ - chrome apps input

How do I implement certificate pinning in this case? So the user could enter public key of the server so he is allowing the app to connect to the server.

On the other hand, you are making it possible in Chrome to the user to open a tab with invalid certificate. So when the user accept the risk he can proceed. I'd like to see a similar behaviour for apps.

I realize that this may affect really small amount of apps but it's huge use case for my app and in case of debugging restful services it is affecting huge amount of people. Only my app is used by over a million users. Another app - Postman - that could use this as well - another million users. Just take it into account.

I am inclined to agree this is a WAI as well.

The app in question is a development tool. I don't see why developers have to talk to servers with bad certs. Would adding "--allow-insecure-localhost" to Chrome command line and binding test servers to localhost work around the problem?

Partially maybe it is a solution. However in case when developers use some  server in local network with FQDM (like https://dev.api.app.com) it won't do much.

I agree that developers should use valid certificates and I don't really care about the ones who are using for example expired certificates. But in case of self-signed certificates - that I can imagine is very common - I have no reason to prohibit them of using it. 

I would instruct the users to setup new profile and run it with '--ignore-certificate-errors' flag but I tried it and it's not working. I'm not sure if this flag working though. 

re: Comment #4: Implementing certificate pinning doesn't require the ability to override errors, it requires the ability to override non-errors and inject an error. We have had high-level talks about how an API might look, but that's not currently prioritized or planned, and there's different security tradeoffs about Apps vs Extensions. Given the interaction that Extensions have with the rest of Chrome networking, I think it will be extremely unlikely such an API would be exposed to them, and until some bugs are fixed with how Apps handle networking/socket pools, it's not likely to happen for Apps either.

As mentioned earlier, the ability for Apps (or Extensions) to override SSL errors leads to a whole host of security issues. While we can totally understand the desire, we also want to avoid encouraging insecure practices, which such an API inherently does.

We're aware that this limits certain kinds of apps from being viable. For example, IMAP servers that serve invalid certificates (as many do) prevent a Chrome App from being an IMAP reader. The solution to that problem is to obtain a valid certificate.

Even for debugging/diagnostic purposes, services such as LetsEncrypt or StartSSL offer viable paths to get trusted certificates for your testing/diagnostic needs, without requiring any security-harming flags or APIs. With such services, even the need for self-signed certificates is not a concern.

Also, note that --ignore-certificate-errors is a flag that (intentionally) does not have global effect, and is not meant to address your use case. There are no plans to expand on the ability to use the command-line to override SSL errors.

Thank you for very detailed answer. I totally understand.

I guess my work now is to educate and promote good practices among my users which I think is quite important.

per discussion, closing as WAI.