| Re: [mosquitto-dev] Accepting connection based on client's certificate |
Hi Mohamed,
sorry, I somehow missed your precious email. I think that I have come to basically similar solution, but - the "additional" authentication is not based on password (hashed private key), but I directly validate public keys presented in certificate instead (similar to how SSH keys work). This seem to work, but (as you mention as well) I have to validate that in ACLs. This is suboptimal, and I'd like to propose (an optional) method for plugin to be called on each incoming connection (e.g. mosquitto_auth_connection_check). Currently there is only call for password checking and then ACLs.
Does that make sense?
Jan
Hi Jan,
I think we focused too much on a method and not on the problem to be solved.If my understanding is good, if the CN consists of login and you want to ensure security even if the CA private key is stolen (while you do not know it yet) which is a very « rare » case and reflects a real problem to manage your PKI.Thus, if you want to define measures in this context, you must use a step in advance of trusting via an OOB channel of your connections.For example:- send CN and a password derived from the HASH of the private key (will serve as PoP),- update your mosquitto ACLs- use your TLS with double authentication.
Regards,Mohamed
Le 29 oct. 2019 à 18:32, Jan Lukavský <je.ik@xxxxxxxxx> a écrit :
_______________________________________________Hi Mohamed,
thanks for the comment, but I cannot terminate TLS prior to mosquitto server (stunnel, haproxy, ...), because otherwise I would loose the username present in common name of client's certificate. It would require something like MQTT proxy, extracting the username and then forwarding it to mosquitto (I'm not sure if any MQTT proxy can do that, maybe yes), but this is generally more complex and generally undesirable in my case (would require opening unsecured mosquitto - even if on local network only).
But thanks for the suggestion anyway.
Best,
Jan
On 10/29/19 5:05 PM, Mohamed HAMZAOUI wrote:
Hello,
I don’t read all of the exchange thread. I have just an idea that we use for similar context (car fleet in automotive) with mosquitto and which is well validated from cybersecurity point of view.Use an autonomous external component for TLS management like stunnel (https://www.stunnel.org/) in which you manage all desired aspect regarding this layer.Put mosquitto server listening only for localhost incoming connection and configure stunnel to forward traffic to it.You have a lot of configurable things with stunner, enjoy !Hope this can help you.
Regards,Mohamed
Le 29 oct. 2019 à 16:51, Greg Troxel <gdt@xxxxxxxxxx> a écrit :
Jan Lukavský <je.ik@xxxxxxxxx> writes:
Yes, UNIX socket is no problem, or maybe gRPC? That could be efficient
enough (not available in pure C, would have to be C++ submodule, could
have C interface though), although the fork is of no big overhead
given that there is synchronous TLS handshake (and thus many cycles
between user space and kernel space and even sending data multiple
cycles over wire). My measurements didn't show any significant impact
of the forking to the number of connections per second just from the
fork. It might be a little more secure to use a more defined protocol,
though.
Fair enough about TLS/etc. I guess it just seems that forking for this
is icky, at least to me, and I realize that's a preference thing.
The plugin architecture is of course possible, but it seems a bit more
fragile - the application code might not be as well tested as
mosquitto server itself and a security or other vulnerability might
compromise the whole server. So were I implement this I would choose a
different process (fork, UNIX socket, gRPC). gRPC would be the
preferred option for me, personally.
True about plugins, but they could just be glue to RPC mechanisms.
I am not familiar with gRPC and it's dimly on my list of things to look
at but if base mosquitto w/o the cpp wrapper can be built without C++
now, it seems like a regression to require C++ for the core.
Maybe CORBA? (That's a joke.)
_______________________________________________
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
_______________________________________________ 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