TLSv12 Client Certificate Selection Behavior !!

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

TLSv12 Client Certificate Selection Behavior !!

Hareesh D
TLSv12 client is sending RSA certificate even when it dont have digitalSignature bit in keyUsage extension. But RFC5246 sectiin-7.4.6 says its MUST condition for client to send RSA certificate with digitalSignature bit set in keyUsage extension.

1. Though server is rejecting such certificates, not sure why client sends such certificates even when there is MUST condition for this point. Should client send empty certificate list instead of sending wrong one? Client has the provision of sensing empty certificate list when it don't have a suitable certificate according to certificate request.

2. And also client is not checking the certificate_types requested in certificate_message and also server not validating if the response is according to the type requested. Consider server requesting only DSA certificate. Client sending RSA certificate and server accepting it.

Is this behavior valid and according to RFC ?
Reply | Threaded
Open this post in threaded view
|

Re: TLSv12 Client Certificate Selection Behavior !!

OpenSSL - User mailing list
On 11/06/2019 12:50, Hareesh D wrote:

> TLSv12 client is sending RSA certificate even when it dont have
> digitalSignature bit in keyUsage extension. But RFC5246 sectiin-7.4.6
> says its MUST condition for client to send RSA certificate with
> digitalSignature bit set in keyUsage extension.
>
> 1. Though server is rejecting such certificates, not sure why client
> sends such certificates even when there is MUST condition for this
> point. Should client send empty certificate list instead of sending
> wrong one? Client has the provision of sensing empty certificate list
> when it don't have a suitable certificate according to certificate
> request.
>
> 2. And also client is not checking the certificate_types requested in
> certificate_message and also server not validating if the response is
> according to the type requested. Consider server requesting only DSA
> certificate. Client sending RSA certificate and server accepting it.
>
> Is this behavior valid and according to RFC ?
There's an overarching OpenSSL policy that certificate checks are
done exclusively by the relying end (for client certs, that's the
server), except when certified end is trying to choose from
multiple certificates.

Thus with only one certificate available, the OpenSSL sends the
(untrusted, and in this case inappropriate) certificate, just in
case the server was somehow configured to make a special exception
for this particular case.

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

Reply | Threaded
Open this post in threaded view
|

RE: TLSv12 Client Certificate Selection Behavior !!

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf Of
> Jakob Bohm via openssl-users
> Sent: Tuesday, June 11, 2019 08:19
>
> On 11/06/2019 12:50, Hareesh D wrote:
> >
> > Is this behavior valid and according to RFC ?
>
> There's an overarching OpenSSL policy that certificate checks are
> done exclusively by the relying end (for client certs, that's the
> server), except when certified end is trying to choose from
> multiple certificates.
>
> Thus with only one certificate available, the OpenSSL sends the
> (untrusted, and in this case inappropriate) certificate, just in
> case the server was somehow configured to make a special exception
> for this particular case.

Yes. I for one would argue this existing behavior (i.e. not enforcing every mandate of every applicable standard, at every step of the way) is the Right Thing to do. While it's good that OpenSSL is increasingly providing functionality to make it easier for applications to follow the RFCs and other standards, it's also very important that applications have the flexibility to violate some aspects of those standards. That is critical for interoperability with non-standard peers, as Jakob wrote, and for testing, among other things.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



Reply | Threaded
Open this post in threaded view
|

Re: TLSv12 Client Certificate Selection Behavior !!

Viktor Dukhovni
> On Jun 11, 2019, at 12:15 PM, Michael Wojcik <[hidden email]> wrote:
>
>> There's an overarching OpenSSL policy that certificate checks are
>> done exclusively by the relying end (for client certs, that's the
>> server), except when certified end is trying to choose from
>> multiple certificates.
>>
>> Thus with only one certificate available, the OpenSSL sends the
>> (untrusted, and in this case inappropriate) certificate, just in
>> case the server was somehow configured to make a special exception
>> for this particular case.
>
> Yes. I for one would argue this existing behavior (i.e. not enforcing every mandate of every applicable standard, at every step of the way) is the Right Thing to do. While it's good that OpenSSL is increasingly providing functionality to make it easier for applications to follow the RFCs and other standards, it's also very important that applications have the flexibility to violate some aspects of those standards. That is critical for interoperability with non-standard peers, as Jakob wrote, and for testing, among other things.

That said, the intention isn't to ignore all the requirements, just
some of those that are not always a good idea to enforce, and perhaps
should never have been mandated in the first place.  Therefore, while
we leave enforcing the certificate signature algorithms to the peer,
enforcing keyUsage in client certificate selection is less obviously
counterproductive, and in fact can (as reported) avoid interop issues.

The OP did not specify which version of OpenSSL did not perform the
expected check.  I'd be open to adding such a check in master and
perhaps even 1.1.1 (as a bug fix).  A client certificate that cannot
do digital signatures is not much use.  On the other hand, applications
should not configure such certificates as client certificates, there
is not context in which they are valid.  So another potential response
is: "if it hurts, don't do that!"

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

RE: TLSv12 Client Certificate Selection Behavior !!

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf Of
> Viktor Dukhovni
> Sent: Tuesday, June 11, 2019 10:39

