[rabbitmq-discuss] CRL support

[Tim Watson]

Bala,

A few things....

1. the verify_fun is an option that Erlang's SSL application takes, not a rabbit specific item


On 8 Oct 2013, at 01:23, Balachandher Srinivasan wrote:
> 1. Erlang adopted a more elegant way to express higher order functions (funs), based on http://www.erlang.org/eeps/eep-0023.html.  So, {Module, Function} would be typically represented as Module:Function/Arity
> 

You can't always do that in a config file - it depends on whether you have literals or are trying to use bound variables (where no binding exists). See http://www.erlang.org/doc/man/config.html for details, but basically the file needs to conform to the same specification that file:consult/1 uses - see http://www.erlang.org/doc/man/file.html#consult-1 for more details. If you can't execute `file:consult("/path/to/your/rabbit/config")' then the config file isn't valid.

> 2. Based on the EEP mentioned above and the SSL documentation, I was able to write a test program and validate CRL successfully by referring a function either internally within the same module or from an external module. For internal module's function, I used the form, {verify_fun, {fun validate/3, []}}; for external module's function, I used the form {verify_fun, {fun cert_util:validate/3, []}}.
> 

That won't work in a config file. To test this for yourself, create a text file containing just that term:

$ echo '[{verify_fun, {fun lists:foldl/3, []}}].' >> foo.config

And try to parse it in the shell:

Eshell V5.10.2  (abort with ^G)
1> file:consult("foo.config").
{error,{1,erl_parse,"bad term"}} 

> 3. After successfully writing a test program, I tried to apply the same in rabbitmq; however, rabbitmq was unable to start and I witnessed the following in the logs,
> /var/log/rabbitmq/startup_log
> {"could not start kernel pid",application_controller,"error in config file \"/etc/rabbitmq/rabbitmq.config\" (1): bad term"}
> 
> /var/log/rabbitmq/startup_err
> Crash dump was written to: erl_crash.dump
> could not start kernel pid (application_controller) (error in config file "/etc/rabbitmq/rabbitmq.config" (1): bad term)
> 

This indicates that the config file contains invalid syntax. As I said, the `fun Mod:Func/Arity' syntax isn't valid in a system configuration file. 

> 4. It was clear from the above that rabbitmq was unable to take the EEP-23 form for verify_fun; so I tried reverting back the funs to old type of the form {Module, Function}.   When I tried restarting, while it gave no errors and started successfully, my CRL validation function was never called.
> 

Looking at https://github.com/erlang/otp/blob/master/lib/ssl/src/ssl_handshake.erl#L359, it seems likely that the user fun isn't called since as the documentation states:

"The verify fun will be called during the X509-path validation when an error or an extension unknown to the ssl application is encountered. Additionally it will be called when a certificate is considered valid by the path validation to allow access to each certificate in the path to the user application."

> 5. RabbitMQ site suggests that in order to use SSL reliably use R14B(erts 4.0.1) as the minimum version.  I tried using R16B (erts-5.10.1) on 64-bit Cent OS, which internally uses ssl-5.2.1.  Also, I tried R16B01(erts-5.10.2) on 64-bit Windows 7, which internally uses ssl-5.3.1.  Between these versions, there are lot of bugs fixed and enhancements applied in SSL application http://www.erlang.org/doc/apps/ssl/notes.html.  
> 
> To summarize, though RabbitMQ states R14B as the minimum version for reliable SSL, I wonder whether it is compatible with the latest SSL available in the recent Erlang distributions.
> 

I don't see any incompatibility - Rabbit does little more than forward the options you've provided to the SSL application. It looks to me like this problem has more to do with how the SSL application handles the validate_fun. I'd suggest asking on the erlang-questions mailing list to see if you can get some more guidance there - unless someone else on rabbit-discuss has come across this before and can say more about it.

If/when you find out the cause, please share the outcome with us!

Thanks,
Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20131008/d64d7ebf/attachment.htm>