You are right. This behavior is there. From the user perspective it
doesn't make sense to do client auth before a page starts to load. When
seer lands, we'll be preconnecting even more often and it could happen
that a client cert selection dialog box pops up even before a user
actually clicks a link or an awesome bar result.
However, from my point of view, client certs are used rarely and this is
not something we should be handling with a high priority.
I've created a bug 910207 to start the technical discussion on this.
On 8/26/2013 7:13 AM, Mark Hammond wrote:
> This is a followup to the thread "Forcing every request from a
> docShell to use LOAD_ANONYMOUS". In that thread, I mentioned on some
> issues I'm having with speculative connections and SSL authentication,
> but I no longer believe they are issues relating to LOAD_ANONYMOUS.
> In short, I now believe speculative connections alone can cause SSL
> authentication prompts, even (or particularly) when those speculative
> connections *are not* used.
> In one example that I can reproduce, we make a speculative connection
> to a site (and never attempt a real connection, so it never gets
> used.) Later, a timer fires to prune dead connections.
> nsHttpConnectionMgr::OnMsgPruneDeadConnections is called, which
> (indirectly) calls nsHttpConnection::IsAlive(), which tries to read 1
> byte from the stream with the PR_MSG_PEEK flag. We then end up in
> ssl_SecureRecv() which notices we haven't done the SSL handshake, so
> prompts for a certificate for authentication.
> IOW, simply checking if a socket is still alive may prompt for auth.
> Secondly, I *think* there's another example of this. A speculative
> connection ends up calling
> nsHttpConnectionMgr::nsHalfOpenSocket::OnOutputStreamReady() - and
> occasionally we enter the block at
> The comments from this block say:
> // if we are using ssl and no other transactions are waiting right now,
> // then form a null transaction to drive the SSL handshake to
> // completion. Afterwards the connection will be 100% ready for the next
> // transaction to use it.
> which is doing exactly what it describes - completing the SSL
> transaction, which prompts for auth - even though this was a
> speculative connection.
> Does this sound correct? If so, what can we do about it? (I'll
> refrain from speculating until people who actually know what they are
> talking about chime in :)
> Any thoughts or insights?
> dev-tech-network mailing list