[Openvpn-devel] Add support for OpenSSL TLS 1.3 when using management-external-key

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
Related show

Commit Message

Arne Schwabe Oct. 7, 2018, 9:58 p.m.
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.

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
support TLS 1.3 without unpadded queries we disable TLS 1.3 otherwise.
We also do the same for cryptoapi since it uses the same API.

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 .
---
 doc/management-notes.txt  |  7 ++++-
 src/openvpn/manage.h      |  9 ++++---
 src/openvpn/options.c     | 54 ++++++++++++++++++++++++++++++++++++++-
 src/openvpn/ssl_openssl.c | 26 ++++++++++++++-----
 4 files changed, 83 insertions(+), 13 deletions(-)

Comments

Selva Nair Oct. 17, 2018, 3:15 a.m. | #1
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
Arne Schwabe Oct. 17, 2018, 9:59 a.m. | #2
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
Selva Nair Oct. 17, 2018, 4:08 p.m. | #3
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

Patch

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)
     {