| Message ID | 20181007215837.489-1-arne@rfc2549.org |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [Openvpn-devel] Add support for OpenSSL TLS 1.3 when using management-external-key | expand |
Hi, Not a review, but some thoughts: On Sun, Oct 7, 2018 at 5:59 PM Arne Schwabe <arne@rfc2549.org> wrote: > > For TLS 1.0 to 1.2 OpenSSL calls us and requires a PKCS1 padded > response, for TLS 1.3 it requires to an unpadded response. Since we > can PCKS1 pad an unpadded response, we prefer to always query for > an unpadded response from the management interface and add the PCKS1 > padding ourselves when needed. First, one clarification: The reason for unpadded response is that when PSS padding is in use, OpenSSL adds the padding and, thus, asks for raw RSA encryption (unpadded). This is because RSA_sign or rsa_priv_enc callbacks do not support a way of indicating PSS padding. In fact, OpenSSL 1.1.1 client talking to 1.1.1 server prefers PSS padding even for TLS 1.2, so this is not a TLS 1.3-only problem. > > This patch adds an 'unpadded' parameter to the management-external-key > option to signal that it is uses the new unpadded API. Since we cannot I do not particularly like this new option: "management-external-key-unpadded". Apart from the confusing name, this doesn't really address the basic limitation of the current pkey-sig (old rsa-sig) directive. We should have extended it when the new name was introduced. pkey-sig should pass not just the data (or hash) to sign but additional info like digest type in use, padding mode etc. Or have a way for the management client to query additional parameters that may be necessary for signing. Using padded data and requiring the external "engine" to do a raw signature may look like a way out of this but not really: not all external libraries may support such a usage. AFAICS, Windows CNG does not. Also some hardware devices may insist on doing the padding inside -- especially non-deterministic padding like PSS. So what about naming this "management-external-key-version2" and then extend pk-sig as below? pk-sig <base64-data-to-sign> [signing-algorithm] where the <signing algorithm> could be, say, SHA256_RSA_PKCS1 or NONE_RSA_PKCS1 or SHA384_RSA_PSS etc. If missing, and the key is RSA, the client can assume it is NONE_RSA_PKCS1 and expect the hash with digest-info header already added and sign as such. Or, if the key is EC, do the ECDSA signing operation as is being done now. The "unpadded" case could be indicated by NONE_RSA_RAW. These mnemonics are just examples -- we could use PKCS11 identifiers or something else. To get unpadded data we have to override sign() in EVP_PKEY_METHOD but that would also provide max flexibility. Now, I think its safe to just update and document this and require that management-interface clients that use the external key feature must update if using client compiled with OpenSSL 1.1.1. Android(?) and iOS (?) clients may be the only one's affected, but those are shipped as one complete package. I'm not aware of any standalone management-client UI that uses the external-key feature. > support TLS 1.3 without unpadded queries we disable TLS 1.3 otherwise. If we must do this, disabling TLS 1.3 will not enough. One way is to also explicitly set the padding mode to RSA_PKCS1_PADDING (for TLS1.2) EVP_PKEY_CTX_set_rsa_padding(ctx, pad) can do this. > > We also do the same for cryptoapi since it uses the same API. Let's just fix cryptoapi --- I'm working on it. Anyway it does not use the same API as external key and prepadded data (= nopadding) will not work with Windows. This'll have to be fixed before we release binaries linked with OpenSSL 1.1.1. > > Using the management api client version instead might seem like the > more logical way but since we only now that version very late, > it would extra logic and complexity to deal with this asynchronous > behaviour . IMO, we should explore this further and try to avoid --management-external-key-foo. Selva
Am 17.10.18 um 05:15 schrieb Selva Nair: > Hi, > > Not a review, but some thoughts: > > On Sun, Oct 7, 2018 at 5:59 PM Arne Schwabe <arne@rfc2549.org> wrote: >> >> For TLS 1.0 to 1.2 OpenSSL calls us and requires a PKCS1 padded >> response, for TLS 1.3 it requires to an unpadded response. Since we >> can PCKS1 pad an unpadded response, we prefer to always query for >> an unpadded response from the management interface and add the PCKS1 >> padding ourselves when needed. > > > First, one clarification: > > The reason for unpadded response is that when PSS padding is in use, > OpenSSL adds the padding and, thus, asks for raw RSA encryption > (unpadded). This is because RSA_sign or rsa_priv_enc callbacks > do not support a way of indicating PSS padding. In fact, OpenSSL > 1.1.1 client talking to 1.1.1 server prefers PSS padding even for > TLS 1.2, so this is not a TLS 1.3-only problem. Ah did not get that extra problem. >> This patch adds an 'unpadded' parameter to the management-external-key >> option to signal that it is uses the new unpadded API. Since we cannot > > I do not particularly like this new option: > "management-external-key-unpadded". Apart from the confusing name, > this doesn't really address the basic limitation of the current > pkey-sig (old rsa-sig) directive. We should have extended it when the > new name was introduced. pkey-sig should pass not just the data (or > hash) to sign but additional info like digest type in use, padding > mode etc. Or have a way for the management client to query additional > parameters that may be necessary for signing. Yes. But we still need a way to signal the capabilities of the management client to OpenVPN, otherwise we will query for a signature that we might not support. How about adding the supported signatures as parameters? E.g. management-external-key pkcs1 raw pss > Using padded data and requiring the external "engine" to do a raw > signature may look like a way out of this but not really: not all external > libraries may support such a usage. AFAICS, Windows CNG does not. Also > some hardware devices may insist on doing the padding inside -- > especially non-deterministic padding like PSS. I have kind of the opposite problem. At least older Android version do not expose signing with PSS. So I have to sign with a raw signature anyway. And I would like to avoid implementing PSS in OpenVPN. > > So what about naming this "management-external-key-version2" and then > extend pk-sig as below? > > pk-sig <base64-data-to-sign> [signing-algorithm] Sure, not a problem with me. > where the <signing algorithm> could be, say, SHA256_RSA_PKCS1 or > NONE_RSA_PKCS1 or SHA384_RSA_PSS etc. If missing, and the key > is RSA, the client can assume it is NONE_RSA_PKCS1 and expect the hash > with digest-info header already added and sign as such. Or, if the key > is EC, do the ECDSA signing operation as is being done now. > > The "unpadded" case could be indicated by NONE_RSA_RAW. These > mnemonics are just examples -- we could use PKCS11 identifiers or something > else. > > To get unpadded data we have to override sign() in EVP_PKEY_METHOD but > that would also provide max flexibility. > > Now, I think its safe to just update and document this and require that > management-interface clients that use the external key feature must > update if using client compiled with OpenSSL 1.1.1. Android(?) and iOS (?) > clients may be the only one's affected, but those are shipped as one complete > package. I'm not aware of any standalone management-client UI that uses > the external-key feature. Might be just my client. >> support TLS 1.3 without unpadded queries we disable TLS 1.3 otherwise. > > If we must do this, disabling TLS 1.3 will not enough. One way is to > also explicitly set the padding mode to RSA_PKCS1_PADDING (for TLS1.2) > > EVP_PKEY_CTX_set_rsa_padding(ctx, pad) can do this. Okay, I will add this to the patch to force pkcs1 padding. Thanks for looking it up/pointing it out. > >> >> We also do the same for cryptoapi since it uses the same API. > > Let's just fix cryptoapi --- I'm working on it. Anyway it does > not use the same API as external key and prepadded data (= nopadding) > will not work with Windows. This'll have to be fixed before we release binaries > linked with OpenSSL 1.1.1. When I wrote that patch I did not know you would dive so fast into it :) > >> >> Using the management api client version instead might seem like the >> more logical way but since we only now that version very late, >> it would extra logic and complexity to deal with this asynchronous >> behaviour . > > IMO, we should explore this further and try to avoid > --management-external-key-foo. The biggest problem is that connect to the management interface is not strictly enforced. If you don't have management-hold, the client might start connecting before the management interface version is known and start with TLS 1.3 while the management client is not yet connected and might not support PSS signatures. This management-external-key is a special feature I would like to opt for simplicity here. I would rather just drop support for older management clients that do not support the new padding but in the last discussion of pk-sig vs rsa-sig we decided to keep support for older clients. Arne
Hi, On Wed, Oct 17, 2018 at 6:00 AM Arne Schwabe <arne@rfc2549.org> wrote: > > Am 17.10.18 um 05:15 schrieb Selva Nair: > > Hi, > > > > Not a review, but some thoughts: > > > > On Sun, Oct 7, 2018 at 5:59 PM Arne Schwabe <arne@rfc2549.org> wrote: > >> > >> For TLS 1.0 to 1.2 OpenSSL calls us and requires a PKCS1 padded > >> response, for TLS 1.3 it requires to an unpadded response. Since we > >> can PCKS1 pad an unpadded response, we prefer to always query for > >> an unpadded response from the management interface and add the PCKS1 > >> padding ourselves when needed. > > > > > > First, one clarification: > > > > The reason for unpadded response is that when PSS padding is in use, > > OpenSSL adds the padding and, thus, asks for raw RSA encryption > > (unpadded). This is because RSA_sign or rsa_priv_enc callbacks > > do not support a way of indicating PSS padding. In fact, OpenSSL > > 1.1.1 client talking to 1.1.1 server prefers PSS padding even for > > TLS 1.2, so this is not a TLS 1.3-only problem. > > Ah did not get that extra problem. > > >> This patch adds an 'unpadded' parameter to the management-external-key > >> option to signal that it is uses the new unpadded API. Since we cannot > > > > I do not particularly like this new option: > > "management-external-key-unpadded". Apart from the confusing name, > > this doesn't really address the basic limitation of the current > > pkey-sig (old rsa-sig) directive. We should have extended it when the > > new name was introduced. pkey-sig should pass not just the data (or > > hash) to sign but additional info like digest type in use, padding > > mode etc. Or have a way for the management client to query additional > > parameters that may be necessary for signing. > > Yes. But we still need a way to signal the capabilities of the > management client to OpenVPN, otherwise we will query for a signature > that we might not support. How about adding the supported signatures as > parameters? > > E.g. management-external-key pkcs1 raw pss This sounds good. None specified would imply rsa-pkcs1 and ecdsa to match the status-quo. So if pss is not included but raw is and we need PSS, we pad and pass it as something like >pk-sig <data> RSA-RAW In fact its easy to detect raw requests as the data will be exactly the size of the key so there is no room for padding. However, in the current code that would be an error as the external signer is supposed to do PKCS1 padding. If pss and raw are supported we have an option to pass the hash with the argument as hash_type-RSA-PSS or RSA-RAW. Sounds good to me. Should we make the arguments name value pairs thinking of possible future extensions. Like pk-sig <data> signature_algorithm=SHA256-RSA-PSS saltlen=32 Either way, the additional option to pk-sig will help us as we can use it to indicate whether the digest-info header is added for pkcs1 (using hash type = None) as is done presently or not etc. > > > > Using padded data and requiring the external "engine" to do a raw > > signature may look like a way out of this but not really: not all external > > libraries may support such a usage. AFAICS, Windows CNG does not. Also > > some hardware devices may insist on doing the padding inside -- > > especially non-deterministic padding like PSS. > > > I have kind of the opposite problem. At least older Android version do > not expose signing with PSS. So I have to sign with a raw signature > anyway. And I would like to avoid implementing PSS in OpenVPN. Ideally, when an engine is in use (external signer in our case) OpenSSL should not do the padding and let the engine do that. Due to limitations of the RSA_sign() call back this is not the case now when padding is not PKCS1. Hopefully that situation will change in future versions of OpenSSL. (see issue 7341 in openssl-github) or using the EVP_PKEY interface to get hold of the hash and signature algorithm details may become the preferred approach. But I understand -- legacy "engines" have to cope too and implementing PSS padding within the UI is not a good option. So we need the ability to ask for raw signature. > > > > > So what about naming this "management-external-key-version2" and then > > extend pk-sig as below? > > > > pk-sig <base64-data-to-sign> [signing-algorithm] > > Sure, not a problem with me. > > > where the <signing algorithm> could be, say, SHA256_RSA_PKCS1 or > > NONE_RSA_PKCS1 or SHA384_RSA_PSS etc. If missing, and the key > > is RSA, the client can assume it is NONE_RSA_PKCS1 and expect the hash > > with digest-info header already added and sign as such. Or, if the key > > is EC, do the ECDSA signing operation as is being done now. > > > > The "unpadded" case could be indicated by NONE_RSA_RAW. These > > mnemonics are just examples -- we could use PKCS11 identifiers or something > > else. > > > > To get unpadded data we have to override sign() in EVP_PKEY_METHOD but > > that would also provide max flexibility. > > > > Now, I think its safe to just update and document this and require that > > management-interface clients that use the external key feature must > > update if using client compiled with OpenSSL 1.1.1. Android(?) and iOS (?) > > clients may be the only one's affected, but those are shipped as one complete > > package. I'm not aware of any standalone management-client UI that uses > > the external-key feature. > > Might be just my client. Yeah. So we need not really worry about backwards compatibility as you client is shipped as one package including openssl and the UI. > > >> support TLS 1.3 without unpadded queries we disable TLS 1.3 otherwise. > > > > If we must do this, disabling TLS 1.3 will not enough. One way is to > > also explicitly set the padding mode to RSA_PKCS1_PADDING (for TLS1.2) > > > > EVP_PKEY_CTX_set_rsa_padding(ctx, pad) can do this. > > > Okay, I will add this to the patch to force pkcs1 padding. Thanks for > looking it up/pointing it out. Sorry, I wrote that without testing. It wont work: by the time we can get hold of EVP_PKEY context the signature algorithm is already negotiated with the peer. We need to use something like: SSL_CTX_set1_sigalgs_list(ctx, "ECDSA+SHA256:RSA+SHA256"); That is, exclude RSA-PSS+hash type entries included by default by OpenSSL 1.1.1. I tested this with cryptoapicert and works. > > > > >> > >> We also do the same for cryptoapi since it uses the same API. > > > > Let's just fix cryptoapi --- I'm working on it. Anyway it does > > not use the same API as external key and prepadded data (= nopadding) > > will not work with Windows. This'll have to be fixed before we release binaries > > linked with OpenSSL 1.1.1. > > When I wrote that patch I did not know you would dive so fast into it :) > > > > >> > >> Using the management api client version instead might seem like the > >> more logical way but since we only now that version very late, > >> it would extra logic and complexity to deal with this asynchronous > >> behaviour . > > > > IMO, we should explore this further and try to avoid > > --management-external-key-foo. > > The biggest problem is that connect to the management interface is not > strictly enforced. If you don't have management-hold, the client might > start connecting before the management interface version is known and > start with TLS 1.3 while the management client is not yet connected and > might not support PSS signatures. > > This management-external-key is a special feature I would like to opt > for simplicity here. I would rather just drop support for older > management clients that do not support the new padding but in the last > discussion of pk-sig vs rsa-sig we decided to keep support for older > clients. I recall that. But, in reality, I think there are no such clients, so we could easily extend pk-sig without breaking any. But that's just my opinion. Thanks, Selva
diff --git a/doc/management-notes.txt b/doc/management-notes.txt index 17645c1d..7e61ff50 100644 --- a/doc/management-notes.txt +++ b/doc/management-notes.txt @@ -832,7 +832,12 @@ END Base 64 encoded output of RSA_private_encrypt for RSA or ECDSA_sign() for EC using OpenSSL or mbedtls_pk_sign() using mbed TLS will provide a -correct signature. +correct signature. With the 'nopadding' argument to the +external-management-interface the interface expects unpadded signatures +(RSA_NO_PADDING in OpenSSL). When the 'nopadding' keyword is missing the +interfaces expects PKCS1 padded signatures for RSA keys (RSA_PKCS1_PADDING). +EC signatures are always unpadded. To support TLS 1.3 using unpadded +signatures is required. This capability is intended to allow the use of arbitrary cryptographic service providers with OpenVPN via the management interface. diff --git a/src/openvpn/manage.h b/src/openvpn/manage.h index ff143fc1..03d46456 100644 --- a/src/openvpn/manage.h +++ b/src/openvpn/manage.h @@ -348,11 +348,12 @@ struct management *management_init(void); #define MF_UNIX_SOCK (1<<8) #ifdef MANAGMENT_EXTERNAL_KEY #define MF_EXTERNAL_KEY (1<<9) +#define MF_EXTERNAL_KEY_NOPADDING (1<<10) #endif -#define MF_UP_DOWN (1<<10) -#define MF_QUERY_REMOTE (1<<11) -#define MF_QUERY_PROXY (1<<12) -#define MF_EXTERNAL_CERT (1<<13) +#define MF_UP_DOWN (1<<11) +#define MF_QUERY_REMOTE (1<<12) +#define MF_QUERY_PROXY (1<<13) +#define MF_EXTERNAL_CERT (1<<14) bool management_open(struct management *man, const char *addr, diff --git a/src/openvpn/options.c b/src/openvpn/options.c index 891468bd..52ec6582 100644 --- a/src/openvpn/options.c +++ b/src/openvpn/options.c @@ -3024,6 +3024,34 @@ options_postprocess_verify(const struct options *o) options_postprocess_verify_ce(o, &o->ce); } } +#if defined(ENABLE_CRYPTOAPI) || (defined(ENABLE_CRYPTO_OPENSSL) && defined(MANAGMENT_EXTERNAL_KEY)) +static void +disable_tls13_if_avilable(struct options *o, const char* msg) +{ +#if OPENSSL_VERSION_NUMBER >= 0x10100000L + const int tls_version_max = + (o->ssl_flags >> SSLF_TLS_VERSION_MAX_SHIFT) & + SSLF_TLS_VERSION_MAX_MASK; + + /* + * The library we are *linked* against is OpenSSL 1.1.1 and therefore support TLS 1.3 + * this need to be a runtime version check since we can be compiled against 1.1.0 and + * then the library can be upgraded to 1.1.1 + */ + if (OpenSSL_version_num() > 0x1010100fL && + (tls_version_max == TLS_VER_UNSPEC || tls_version_max > TLS_VER_1_2)) + { + msg(M_WARN, "%s Setting maximum TLS version to 1.2 ", msg); + o->ssl_flags &= ~(SSLF_TLS_VERSION_MAX_MASK << + SSLF_TLS_VERSION_MAX_SHIFT); + o->ssl_flags |= (TLS_VER_1_1 << SSLF_TLS_VERSION_MAX_SHIFT); + + } +#else + return; +#endif +} +#endif static void options_postprocess_mutate(struct options *o) @@ -3105,6 +3133,26 @@ options_postprocess_mutate(struct options *o) } #endif +#if defined(ENABLE_CRYPTO_MBEDTLS) && defined(MANAGMENT_EXTERNAL_KEY) + if (o->management_flags & MF_EXTERNAL_KEY_NOPADDING) + { + msg(M_FATAL, "mbed TLS does not support the 'nopadding' argument for the --management-external-key option"); + } +#endif + +#if defined(ENABLE_CRYPTOAPI) + if (o->cryptoapi_cert) + { + disable_tls13_if_avilable(o, "Warning: cryptapicert used."); + } +#endif +#if defined(ENABLE_CRYPTO_OPENSSL) + if ((o->management_flags & MF_EXTERNAL_KEY) && !(o->management_flags & MF_EXTERNAL_KEY_NOPADDING)) + { + disable_tls13_if_avilable(o, "Warning: Using management-external-key " + "without nopadding option."); + } +#endif #if P2MP /* * Save certain parms before modifying options via --pull @@ -5178,9 +5226,13 @@ add_option(struct options *options, options->management_write_peer_info_file = p[1]; } #ifdef MANAGMENT_EXTERNAL_KEY - else if (streq(p[0], "management-external-key") && !p[1]) + else if (streq(p[0], "management-external-key") && !p[2]) { VERIFY_PERMISSION(OPT_P_GENERAL); + if (p[1] && streq(p[1], "nopadding")) + { + options->management_flags |= MF_EXTERNAL_KEY_NOPADDING; + } options->management_flags |= MF_EXTERNAL_KEY; } else if (streq(p[0], "management-external-cert") && p[1] && !p[2]) diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c index 813ef616..81c5fd4c 100644 --- a/src/openvpn/ssl_openssl.c +++ b/src/openvpn/ssl_openssl.c @@ -1099,15 +1099,27 @@ openvpn_extkey_rsa_finish(RSA *rsa) */ static int get_sig_from_man(const unsigned char *dgst, unsigned int dgstlen, - unsigned char *sig, unsigned int siglen) + unsigned char *sig, unsigned int siglen, bool pkcs1pad) { char *in_b64 = NULL; char *out_b64 = NULL; int len = -1; + int bencret = -1; - /* convert 'dgst' to base64 */ - if (management - && openvpn_base64_encode(dgst, dgstlen, &in_b64) > 0) + if ((management->settings.flags & MF_EXTERNAL_KEY_NOPADDING) > 2 && pkcs1pad) + { + /* + * Add PKCS1 signature and replace input with it + * Use our output buffer also als temporary buffer + */ + RSA_padding_add_PKCS1_type_1(sig, siglen, dgst, dgstlen); + bencret = openvpn_base64_encode(sig, siglen, &in_b64); + } + else + { + bencret = openvpn_base64_encode(dgst, dgstlen, &in_b64); + } + if (management && bencret > 0) { out_b64 = management_query_pk_sig(management, in_b64); } @@ -1128,13 +1140,13 @@ rsa_priv_enc(int flen, const unsigned char *from, unsigned char *to, RSA *rsa, i unsigned int len = RSA_size(rsa); int ret = -1; - if (padding != RSA_PKCS1_PADDING) + if (padding != RSA_PKCS1_PADDING && padding != RSA_NO_PADDING) { RSAerr(RSA_F_RSA_OSSL_PRIVATE_ENCRYPT, RSA_R_UNKNOWN_PADDING_TYPE); return -1; } - ret = get_sig_from_man(from, flen, to, len); + ret = get_sig_from_man(from, flen, to, len, padding == RSA_PKCS1_PADDING); return (ret == len)? ret : -1; } @@ -1228,7 +1240,7 @@ ecdsa_sign(int type, const unsigned char *dgst, int dgstlen, unsigned char *sig, unsigned int *siglen, const BIGNUM *kinv, const BIGNUM *r, EC_KEY *ec) { int capacity = ECDSA_size(ec); - int len = get_sig_from_man(dgst, dgstlen, sig, capacity); + int len = get_sig_from_man(dgst, dgstlen, sig, capacity, false); if (len > 0) {