Would you mind to provide sample network details? as described in the following instructions:

   http://www.chromium.org/for-testers/providing-network-details

No need for net-internals and it wouldn't capture this anyway. chrome.sockets.tcp.secure does not support client certificates, so this is expected. I don't know if we have a bug on file anywhere for adding support to duplicate this to, so I guess this can be it? Unless we want to just close this outright.

Adding extensions tag, but extensions folks: do not add any API to support this without consulting with SSL folks. Client certificates are a mess and depending on what you want your API to do in the first place, you may open up fun and exciting security holes. Notably, prompting to use the system store would almost certainly be a bad idea.

Right, this was an intentional design decision for exposing the Sockets APIs.

Chrome Apps should not have access to the system or profile resources; we discussed the possibility of allowing Apps to specify their own certs, but that's not a priority and unlikely to happen.

Okay, is it possible that we can get Channel-ID/Token Binding available for this API?

With that at least we could build something that worked.

Thanks!

No. That's even less likely to be exposed, as that's an even more unstable and problematic API.

Marking this as Needs-DesignDoc and Needs-Feedback - Apps/Extensions would need to weigh in, but I'm strongly opposed to exposing Channel ID/Token Binding. There are things we could do for certs, potentially, but that's still a big discussion and I don't think Apps/Extension API teams are taking on new feature enhancements for this.

regarding comment 3, are you saying with your comment that it's by design that the SSL subsystem is never going to let us connect to a server that requests but doesn't require a client certificate? the point here is that currently using the SSL API for chrome.sockets.tcp fails when connecting to freenode just because freenode has the option to use client certificates. This is broken in my opinion: even if Chrome doesn't allow us to use client certificates it should still try to connect to an SSL socket without one. If the API is not allowed to prompt the user and default to not selecting a certificate then the api should still attempt the connection, which it currently does not.

The example of freenode is that when using chrome.sockets.tcp.secure the connection can never be established as things currently stand because the freenode implementation allows authentication via client certificate. Freenode does NOT REQUIRE client certificate yet the connection still cannot be established via the API!

re: #6, that's enough of a distinct request that I'd ask you to file a separate bug. I think it's reasonable that in the absence of client certificate support, we continue trying to send w/o, but we should follow-up that design discussion separately from supporting client certs in the affirmative case.

Marking Needs-Feedback again - it's needing feedback from Extensions folks.

Mike: Could someone from Apps/Extensions review this (see comment #5/#6/#7)

Question: When encountering a server that requests, but does not require, a client certificate, there are two possible options: We can fail the connection immediately (present behaviour) or attempt to continue without it (proposed behaviour). Both have trade-offs - the proposed behaviour will lead to observably different behaviour that may make it hard for apps developers to debug, but may also make it easier for cases like optional certs that can't be supported with the present behaviour.

As for Channel ID, Token Binding, and Client Certs, I remain strongly opposed to exposing that from the default store (it would be akin to exposing raw login credentials to Apps/Extensions, as that's what client certs are), but there is the possibility of allowing Apps/Extensions to provide and store their own client certificates (such as via an App Manifest or the like). But that's a rather sizably new feature that is somewhat more questionable.

Assigning to rpaquay@ for triage as OWNER of sockets.tcp.

+ppl that are interested in the outcome.

If a server supports both page navigation and websockets and if we first do successful client cert auth via page then attempt websocket connection, then websocket connection goes through fine. See my comment on: https://bugs.chromium.org/p/chromium/issues/detail?id=329884#c36 and its response.

Is there any chance similar behavior can be achieved via chrome.socket(s) API given the case where TLS connection is made to same website?

I think ideally we should be able to tie in chrome.platformKeys.selectClientCertificates with chrome.sockets.tcp.secure API. We could then do client cert auth without relying on browser caching. App could also try this only when error from socket mentions client cert auth is mandatory.

No, the chrome.socket API absolutely cannot interact with the browser's login state. This would invite every CSRF vulnerability imaginable against client cert sites.

I assume you are talking about allowing connection without cert prompt silently or is it applicable even when using both APIs together. APIs can't be used together today, but needs an enhancement.

BTW websocket connection goes through ok from an app even though user only authenticated in a browser tab.

WebSockets are different. Those participate in the same-origin policy. Giving a raw socket does not.

I'm specifically talking about using the fact that the client cert has been used in a browser. It would be a security vulnerability if that state interacted with chrome.socket client cert state.

Assigning to benwells@ for apps triage.

davidben@ is right. Apps should share no state with the browser.

It seems like there is a valid thing to do here: as per comment #10, we probably should attempt to continue without a client cert, if the client cert is optional.

Unfortunately I don't think anyone is actively developing this API. I'm going to mark this WontFix, as it is valid but we have nobody to do it. Also adding kuscher@ and abodenha@ who might be inclined to find someone for this.

"it is valid but we have nobody to do it."

Seriously? That's a terrible reason to mark it as won't fix. Leave it in the queue until you have someone to fix it for chrisake!