> A client certificate that cannot do digital signatures is not much use.

There may be existing applications which use TLS entirely within an organization, where the server does not check KU, and the peers use certificates generated by an internal CA that doesn't set those extensions properly. In that use case, enforcing the KU requirement would break backward compatibility.

Maybe that's not worth worrying about; maybe the advantages of enforcing KU on the client certificate at the client end (better diagnostics for the client application, enforce the standard even if the server doesn't) outweigh it. But I don't think it's entirely accurate to say a client certificate with incorrect/missing KU (or EKU, or other extensions) is necessarily useless.

To be honest I don't have a strong feeling about this particular suggestion. If OpenSSL started requiring proper KU on client certificates, and that forced some people to fix their internal CA configurations, that's arguably a good thing; such people may well be using too-small keys and outdated algorithms too. Disruption can definitely be good in this area. Just wanted to point out that it might be possible to rely on the existing behavior.

And, of course, there are no doubt still people out there running internal CAs that generate X.509v1 certs, which won't have any extensions at all. No KU, no EKU, no SAN, no SKID/AKID ... Presumably a check for proper KU on the client certificate would be bypassed if the client cert is v1 - but then using a v1 certificate is another violation of RFC 5246 (7.4.2) that OpenSSL probably should not enforce.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



Reply | Threaded
Open this post in threaded view
|

Re: TLSv12 Client Certificate Selection Behavior !!

Viktor Dukhovni
> On Jun 11, 2019, at 1:02 PM, Michael Wojcik <[hidden email]> wrote:
>
> And, of course, there are no doubt still people out there running internal CAs that generate X.509v1 certs, which won't have any extensions at all. No KU, no EKU, no SAN, no SKID/AKID ... Presumably a check for proper KU on the client certificate would be bypassed if the client cert is v1 - but then using a v1 certificate is another violation of RFC 5246 (7.4.2) that OpenSSL probably should not enforce.

Yes, v1 certs would get a free ride.  The reason to enforce KU
in client certs would be that client certs are not infrequently
(though not always) optional, and it can be better to not send
any client cert, than to send one the server will reject.

RSA client certs without digital signature in KU are increasingly
not interoperable as more server implementations are checking the
keyUsage these days.  So at some point it makes sense to consider
not offering such (client) certs to the peer server.

But at the end of the day, the user should not have configured
such a client cert in the first place, so it may also make sense
to just leave the responsibility with the user.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: TLSv12 Client Certificate Selection Behavior !!

Michael Richardson

Viktor Dukhovni <[hidden email]> wrote:
    > Yes, v1 certs would get a free ride.  The reason to enforce KU
    > in client certs would be that client certs are not infrequently
    > (though not always) optional, and it can be better to not send
    > any client cert, than to send one the server will reject.

802.1AR seems to discourage KU in IDevID because at most KU bits make
the certificate less useable, and IDevID certificates are expected to live
for decades.

    > RSA client certs without digital signature in KU are increasingly
    > not interoperable as more server implementations are checking the
    > keyUsage these days.  So at some point it makes sense to consider
    > not offering such (client) certs to the peer server.

I would like knobs for this.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [hidden email]  http://www.sandelman.ca/        |   ruby on rails    [


signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TLSv12 Client Certificate Selection Behavior !!

OpenSSL - User mailing list
In reply to this post by Viktor Dukhovni
On 11/06/2019 19:21, Viktor Dukhovni wrote:

>> On Jun 11, 2019, at 1:02 PM, Michael Wojcik <[hidden email]> wrote:
>>
>> And, of course, there are no doubt still people out there running internal CAs that generate X.509v1 certs, which won't have any extensions at all. No KU, no EKU, no SAN, no SKID/AKID ... Presumably a check for proper KU on the client certificate would be bypassed if the client cert is v1 - but then using a v1 certificate is another violation of RFC 5246 (7.4.2) that OpenSSL probably should not enforce.
> Yes, v1 certs would get a free ride.  The reason to enforce KU
> in client certs would be that client certs are not infrequently
> (though not always) optional, and it can be better to not send
> any client cert, than to send one the server will reject.
>
> RSA client certs without digital signature in KU are increasingly
> not interoperable as more server implementations are checking the
> keyUsage these days.  So at some point it makes sense to consider
> not offering such (client) certs to the peer server.
>
> But at the end of the day, the user should not have configured
> such a client cert in the first place, so it may also make sense
> to just leave the responsibility with the user.
>
Note that the most common variant of encrypt-only RSA client certs
is probably encrypt-only e-mail client certs with other client uses
tacked on.

Such certificates are typically paired with a "same logical
identity" sign-only e-mail/client certificate, with the key
difference being that the encrypt-only-private key is kept around
for a lot longer in order to decrypt stored e-mails that are
(wisely) stored only in their original encrypted form.

In that /specific/ case, attempting to use the encrypt-only cert
as a TLS client cert is typically some kind of logic certificate
selection error, such as a Web client blindly using the locally
stored long-term decryption key instead of the signing key stored
on a removable, but also loosable, smart card, however there may
be company-internal reasons to do so deliberately in order for
background activities to operate when the user (and smartcard) is
"away from terminal".

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