"SSL_read: nested asn1 error" after calling "value" on cert extension

[Garrett Thornburg]

This is a continuation of the discussion at: https://github.com/ruby-amqp/bunny/pull/578

Configuration options:

1. `tls: true, verify_peer: false, there's a custom CA cert added, no client cert/key.

2. Rabbitmq has the following options:

    {ssl_options, [
                   {cacertfile,"/etc/path/to/ssl/certs/ca.pem"},
                   {certfile,"/etc/path/to/ssl/certs/certfile.pem"},
                   {keyfile,"/etc/rabbitmq/ssl/keyfile.pem"},
                   {verify,verify_none},
                   {fail_if_no_peer_cert,false}
                   ,{versions, ['tlsv1.2']}
                  ]},

Error: 

When we go to create a new connection using bunny (> 2.13.0), we call `x.value` in `peer_certificate_info`:

peer_cert.extensions.map { |x| x.value }

We end up with an `SSL_read: nested asn1 error (OpenSSL::SSL::SSLError)` error:

         8: from /home/film42/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/bunny-2.14.1/lib/bunny/session.rb:317:in `start'
         7: from /home/film42/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/bunny-2.14.1/lib/bunny/session.rb:1164:in `init_connection'
         6: from /home/film42/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/bunny-2.14.1/lib/bunny/transport.rb:261:in `read_next_frame'
         5: from /home/film42/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/bunny-2.14.1/lib/bunny/transport.rb:239:in `read_fully'
         4: from /home/film42/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/bunny-2.14.1/lib/bunny/cruby/ssl_socket.rb:44:in `read_fully'
         3: from /home/film42/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/bunny-2.14.1/lib/bunny/cruby/ssl_socket.rb:44:in `loop'
         2: from /home/film42/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/bunny-2.14.1/lib/bunny/cruby/ssl_socket.rb:45:in `block in read_fully'
         1: from /home/film42/.rbenv/versions/2.5.1/lib/ruby/2.5.0/openssl/buffering.rb:182:in `read_nonblock'
/home/film42/.rbenv/versions/2.5.1/lib/ruby/2.5.0/openssl/buffering.rb:182:in `sysread_nonblock': SSL_read: nested asn1 error (OpenSSL::SSL::SSLError)

I attached the rabbitmq server cert and a few commands reading the file off disk to show the cert appears to be valid: https://gist.github.com/film42/2ea9a04363155d48f363e7d9078f1b3a

Additionally: 

- This was failing on ruby 2.3.X using openssl 1.0.1f (bunny client and rabbitmq are using the same openssl version).

- This was also failing using ruby 2.5.1 using OpenSSL 1.1.1b. 

[Michael Klishin]

The "Netscape Comment" extension is the only thing that stands out. Curiously it does have a value that Ruby's OpenSSL can parse.

My best guess right now is that early eager evaluation of certificate data could lead to an incomplete ASN.1 sequence evaluation.

You can see that the exception is thrown after a TLS socket read :/

I cannot try it today but will when I get back online.

--
Bunny: http://rubybunny.info
March Hare: http://rubymarchhare.info
 
IRC: #rabbitmq on irc.freenode.net
 
Post to the group: ruby...@googlegroups.com | unsubscribe: ruby-amqp+...@googlegroups.com
---
You received this message because you are subscribed to the Google Groups "Ruby RabbitMQ libraries" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ruby-amqp+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

MK

Staff Software Engineer, Pivotal/RabbitMQ

[Michael Klishin]

I've modified tls-gen's basic profile [1] locally to be as close as practically possible to the certificate in question:

https://gist.github.com/michaelklishin/c0cc6bbed44d7335c24cc2bf2fac024d

and I cannot reproduce the issue after locally reverting bunny#578. Bunny successfully connects on Ruby 2.6.0 with OpenSSL

1.0.2q (from 20 Nov 2018) against a RabbitMQ using Erlang 21.3.2 with the same OpenSSL version (that said, Erlang only uses OpenSSL for crypto functions

and not e.g. TLS state machine implementation):

