Unexpected behaviors in TLS handshake

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Unexpected behaviors in TLS handshake

Devang Kubavat

Hi all,

I set the signature algorithm using in client,

/* signature algorithm list */

(void)SSL_CTX_set1_client_sigalgs_list(ctx, “RSA+SHA512”);

 

Expected behavior: client only accepts server certificate which has signature algorithm SHA512withRSAencryption during TLS handshake.

 

But, here even I set “RSA+SHA512” signature algorithm, still client is accepting the server certificate which has signature algorithm SHA256withRSAencryption. Why?

Best Regards,
Devang

 


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Unexpected behaviors in TLS handshake

Matt Caswell-2


On 20/06/18 09:44, Devang Kubavat wrote:

> Hi all,
>
> I set the signature algorithm using in client,
>
> /* signature algorithm list */
>
> (void)SSL_CTX_set1_client_sigalgs_list(ctx, “RSA+SHA512”);
>
>  
>
> Expected behavior: client only accepts server certificate which has
> signature algorithm SHA512withRSAencryption during TLS handshake.
>
>  
>
> But, here even I set “RSA+SHA512” signature algorithm, still client is
> accepting the server certificate which has signature algorithm
> SHA256withRSAencryption. Why?

As I said in reply to your other post:

"The function "SSL_CTX_set1_client_sigalgs_list()" is for setting
signature algorithms related to *client authentication*. This is not the
same as the sig algs sent in the ClientHello. For that you need to use
SSL_CTX_set1_sigalgs_list()."

Matt
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Unexpected behaviors in TLS handshake

Devang Kubavat-2
Hi Matt,
Thanks for reply.

I also used both functions SSL_CTX_set1_sigalgs_list()
SSL_CTX_set1_client_sigalgs_list()
but same thing happens.
I set client side “RSA+SHA512” using SSL_CTX_set1_sigalgs_list() but still it is accepting sever certificate which has signature algorithm SHA256withRSAencryption.

Best Regards,
Devang

Sent from my iPhone

> On 20-Jun-2018, at 2:25 PM, Matt Caswell <[hidden email]> wrote:
>
>
>
>> On 20/06/18 09:44, Devang Kubavat wrote:
>> Hi all,
>>
>> I set the signature algorithm using in client,
>>
>> /* signature algorithm list */
>>
>> (void)SSL_CTX_set1_client_sigalgs_list(ctx, “RSA+SHA512”);
>>
>>  
>>
>> Expected behavior: client only accepts server certificate which has
>> signature algorithm SHA512withRSAencryption during TLS handshake.
>>
>>  
>>
>> But, here even I set “RSA+SHA512” signature algorithm, still client is
>> accepting the server certificate which has signature algorithm
>> SHA256withRSAencryption. Why?
>
> As I said in reply to your other post:
>
> "The function "SSL_CTX_set1_client_sigalgs_list()" is for setting
> signature algorithms related to *client authentication*. This is not the
> same as the sig algs sent in the ClientHello. For that you need to use
> SSL_CTX_set1_sigalgs_list()."
>
> Matt
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Unexpected behaviors in TLS handshake

Matt Caswell-2


On 20/06/18 14:51, Devang Kubavat wrote:
> Hi Matt,
> Thanks for reply.
>
> I also used both functions SSL_CTX_set1_sigalgs_list()
> SSL_CTX_set1_client_sigalgs_list()
> but same thing happens.
> I set client side “RSA+SHA512” using SSL_CTX_set1_sigalgs_list() but still it is accepting sever certificate which has signature algorithm SHA256withRSAencryption.

RFC5246 (TLSv1.2) says this about sigalgs:

   The client uses the "signature_algorithms" extension to indicate to
   the server which signature/hash algorithm pairs may be used in
   digital signatures.  The "extension_data" field of this extension
   contains a "supported_signature_algorithms" value.

There are actually 2 places in TLS where the server sends digital
signatures to the client: in the ServerKeyExchange message, and in the
server's Certificate.

An OpenSSL server will use the client's sigalgs to guide which of its
certificates are appropriate to use for the client - so if it has an
ECDSA cert but the client hasn't offered any ECDSA sig algs then it
won't use that cert.

The server will also sign the ServerKeyExchange with one of the sig algs
offered by the client.

Note though that an OpenSSL server does *not* (by default) check the
signature in its certs for compliance with the sig algs. So, for
example, if it has an ECDSA cert signed by the CA using RSA+SHA256, but
the client only offers ECDSA sig algs then it will still use that
certificate. You can configure the server to operate in "strict" mode
(e.g. using the "-strict" command line arg to s_server). In that mode it
will also check its certificate chain for compliance with the client's
sig algs.

An OpenSSL client will enforce that the ServerKeyExchange signature is
consistent with the sig algs that it sent. It does *not* enforce that
the server's certificate signatures are consistent with those sig algs.
I don't think there is any equivalent of the server's "-strict" to
switch this checking on.

