--management-external-key sometimes requests signatures for too long data

[jarit]

According to https://openvpn.net/index.php/open-source/documentation/miscellaneous/79-management-interface.html, the ">RSA_SIGN" notification should be responded with "rsa-sig" command where the signature should be a "Base64 encoded output of RSA_sign(NID_md5_sha1,... ".

The normal case is that OpenVPN requests signatures for 36 bytes of data, but with some clients we see a notification requesting a signature for 83 bytes:

>RSA_SIGN:MFEwDQYJYIZIAWUDBAIDBQAEQGOZtLwchpQ0BVWxcSizpYpAEoVi/B8tGMYuj374VsmPQ1GUMiIbggdX7apKK7+x5FgVTqCCi+T/1EGZU1zIYn4=

OpenSSL RSA_sign with NID_md5_sha1 expects that the data is exactly 36 bytes and will refuse to sign this and gives an error about invalid message length:
​https://github.com/openssl/openssl/blob/608a026/crypto/rsa/rsa_sign.c#L88

Either the documentation is wrong and the signature should be generated in another way or the request for signing 83 bytes is a bug.

This seems to happen only with certain clients/versions (Android) and is reproducible always with those.

OpenSSL version is 1.0.2d and OpenVPN version:

OpenVPN 2.3.12 arm-poky-linux-gnueabi [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Nov  9 2016
library versions: OpenSSL 1.0.2d 9 Jul 2015, LZO 2.09
Originally developed by James Yonan
Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <sales@openvpn.net>
Compile time defines: enable_crypto=yes enable_crypto_ofb_cfb=yes enable_debug=yes enable_def_auth=yes enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=yes enable_fragment=yes enable_http_proxy=yes enable_iproute2=no enable_libtool_lock=yes enable_lzo=yes enable_lzo_stub=no enable_management=yes enable_multi=yes enable_multihome=yes enable_pam_dlopen=no enable_pedantic=no enable_pf=yes enable_pkcs11=no enable_plugin_auth_pam=no enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_small=no enable_socks=yes enable_ssl=yes enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=no enable_win32_dll=yes enable_x509_alt_username=no with_crypto_library=openssl with_gnu_ld=yes with_lzo_headers=/include with_lzo_lib=/lib with_mem_check=no with_plugindir='$(libdir)/openvpn/plugins' with_ssl_headers=/include with_ssl_lib=/lib with_sysroot=no

[Gert Döring]

@syzzer: any idea?

[Steffan Karger]

The documentation is wrong (or actually, not up to date). What is happening is that you client and server negotiate TLS 1.2, which no longer restricts transcript digests to SHA1_MD5. Instead a stronger digest like SHA256 or SHA384 is likely negotiated.

I'll put this on my list, but can't make promises on the timeline. So, if anyone else want to take a stab at it: patches are welcome.

[Steffan Karger]

BTW, if your management software can't deal with this, you can (temporarily, please) disable TLS 1.2 until you've updated the software, by setting tls-version-max 1.1 in the openvpn config (either server or client).

[jarit]

Thanks for the prompt response. As a workaround, could you then briefly instruct on what is the correct way to generate the signature in case of TLS 1.2 ?

[jarit]

And also, if TLS 1.2 allows multiple different digests, how should the management software know what kind of signature to generate? Based on the data length?

[Steffan Karger]

The management software is expected to simple create a PKCS#1 1.5 signatures, as described here: ​https://tools.ietf.org/html/rfc3447#section-8.2. (In most crypto libraries this is known as a 'raw rsa signature'.) See ​https://tools.ietf.org/html/rfc5246#section-4.7 for a little extra context.

The OpenVPN software already calculates the correct digest, and does all the proper formatting of metadata. All the management software has to do is create the PKCS#1 signature. (I.e. you don't need to know anything about the used digest.)

[jarit]

Thanks. That makes it clear and simple. OpenSSL method RSA_private_encrypt() with RSA_PKCS1_PADDING seems to do the job.

[Steffan Karger]

I just sent a patch to the list to update the documentation:

Samuli, can you look into updating the web page once this patch has been applied?

[Gert Döring]

So I think I can close this ticket now? Web page documentation for management-notes has been updated just recently.