[rabbitmq-discuss] Request Handshake Timeout Increase

Mon May 14 11:47:17 BST 2012

James,

On 10/05/12 19:53, james.poole at rsa.com wrote:
> Yeah, the simple fix would be to just add our root CA to the Windows Trust
> Store as a "trusted CA".  However, this is not what we want to do, since this
> would be a security risk.  We don't want the entire machine to trust our CA,
> but we want only our product (rabbit client) to trust the CA.  (This is going
> to be in customer environments who are sensitive to security... not an
> internal deployment)
>
> When the internet is available on the machine, the .NET client fails to find
> the CA, but then our registered certificate validation callback is run, and we
> can manually inspect the certificate, validate it is "our" certificate, and
> let the SSL handshake proceed.
>
> If the internet is not available, the 15 second delay causes the handshake to
> time out and close the SSL connection before we get a chance to handle the
> certificate validation.

So there is no way to preempt the cert retrieval, other than altering 
the machine-wide policy? That seems like a major omission in the .net 
SSL API. Having every connection take 15+ seconds to get established may 
be ok in your particular app but could be a showstopper in many other cases.

> To get around this, we would just need the timeout (pointed out by Emile -
> http://hg.rabbitmq.com/rabbitmq-server/file/e852cd4060d3/src/rabbit_reader.erl#l30)
> to be relaxed to 20 seconds.  This would give the client enough time to wait
> for the Windows 15 second delay, verify the certificate, and allow the SSL
> connection to be established.

As Emile mentioned, there are actually two timeouts:

1) ssl upgrade. This covers the upgrading of the tcp connection to ssl 
and should include all ssl handshaking. It's set to 5 seconds.

2) AMQP connection establishment. This covers the entire AMQP connection 
establishment handshake. It is set to 10 seconds and starts *after* the 
ssl upgrade has been completed.

 From the description of the problem I would expect you to encounter the 
*first* timeout, which result in a "error on AMQP connection ...: 
<Reason>" message in the logs. However, you said you are seeing a 
handshake_timeout error, which is raised by the *second* timeout. That 
is weird. Are you sure that is the error you saw?

Regards,

Matthias.