>> dir = "/path/totls-gen.git/basic/result/"; c = Bunny.new(log_level: "debug", hostname: "localhost", port: 5671, tls: true, tls_ca_certificates: ["#{dir}/ca_certificate.pem"]); c.start
D, [2019-04-08T13:40:12.211870 #82967] DEBUG -- #<Bunny::Session:0x7f871fa36468 guest@localhost:5671, vhost=/, addresses=[localhost:5671]>: Using CA certificates at /path/to/tls-gen.git/basic/result//ca_certificate.pem
D, [2019-04-08T13:40:12.211968 #82967] DEBUG -- #<Bunny::Session:0x7f871fa36468 guest@localhost:5671, vhost=/, addresses=[localhost:5671]>: Using 0 inline CA certificates
W, [2019-04-08T13:40:12.224178 #82967]  WARN -- #<Bunny::Session:0x7f871fa36468 guest@localhost:5671, vhost=/, addresses=[localhost:5671]>: Using TLS but no client certificate is provided. If RabbitMQ is configured to require & verify peer
certificate, connection will be rejected. Learn more at https://www.rabbitmq.com/ssl.html

D, [2019-04-08T13:40:12.224244 #82967] DEBUG -- #<Bunny::Session:0x7f871fa36468 guest@localhost:5671, vhost=/, addresses=[localhost:5671]>: Will use peer verification mode 3
D, [2019-04-08T13:40:12.251443 #82967] DEBUG -- #<Bunny::Session:0x7f871fa36468 guest@localhost:5671, vhost=/, addresses=[localhost:5671]>: Peer's leaf certificate subject: /CN=warp10/O=server, subject alternative names: warp10, DNS:warp10.local, DNS:localhost, issuer: /CN=TLSGenSelfSignedtRootCA/L=$$$$, not valid after: 2029-04-05 09:28:02 UTC, X.509 usage extensions: CA:FALSE, Digital Signature, Key Encipherment, TLS Web Server Authentication, TLS Web Client Authentication, DNS:warp10, DNS:warp10.local, DNS:localhost, 1E:9B:15:FF:09:97:2F:5A:33:89:28:8B:12:CA:61:A0:56:1A:FA:FB, keyid:BB:C2:05:BD:BC:9B:BB:84:EB:C0:82:E1:D6:A1:7F:70:E3:8B:0D:1E
, .(Puppet Ruby/OpenSSL Internal Certificate
D, [2019-04-08T13:40:12.251773 #82967] DEBUG -- #<Bunny::Session:0x7f871fa36468 guest@localhost:5671, vhost=/, addresses=[localhost:5671]>: Peer's certificate chain entry subject: /CN=warp10/O=server, subject alternative names: warp10, DNS:warp10.local, DNS:localhost, issuer: /CN=TLSGenSelfSignedtRootCA/L=$$$$, not valid after: 2029-04-05 09:28:02 UTC, X.509 usage extensions: CA:FALSE, Digital Signature, Key Encipherment, TLS Web Server Authentication, TLS Web Client Authentication, DNS:warp10, DNS:warp10.local, DNS:localhost, 1E:9B:15:FF:09:97:2F:5A:33:89:28:8B:12:CA:61:A0:56:1A:FA:FB, keyid:BB:C2:05:BD:BC:9B:BB:84:EB:C0:82:E1:D6:A1:7F:70:E3:8B:0D:1E
, .(Puppet Ruby/OpenSSL Internal Certificate
D, [2019-04-08T13:40:12.252466 #82967] DEBUG -- #<Bunny::Session:0x7f871fa36468 guest@localhost:5671, vhost=/, addresses=[localhost:5671]>: Peer's certificate chain entry subject: /CN=TLSGenSelfSignedtRootCA/L=$$$$, subject alternative names: , issuer: /CN=TLSGenSelfSignedtRootCA/L=$$$$, not valid after: 2029-04-05 09:28:02 UTC, X.509 usage extensions: Certificate Sign, CRL Sign, BB:C2:05:BD:BC:9B:BB:84:EB:C0:82:E1:D6:A1:7F:70:E3:8B:0D:1E, keyid:BB:C2:05:BD:BC:9B:BB:84:EB:C0:82:E1:D6:A1:7F:70:E3:8B:0D:1E
, CA:TRUE

So unless someone has more steps to recommend or can provide a traffic capture that demonstrates the issue, this one will

have to remain a mystery worked around by bunny#578.