[rabbitmq-discuss] Request Handshake Timeout Increase
Matthias Radestock
matthias at rabbitmq.com
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.
More information about the rabbitmq-discuss
mailing list