Note that in TLSv1.3 there are actually *two* sig algs extensions, i.e.
"signature_algorithms" and "signature_algorithms_cert". The latter
enables you to specify acceptable signature algorithms in a certificate
chain separately from signatures algorithms in the TLSv1.3
CertificateVerify message.

Hope that helps,

Matt



>
> Best Regards,
> Devang
>
> Sent from my iPhone
>
>> On 20-Jun-2018, at 2:25 PM, Matt Caswell <[hidden email]> wrote:
>>
>>
>>
>>> On 20/06/18 09:44, Devang Kubavat wrote:
>>> Hi all,
>>>
>>> I set the signature algorithm using in client,
>>>
>>> /* signature algorithm list */
>>>
>>> (void)SSL_CTX_set1_client_sigalgs_list(ctx, “RSA+SHA512”);
>>>
>>>  
>>>
>>> Expected behavior: client only accepts server certificate which has
>>> signature algorithm SHA512withRSAencryption during TLS handshake.
>>>
>>>  
>>>
>>> But, here even I set “RSA+SHA512” signature algorithm, still client is
>>> accepting the server certificate which has signature algorithm
>>> SHA256withRSAencryption. Why?
>>
>> As I said in reply to your other post:
>>
>> "The function "SSL_CTX_set1_client_sigalgs_list()" is for setting
>> signature algorithms related to *client authentication*. This is not the
>> same as the sig algs sent in the ClientHello. For that you need to use
>> SSL_CTX_set1_sigalgs_list()."
>>
>> Matt
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Unexpected behaviors in TLS handshake

Viktor Dukhovni


> On Jun 20, 2018, at 12:47 PM, Matt Caswell <[hidden email]> wrote:
>
> An OpenSSL client will enforce that the ServerKeyExchange signature is
> consistent with the sig algs that it sent. It does *not* enforce that
> the server's certificate signatures are consistent with those sig algs.
> I don't think there is any equivalent of the server's "-strict" to
> switch this checking on.
>
> Note that in TLSv1.3 there are actually *two* sig algs extensions, i.e.
> "signature_algorithms" and "signature_algorithms_cert". The latter
> enables you to specify acceptable signature algorithms in a certificate
> chain separately from signatures algorithms in the TLSv1.3
> CertificateVerify message.

Right, certificate chain verification is the business of the X.509
code in libcrypto and lies entirely outside the SSL library.  The
SSL library sets the "security level" establishing a baseline
acceptable cryptographic strength, but otherwise, if your trusted
CAs use particular signature algorithms (per CA/B Forum practices,
...) then you'll accept the algorithms they use.

If some root CAs, or intermediate CAs to which they delegate authority,
employ weak algorithms, your best bet is to not trust those
CAs, they should not be using weak algorithms.

TLS is not the best place to regulate (Web) PKI.

At present libcrypto does not provide a fine-grained way to
restrict which signature algorithms are acceptable for a
particular invocation of X509_verify_cert(3).  The "best"
you can do is enable only the EVP algorithms you want when
when initializing the OpenSSL library.  I don't recall
whether leaving some EVP algorithms uninitialized is still
possible now that OpenSSL 1.1.x is doing automatic
self-initialization.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Unexpected behaviors in TLS handshake

Jakob Bohm-7
On 20/06/2018 19:31, Viktor Dukhovni wrote:
>
> If some root CAs, or intermediate CAs to which they delegate authority,
> employ weak algorithms, your best bet is to not trust those
> CAs, they should not be using weak algorithms.
>
> TLS is not the best place to regulate (Web) PKI.
I believe there is a fundamental concern, impossible to handle sanely
at the CA policy level, that a CA may reasonably have certificate
hierarchies targeting people with different maximum security strength
and/or living at different times within a root certificate lifespan
(decades).

Thus it is reasonable for a particular TLS participant to dynamically
reject/ignore certificates weaker than it's own policies even if
issued by a root CA that has both strong and weak subtrees.

For example CA1 may, over time, have the following chains:

longtermCAroot ->
   OldIntermediary(signed-with-RSA2048-SHA1, expired or revoked) ->
     OldEECerts(all expired or revoked)

longtermCAroot ->
   crossSignedNewCAroot(signed-with-RSA2048-SHA256) ->
   NewIntermediary(signed-with-RSA4096-SHA256) ->
       CurrentEEcerts (all signed with RSA4096-SHA256)

newCAroot->
NewIntermediary(signed-with-RSA4096-SHA256) ->
     CurrentEEcerts (all signed with RSA4096-SHA256)

longtermCAroot ->
   NeverIssuedIntermediary(falsified via SHA1 weakness) ->
     FakeCert (signed with RSA4096-SHA256).

