Re: [chromium-dev] SSL renegotiation workflow for Chrome

[Ryan Sleevi]

On Mon, Jun 17, 2013 at 12:21 AM, Niall Gallagher
<gallagh...@gmail.com> wrote:
> Hi,
>
> I have a rather specific question on the workflow used by Chrome in dealing
> with SSL renegotiations. I hope this is to correct mailing list, it requires
> some detailed technical knowledge.
>
> I have noticed a very strange workflow for SSL renegotiations which seems to
> be used by Chrome, and also used by other browsers such as IE. I have tested
> a number of scenarios to try to get SSL renegotiation to work, both result
> in unexpected results.
>
> 1) I connect Chrome to the HTTPS server, browse a couple of resources under
> the security of SSL and then I hit a highly secure resource, I then send a
> HTTP response, and follow that fulfilled HTTP response with an SSL hello
> from the server to initiate a renegotiation. Here Chrome sends a TCP FIN
> straight away and renegotiation fails.

By "highly secure", I'm guessing you mean "Requests a client certificate".

The default behaviour of Chrome upon receiving a client certificate
request that it has not cached the answer for is to abort the request
(disconnecting the socket) and prompt the user. This is done primarily
because prompting the user is a task with unbounded time, and many
servers themselves do not behave well with such 'hung' sockets.

For comparison, Firefox will keep the existing socket open for 15
seconds (IIRC) before disconnecting.

If I'm understanding correctly, the HelloRequest (the server's attempt
to get the client to initiate renegotiation) is not sent until *full*
response data is received? Or have I misunderstood your timeline?

>
> 2) I connect Chrome to the HTTPS server, browse a couple of resources under
> the security of SSL and then I hit a highly secure resource, before serving
> the response I send an SSL hello and initiate a handshake, here the
> handshake proceeds, until Chrome pops up a dialog and asks for the SSL
> certificate to be selected. At this point a TCP FIN is send and the channel
> is closed. Once the certificate is selected Chrome opens up a new connection
> and waits the status bar shows the typical "waiting.....". It does not
> resend the HTTP request that was sent on the connection it terminated. Its
> as if it expects the server to know to send the response for the original
> request??

I'm not sure I follow this description. Chrome will immediately abort
the request (that requested client cert negotiation), disconnect the
socket, prompt the user, and have the user select a certificate. Once
a user has selected a certificate, it will attempt to establish a
*new* connection to the server AND retry the original (aborted)
request.

Perhaps you can attach a Wireshark or chrome://net-internals log on a
new bug demonstrating the problem, because Chrome's client certificate
behaviour certainly doesn't behave as you've described, so either it's
a bug or I've misunderstood you.

>
> Is this the workflow, does Chrome really terminate the SSL connection when a
> user selects the certificate and then expect some sort of spontaneous
> response from the server when it reconnects with the certificate and posts
> no request???
>
> I have trawled the net for an answer, and RFC, something on this to no
> avail. I would appreciate help from anyone has some knowledge of this.
>
> Thanks,
> Niall
>
> --
> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
>
>
>