[rabbitmq-discuss] Request Handshake Timeout Increase

[james.poole at rsa.com]

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.

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.

-James

-----Original Message-----
From: Matthias Radestock [mailto:matthias at rabbitmq.com]
Sent: Tuesday, May 08, 2012 2:08 PM
To: Poole, James
Cc: rabbitmq-discuss at lists.rabbitmq.com
Subject: Re: [rabbitmq-discuss] Request Handshake Timeout Increase

James,

On 08/05/12 15:42, james.poole at rsa.com wrote:
> It turns out that Microsoft has a default policy that tries to connect
> to Windows Update on the internet to validate Certificate Authorities.
> If the client machine is not connected to the internet (our likely
> customer deployment scenario and our development environment), then this
> can cause a 15 second delay when validating certificates. Since the
> RabbitMQ handshake timeout is 10 seconds, then this fails and closes the
> connection. This was only seen from the .NET client, and not the Java
> client.
>
> I verified that disabling the local machine policy (directions here
> http://technet.microsoft.com/en-us/library/cc749331%28v=ws.10%29.aspx)
> allowed the SSL connection to immediately succeed.

 From the description of that policy it sounds like disabling would
cause connections to fail:
<quote>
If the user is presented with a certificate issued by a root
certification authority that is not directly trusted, and the Update
Root Certificates feature is turned off through Group Policy, the user
can be prevented from completing the action that required authentication.
</quote>

Though this may depend on the policy settings of the app. Have you
looked at http://www.rabbitmq.com/ssl.html#trust-dotNET?

Also, the policy appears to only come into play when hitherto unknown
root certificates are encountered. So it should be possible to avoid
that situation by getting a server certificate with a root CA that
Windows trusts by default.


Matthias.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7449 bytes
Desc: not available
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120510/4458910e/attachment.bin>