By making a TLS library able to reject certificate chains
involving RSA-MD5 (or whatever else the run time configuration
chooses to distrust), it can protect its user against trusting
the NeverIssuedIntermediary and thus the FakeCert.

CA policy and the browser forum can only choose to accept or
refuse longtermCAroot entirely.  Trusting only the self-signed
variant of crossSignedNewCAroot won't work until that has been
distributed via secure channels and all needs to trust
longtermCAroot for other uses of the unified openSSL CA directory
have disappeared.

The scenario becomes even more complicated in cases when (due to
refusals to backport algorithms to older libraries), there are
real systems that cannot accept the latest state of the art
minimum algorithms, thus in turn requiring the ongoing issuance
of certificates with old algorithm chaining to CA roots trusted
by such older systems.

The above pattern of algorithm distrust can be expected to reccur
every few decades as new attacks are found or otherwise become viable.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Unexpected behaviors in TLS handshake

Viktor Dukhovni


> On Jun 20, 2018, at 3:44 PM, Jakob Bohm <[hidden email]> wrote:
>
> I believe there is a fundamental concern, impossible to handle sanely
> at the CA policy level, that a CA may reasonably have certificate
> hierarchies targeting people with different maximum security strength
> and/or living at different times within a root certificate lifespan
> (decades).
>
> Thus it is reasonable for a particular TLS participant to dynamically
> reject/ignore certificates weaker than it's own policies even if
> issued by a root CA that has both strong and weak subtrees.

For that we have a coarse filter in the form of the security
level.  Thus MD5 is no longer accepted outside root CA self
signatures at the default security level 1 or higher.

One thing I forgot to mention is:

   https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_security_callback.html

The callback interface is not yet documented, but it does allow
the application to bless or reject each algorithm for a particular
purpose:

    void SSL_CTX_set0_security_ex_data(SSL_CTX *ctx, void *ex);
    void SSL_CTX_set_security_callback(SSL_CTX *ctx,
                                       int (*cb)(SSL *s, SSL_CTX *ctx, int op,
                                                 int bits, int nid,
                                                 void *other, void *ex));

When this is documented, users who really want low level
control would be able to accept or reject specific algorithms
for specific operations.

The "op" values of interest are:

   SSL_SECOP_EE_KEY   /* accept/reject an EE public key */
   SSL_SECOP_CA_KEY   /* accept/reject a CA public key */
   SSL_SECOP_CA_MD    /* accept/reject a CA hash algorithm */

If there is enough demand and contributor energy, this
interface could get documented, code examples provided, ...

--
--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Unexpected behaviors in TLS handshake

Jakob Bohm-7
On 20/06/2018 23:07, Viktor Dukhovni wrote:

>
>> On Jun 20, 2018, at 3:44 PM, Jakob Bohm <[hidden email]> wrote:
>>
>> I believe there is a fundamental concern, impossible to handle sanely
>> at the CA policy level, that a CA may reasonably have certificate
>> hierarchies targeting people with different maximum security strength
>> and/or living at different times within a root certificate lifespan
>> (decades).
>>
>> Thus it is reasonable for a particular TLS participant to dynamically
>> reject/ignore certificates weaker than it's own policies even if
>> issued by a root CA that has both strong and weak subtrees.
> For that we have a coarse filter in the form of the security
> level.  Thus MD5 is no longer accepted outside root CA self
> signatures at the default security level 1 or higher.
>
> One thing I forgot to mention is:
>
>     https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_security_callback.html
>
> The callback interface is not yet documented, but it does allow
> the application to bless or reject each algorithm for a particular
> purpose:
>
>      void SSL_CTX_set0_security_ex_data(SSL_CTX *ctx, void *ex);
>      void SSL_CTX_set_security_callback(SSL_CTX *ctx,
>                                         int (*cb)(SSL *s, SSL_CTX *ctx, int op,
>                                                   int bits, int nid,
>                                                   void *other, void *ex));
>
> When this is documented, users who really want low level
> control would be able to accept or reject specific algorithms
> for specific operations.
>
> The "op" values of interest are:
>
>     SSL_SECOP_EE_KEY   /* accept/reject an EE public key */
>     SSL_SECOP_CA_KEY   /* accept/reject a CA public key */
>     SSL_SECOP_CA_MD    /* accept/reject a CA hash algorithm */
>
> If there is enough demand and contributor energy, this
> interface could get documented, code examples provided, ...
>
What would be much more useful would be a way to put the simpler
forms in the cipher list or config options list that OpenSSL
encourages generic clients and servers to make available to end
users, thus allowing such end users (not software developers like
me) to disable broken algorithms as soon as practical to their
situation.  Also end users wanting higher security levels might
want to disable the weaker of the "currently secure" algorithms,
along with disabling the corresponding TLS ciphers suites.  So
currently, these would be approximately the users who might
manually disable 128 bit symmetric cipher suites.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users