Re: [mosquitto-dev] Accepting connection based on client's certificate

[Jan Lukavský <je.ik@xxxxxxxxx>]

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