Has client validated successfully?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Has client validated successfully?

d3x0r
Is there a way for a server to know if the client verified the cert chain successfully or not?  

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

Re: Has client validated successfully?

Kyle Hamilton
The only thing that the server can know is whether the client has
terminated the connection with a fatal alert.  If the client validates
presented cert chains, then its continuation with the connection means
that it passed validation.  If the client does not, or ignores any
given error, then it doesn't mean that it passed validation.

In other words, you can only know if the client's applied policy
allows the connection to continue.  You cannot know if the policy that
was applied was specifically related to the certificate chain
presented.

-Kyle H

On Mon, Feb 12, 2018 at 10:06 PM, J Decker <[hidden email]> wrote:
> Is there a way for a server to know if the client verified the cert chain
> successfully or not?
>
> --
> 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: Has client validated successfully?

d3x0r


On Tue, Feb 13, 2018 at 9:33 AM, Emmanuel Deloget <[hidden email]> wrote:
Hello,

On Tue, Feb 13, 2018 at 7:14 AM, Kyle Hamilton <[hidden email]> wrote:

> The only thing that the server can know is whether the client has
> terminated the connection with a fatal alert.  If the client validates
> presented cert chains, then its continuation with the connection means
> that it passed validation.  If the client does not, or ignores any
> given error, then it doesn't mean that it passed validation.
>
> In other words, you can only know if the client's applied policy
> allows the connection to continue.  You cannot know if the policy that
> was applied was specifically related to the certificate chain
> presented.
>
> -Kyle H
>
> On Mon, Feb 12, 2018 at 10:06 PM, J Decker <[hidden email]> wrote:
> > Is there a way for a server to know if the client verified the cert chain
> > successfully or not?
>

​From a security PoV, that doesn't help much. One can build a malicious
version of openvpn that will tell you "everything's ok" (or "it failed!",
depending of its goal)​. The server should not make any decision w.r.t. the
client state (that's more or less what is implied by Kyle's answer ; I just
wanted to stress it).


Yes that is true.... however here's the scenario.
Client does a verification and passes or fails, and via the SSL layer I can query if the client validated the certificate.
If it failed, provide a option for the client to get a renewed certificate for verification.  If success, no action.
If an actor lies in this scenario he answers
lies *yes* and didn't, don't give him a means to actually verify. *noop*
lies *no* but did, then give him the root cert he already has.... *noop*

so I don't have to trust the reply.... I'm willing to give him the right root.
 
BR,

-- Emmanuel Deloget


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

Re: Has client validated successfully?

Jochen Bern
In reply to this post by d3x0r
On 02/20/2018 06:34 PM, J Decker <[hidden email]> wrote:

> Yes that is true.... however here's the scenario.
> Client does a verification and passes or fails, and via the SSL layer I can
> query if the client validated the certificate.
> If it failed, provide a option for the client to get a renewed certificate
> for verification.  If success, no action.
> If an actor lies in this scenario he answers
> lies *yes* and didn't, don't give him a means to actually verify. *noop*
> lies *no* but did, then give him the root cert he already has.... *noop*
>
> so I don't have to trust the reply.... I'm willing to give him the right
> root.
That's nice from the server's POV, but the client REALLY REALLY SHOULD
NOT install and/or put trust into any CA certs it received in-band in a
connection that failed verification. The best (for you) it can do is to
store it and offer it to its user for additional verification and *then*
installation - and I'ld venture a guess that you'ld have to write such a
client yourself.

(And offering the *root* certificate isn't that far from the common
practice of a server sending *most* of its CA chain in addition to its
own certificate, anyway, so it's debatable whether you even *need* the
result of the client's verification as an input to send the root as well.)

Kind regards,
--
Jochen Bern
Systemingenieur

Binect GmbH


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

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Has client validated successfully?

Kyle Hamilton
In reply to this post by d3x0r
No, you cannot query the SSL layer to know if the client validated the
certificate.  SSL/TLS don't provide any means of querying the remote
side.

Here's how the workflow works:

1) client doesn't trust certificate, doesn't override distrust:
connection closes with fatal unknown_ca or expired_certificate alert.
2) client doesn't trust certificate, does override distrust:
connection continues.  No way to query if distrust was overridden.
3) client does trust certificate, no need to override: connection
continues.  No way to query if distrust was overridden.

There's no way for the server to know if the client trusts the
certificate, or if the client overrode the distrust.

There's generally also no way for Javascript on the client to know
this, either.  However, because this is a list about OpenSSL (and not
about any given application of OpenSSL, i.e. the web) it's not the
best place to ask about how to do this on the web.

Certificate chain updates (to avoid chain expiration) by the server
are expected to be done unilaterally, by the server operator.

If different certificate chains need to be provided to different
clients, the different clients can request different hostnames (via
the Server Name Indication extension) so the server can decide which
certificate chain to present.

As much as it sucks, this is the only server certificate selection
mechanism that exists in SSL/TLS.

-Kyle H

On Tue, Feb 20, 2018 at 9:34 AM, J Decker <[hidden email]> wrote:

>
>
> On Tue, Feb 13, 2018 at 9:33 AM, Emmanuel Deloget <[hidden email]> wrote:
>>
>> Hello,
>>
>> On Tue, Feb 13, 2018 at 7:14 AM, Kyle Hamilton <[hidden email]> wrote:
>>
>> > The only thing that the server can know is whether the client has
>> > terminated the connection with a fatal alert.  If the client validates
>> > presented cert chains, then its continuation with the connection means
>> > that it passed validation.  If the client does not, or ignores any
>> > given error, then it doesn't mean that it passed validation.
>> >
>> > In other words, you can only know if the client's applied policy
>> > allows the connection to continue.  You cannot know if the policy that
>> > was applied was specifically related to the certificate chain
>> > presented.
>> >
>> > -Kyle H
>> >
>> > On Mon, Feb 12, 2018 at 10:06 PM, J Decker <[hidden email]> wrote:
>> > > Is there a way for a server to know if the client verified the cert
>> > > chain
>> > > successfully or not?
>> >
>>
>> From a security PoV, that doesn't help much. One can build a malicious
>> version of openvpn that will tell you "everything's ok" (or "it failed!",
>> depending of its goal). The server should not make any decision w.r.t. the
>> client state (that's more or less what is implied by Kyle's answer ; I
>> just
>> wanted to stress it).
>>
>
> Yes that is true.... however here's the scenario.
> Client does a verification and passes or fails, and via the SSL layer I can
> query if the client validated the certificate.
> If it failed, provide a option for the client to get a renewed certificate
> for verification.  If success, no action.
> If an actor lies in this scenario he answers
> lies *yes* and didn't, don't give him a means to actually verify. *noop*
> lies *no* but did, then give him the root cert he already has.... *noop*
>
> so I don't have to trust the reply.... I'm willing to give him the right
> root.
>
>>
>> BR,
>>
>> -- Emmanuel Deloget
>
>
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users