[
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 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
On 10/30/19 3:28 PM, Mohamed HAMZAOUI
wrote:
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@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