On 20/11/20 19:22, W. Michael Petullo wrote:
I think making use of self-signed certificates in production is a bad
idea because (1) it reinforces poor practices, namely electing to trust
a self-signed certificate and (2) it does not authenticate the
server/router, a critical piece of the TLS security model.
maybe, but it's still better than sending all communication to the
management interface as plain text.
What is the difference between transmitting packets containing cleartext
and transmitting encrypted packets to a party whose identity you do
not know?
What are you talking about? After the initial "pairing" process where you
see the warning, the browser remembers the certificate for all subsequent
connections.
If the certificate changes (and it will change only if you do a firmware
reset to default settings) you will see the the warning again.
So you are just changing a CA-based system to a local pairing system.
(I really do not mean for any of my comments here or earlier to be
patronizing. I am just trying to describe my point of view.)
When I make the first SSH connection to a new router, I confirm the
fingerprint of the router's key using a serial-port connection. Thus
I know it is safe to accept the pairing. If I were to skip this step,
then I would have no assurance regarding to whom my encrypted messages
were being sent now and in the future.
I think that if the first setup is done with only the router and the
trusted PC connected to it through an ethernet cable (wifi is disabled
by default), there is physically nothing else on that "network" so
whatever you see can be accepted even if you don't have "dual
authentication" with the serial port.
The only way for that to go bad is if your PC isn't trusted, but if
that's the case, using a serial console from the same PC won't help much.
Although I understand what you mean.
How would our scheme recreate this? What would the interface provide
to the user to help them perform this step? What would it recommend?
Some tugging on Luiz Angelo Daros de Luca's proposal earlier in this
thread (Fri, 20 Nov 2020 14:25:10), especially the addition of a suggested
verification process, might help.
How can you recreate a secure two-step verification process without two
different communication mediums? I don't think it is possible, so this
isn't viable.
Imho the only thing that can be done for most devices is adding a http
landing page that explains how to do the first pairing in the most
secure way, like I said above.
"make sure the device is connected through an ethernet cable to a
trusted PC only, and that there are no other ethernet cables connected
to this device, when you are ready to accept the self-signed certificate
press OK button"
And when you press OK it will redirect to https and you will get the
warning and must accept it.
Does it make sense to add this kind of "first setup" webpage to the
device's web interface? Maybe.
I have already mentioned some time ago in the older version of this
discussion that 99% of the users that are doing this for the first time
are going to be following some documentation anyway, so we could just
write this down in the install tutorial in the wiki.
-Alberto
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
