Re: [mosquitto-dev] config file questions

[Greg Troxel <gdt@xxxxxxxxxx>]

Roger Light <roger@xxxxxxxxxx> writes:

>>   The documentation talks about port 1883 vs 8883, which is obviously a
>>   pair that one does not and does usually use TLS on.  But it doesn't
>>   say that port number and TLS are or are not linked.  I think they
>>   aren't linked in code, just by custom.
>
> I feel as though you're pulling my leg a bit at this point :) This is
> just the same as port 80 and 443, they're defined by custom and IANA.

I am not pulling your leg.  I completely understand that people do plain
MQTT on 1883 and do MQTT over TLS on 8883.  What is not clear from the
documentation is which config statements actually cause a listener to be
switched into TLS mode.  One could write a server to know about the two
standard ports and switch TLS on by port matching.  But that's not a
good idea, for testing and odd use.  Perhaps it's certfile/keyfile that
if both present mean TLS, and if one but not the other it's an error,
and if neither mean no TLS.  Or perhaps it's capath, and who knows what
happens with various combinations of certfile/keyfile.  So I think that
there should be a new "tls [true|false]" directive, and that setting it
true without both certfile/keyfile should be an error, and setting it
false and giving either should be an error.  Plus capath without tls
true would be an error.  As a transition, whatever makes tls turn on now
can continue to do so with a warning.  And perhaps the "listening on"
log statments would indicate TLS.  Right now I get:

  Jul  3 20:38:44 foo mosquitto[26387]: Opening ipv6 listen socket on port 8883.
  Jul  3 20:38:44 foo mosquitto[26387]: Opening ipv4 listen socket on port 8883.
  Jul  3 20:38:44 foo mosquitto[26387]: Opening ipv6 listen socket on port 1883.
  Jul  3 20:38:44 foo mosquitto[26387]: Opening ipv4 listen socket on port 1883.

which does not say that the first two lines (for the second listener :-)
are using TLS.

I realize I can hack around and get something to sort of work.  But I am
taking the perhaps cantankerous view that it should be possible to read
the docs and construct a config file, that after doing so others can
inspect the config file for defects against the docs, and that running
it will reliably work as intended.  I don't mean to complain that this
isn't the case, as much as point out places where the docs can be
improved to get closer to how I think things should be.