[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [mosquitto-dev] Accepting connection based on client's certificate
|
Hi Roger,
I finally got to actually implementing this and I have found a problem.
The function you suggest is called only when user supplies
username/password (which is not the case in my situation, because
clients are authenticated using certificates). I did a little research
and it looks to me, that the only way around this is to use the
mosquitto_auth_acl_check call instead. That will sort of work, but the
problem there is a subtle (but important) difference - when using ACLs,
the user will not be able to send or receive any data (which is fine),
but will stay connected to the broker and consume resources. I think
that to simply disconnect the client would be a little more efficient. I
think I can live for now with the ACL approach, but the question is -
would the mosquitto community be open to adding a function to the plugin
to validate the client's certificate and disconnect the client upon failure?
Jan
On 10/30/19 10:30 AM, Jan Lukavský wrote:
Hi Roger,
that is really helpful, thanks! I somehow missed that the signature of
this method changed (it was not possible to obtain client certificate
from there in earlier versions).
Cheers,
Jan
On 10/29/19 7:56 PM, Roger Light wrote:
Hi Jan,
One way to approach this would be to have a plugin that does what you
have already described, but in the authentication check. Something
like:
int mosquitto_auth_unpwd_check(void *user_data, struct mosquitto
*client, const char *username, const char *password)
{
X509 *cert;
cert = mosquito_client_certificate(client);
if(do_my_check(cert) == MOSQ_ERR_SUCCESS){
return MOSQ_ERR_SUCCESS;
}else{
return MOSQ_ERR_AUTH;
}
}
Cheers,
Roger
On Tue, 29 Oct 2019 at 10:33, Jan Lukavský <je.ik@xxxxxxxxx> wrote:
Hello,
I have a question about solving following situation:
- I have a TLS enabled mosquitto server, which is configured to
accept
only connections with client certificate signed by defined authority
- suppose I have additional application logic, that can decide
whether
certificate should be granted access, although it seems to be otherwise
valid
- I cannot use OCSP stapling (let's just suppose that)
I have successfully solved this by adding a "hook" to the
src/handle_connect.c - a configurable executable that receives
certificate can be run and return zero (success) or non-zero (deny
access).
The question now is - would this solution be acceptable upstream? Is
there better solution (one that comes in mind is maybe extend auth
plugin somehow)? I see the fact that a subprocess is forked on each
incoming connection as only a minor performance issue given that it
gives (a little) additional security in that if the "plugin" crashes
for
whatever reason then it affects only the incoming connection and not
the
server as a whole.
Thanks for any comments,
Jan
_______________________________________________
mosquitto-dev mailing list
mosquitto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/mosquitto-dev
_______________________________________________
mosquitto-dev mailing list
mosquitto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/mosquitto-dev