| 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
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
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@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/mosquitto-dev
|
