optional verification of clients?

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

optional verification of clients?

Antonio SJ Musumeci
Is there a way to do something similar to NGINX's "ssl_verify_client
optional;"?
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: optional verification of clients?

Amos Jeffries
Administrator
On 1/11/19 9:19 am, Antonio SJ Musumeci wrote:
> Is there a way to do something similar to NGINX's "ssl_verify_client
> optional;"?


Set sslflags=DELAYED_AUTH on the http(s)_port line.

Though why you would want to slow every TLS connection setup with KBs of
certificates pushed in both directions then "dropped on the floor" is
beyond me.


Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: optional verification of clients?

Antonio SJ Musumeci
On 11/1/2019 2:32 AM, Amos Jeffries wrote:

> On 1/11/19 9:19 am, Antonio SJ Musumeci wrote:
>> Is there a way to do something similar to NGINX's "ssl_verify_client
>> optional;"?
>
>
> Set sslflags=DELAYED_AUTH on the http(s)_port line.
>
> Though why you would want to slow every TLS connection setup with KBs of
> certificates pushed in both directions then "dropped on the floor" is
> beyond me.
>
>
> Amos
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users
>

The docs indicated that DELAYED_AUTH isn't implemented and doesn't seem
to work on 4.8. If I enable it it acts as if no certs are passed and the
http_access user_cert acl I setup which works fine when not using
DELAYED_AUTH does not seem to trigger the verification.

Regardless, the point is to create an "anonymous" setup. Not all clients
have, need, or can provide certs. With NGINX setting verify to optional
I can verify iff they are provided allowing me to convert no certs into
a generic guest / anonymous account and entitle separately.

If I understand DELAYED_AUTH's behavior this isn't going to get me that.
I need to be able to tell if the cert was provided. If verification is
just delayed till when the acl is processed that doesn't help unless
there is an acl I'm missing that indicates a cert was provided. The
ssl_error acl values all imply existence.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: optional verification of clients?

Amos Jeffries
Administrator
On 2/11/19 1:17 am, Antonio SJ Musumeci wrote:

> On 11/1/2019 2:32 AM, Amos Jeffries wrote:
>> On 1/11/19 9:19 am, Antonio SJ Musumeci wrote:
>>> Is there a way to do something similar to NGINX's "ssl_verify_client
>>> optional;"?
>>
>>
>> Set sslflags=DELAYED_AUTH on the http(s)_port line.
>>
>> Though why you would want to slow every TLS connection setup with KBs of
>> certificates pushed in both directions then "dropped on the floor" is
>> beyond me.
>>
>
> The docs indicated that DELAYED_AUTH isn't implemented and doesn't seem
> to work on 4.8. If I enable it it acts as if no certs are passed and the
> http_access user_cert acl I setup which works fine when not using
> DELAYED_AUTH does not seem to trigger the verification.
>

Oh well. That was the closest Squid has. I was hoping the library would
sent cert request but not verify the clients response. So the details
would be available for logging etc as handshake parameters.

If that client cert request/delivery is not working then the only
alternative would be two proxy ports, one with client certificates
required and one without. Which does not match what you are trying to
achieve.


If this is of particular importance patch/PR are welcome. I will keep it
in mind for future TLS improvements, but there is no guarantees that way.
<https://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feature.2C_enhance.2C_of_fix_something.3F>
<https://wiki.squid-cache.org/DeveloperResources>

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: optional verification of clients?

Antonio SJ Musumeci
On 11/1/2019 8:37 PM, Amos Jeffries wrote:

> Oh well. That was the closest Squid has. I was hoping the library would
> sent cert request but not verify the clients response. So the details
> would be available for logging etc as handshake parameters.
>
> If that client cert request/delivery is not working then the only
> alternative would be two proxy ports, one with client certificates
> required and one without. Which does not match what you are trying to
> achieve.
>
>
> If this is of particular importance patch/PR are welcome. I will keep it
> in mind for future TLS improvements, but there is no guarantees that way.
> <https://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feature.2C_enhance.2C_of_fix_something.3F>
> <https://wiki.squid-cache.org/DeveloperResources>

I've done a quick hack to remove SSL_VERIFY_FAIL_IF_NO_PEER_CERT from
Ssl::SetupVerifyCallback in ssl/support.cc. It *appears* that this
accomplishes what I want. I'm seeing client cert info when provided and
not when I don't (in acl user_cert, logging, external_acl_handler, etc.)
Anyone know if there may be some gotchas that I could be missing? Some
data structures or behavior expecting the VERIFY_FAIL_IF_NO_PEER_CERT
behavior? If it sounds safe I'll look into turning this into a proper
sslflags option.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users