From:  Honza Bambas <>
Date:  28 Aug 2013 21:00:29 Hong Kong Time

Re: Speculative connections and SSL auth.


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?
> Thanks,
> Mark
> _______________________________________________
> dev-tech-network mailing list