x.509 certificate auth mechanism: support (some) SANs of type otherName

[michaelklishin]

Note that the type by definition contains arbitrary values. According
to the OTP types, they are triplets that represent effectively
a key/value pair. So we assume the pair is a string that needs a bit
massaging, namely stripping the UTF encoding prefix OTP AnotherName
decoder leaves in.

Kudos to @Thibi2000 for providing an example value.

Closes #2983.

[michaelklishin]

Backported to v3.8.x.

[Thibi2000]

There seems to be an issue with using utf8 string as usernames. I tested it with the following username: uþðsername

This results in the user being made:

2021-04-19 08:55:15.297698+02:00 [info] <0.460.0> Importing concurrently 1 users...
2021-04-19 08:55:15.297931+02:00 [debug] <0.455.0> Asked to set user tags for user 'uþðsername' to []
2021-04-19 08:55:15.300583+02:00 [info] <0.455.0> Successfully set user tags for user 'uþðsername' to []
2021-04-19 08:55:15.300664+02:00 [info] <0.455.0> Clearing password for 'uþðsername'
2021-04-19 08:55:15.302539+02:00 [info] <0.460.0> Importing concurrently 1 vhosts...
2021-04-19 08:55:15.302799+02:00 [info] <0.460.0> Importing concurrently 1 permissions...
2021-04-19 08:55:15.302965+02:00 [debug] <0.455.0> Asked to set permissions for 'uþðsername' in virtual host '/' to '.*', '.*', '.*'
2021-04-19 08:55:15.304885+02:00 [info] <0.455.0> Successfully set permissions for 'uþðsername' in virtual host '/' to '.*', '.*', '.*'
2021-04-19 08:55:15.305205+02:00 [info] <0.460.0> Ready to start client connection listeners
2021-04-19 08:55:15.305992+02:00 [debug] <0.460.0> Started Ranch

Stripping away the first 2 characters, which are different in this case:

2021-04-19 08:55:23.946225+02:00 [info] <0.644.0> accepting AMQP connection <0.644.0> (127.0.0.1:40496 -> 127.0.0.1:5671)
2021-04-19 08:55:24.014228+02:00 [debug] <0.644.0> Peer certificate SANs of type other_name: [{otherName,
2021-04-19 08:55:24.014228+02:00 [debug] <0.644.0>                                             {'AnotherName',
2021-04-19 08:55:24.014228+02:00 [debug] <0.644.0>                                              {1,3,6,1,4,1,34907},
2021-04-19 08:55:24.014228+02:00 [debug] <0.644.0>                                              <<12,16,117,195,131,194,190,195,
2021-04-19 08:55:24.014228+02:00 [debug] <0.644.0>                                                131,194,176,115,101,114,110,
2021-04-19 08:55:24.014228+02:00 [debug] <0.644.0>                                                97,109,101>>}},
2021-04-19 08:55:24.014228+02:00 [debug] <0.644.0>                                            {otherName,
2021-04-19 08:55:24.014228+02:00 [debug] <0.644.0>                                             {'AnotherName',
2021-04-19 08:55:24.014228+02:00 [debug] <0.644.0>                                              {1,3,6,1,4,1,34907},
2021-04-19 08:55:24.014228+02:00 [debug] <0.644.0>                                              <<"\f\randere-waarde">>}}], index to use with lists:nth/2: 1

Note that I added another otherName which has the value andere-waarde and that 12,14 became 12,16 and \f\r. Stripping away the first 2 characters leads to: uþðsername, which makes it obvious that the authentication will fail. But I am using a utf8 string as login so there is no need to strip them away. I changed the code so it doesn't do it, which results in:

2021-04-19 08:55:24.015413+02:00 [error] <0.644.0> Error on AMQP connection <0.644.0> (127.0.0.1:40496 -> 127.0.0.1:5671, state: starting):
2021-04-19 08:55:24.015413+02:00 [error] <0.644.0> EXTERNAL login refused: user '
                                                                                 uþðsername' - invalid credentials

which makes me believe that utf8 strings are not supported in rabbit_auth_mechanism_ssl or in the login process of rabbit as a whole. is this the way it is?

[michaelklishin]

@Thibi2000 you are doing something very niche and specific but making broad generalizations.

Usernames in RabbitMQ are sequences of bytes. Some protocols (AMQP 0-9-1 is one example) can have assumptions
about certain values being limited to ASCII (e.g. queue names). RabbitMQ simply follows the spec.

I haven't tried Unicode usernames. Virtual host names can contain Unicode characters. However, you cannot
generalize about RabbitMQ as a whole since you are working with my semi-broken, best effort decoder of values
that up until 30 minutes ago we did not fully understand.

[michaelklishin]

Stripping off the first two bytes is not correct. One value is a type tag, another is length but the length is not encoded as a single byte for obvious length limitation reasons.

#2985 changes the parsing mechanism to use whatever the built-in ASN.1/x.509 certificate format parser provides. It requires a value type which we cannot know, so we assume it is
one of the string types ("directory strings"), of which utf8String is one.

I tested it with strings varying from 4 to 390 characters and it works as expected. It obviously won't support
more than a few string types. I also tested it with a Cyrillic value and it is parsed but because Erlang shells
(unlike Elixir) are not great at displaying Unicode, I cannot say more than "things do not obviously fail". I'll
try with some accented Latin characters (e.g. à) next.

[michaelklishin]

Using the following otherName value

otherName = 1.3.6.1.4.1.54392.5.436;FORMAT:UTF8,UTF8String:unicøde-vàlüe

I can tell that it is parsed correctly in #2985. It also authenticates when I create a user and grant it some permissions:

rabbitmqctl add_user "unicøde-vàlüe"
rabbitmqctl set_permissions -p / "unicøde-vàlüe" ".*" ".*" ".*"

[michaelklishin]

I do not expect anyone to do this but a Cyrillic value ("кролик") works as well. So as long as the value is of the type utf8string, it is parsed correctly and the rest of RabbitMQ doesn't care (a sequence of bytes is a sequence of bytes).