<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Deployed on my server as well.<br>
<br>
I've also added enabling TLS by default to the setup wizard, so new
users by default will have strong encryption.<br>
<br>
The V2 connection performance is much better than with
HTTP.Request(), even the initial connect is done within ~3 seconds
normally. TX/RX afterwards has no significant delay.<br>
<br>
On auth: I think #1 will not help that much. #2 is an option. Most
needed is a way to bypass the need to register user & vehicle on
the server first. After filling in the module ID & password,
there should be an option to create a new server + vehicle account
and retreive the credentials simply by clicking a button (as
outlined previously: <a
href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/182">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/182</a>).<br>
<br>
Maybe we can also provide a similar option for the Hologram
registration, or at least some way to hand over the ICCID for
registration.<br>
<br>
Filling in credentials manually must still be possible of course,
but the standard case of a new user would be simplified as far as
possible.<br>
<br>
OAuth could simplify the App connection, but not substantially -- it
would only allow to skip entering the password. A better option here
would be to display the full App credentials as a QR code during the
setup (and on the server page), so the user just needs to scan that
to configure the App.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 11.02.20 um 07:27 schrieb Mark
Webb-Johnson:<br>
</div>
<blockquote type="cite"
cite="mid:B0E2840C-DF9C-410C-8C28-55A2A43C46F7@webb-johnson.net">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class=""><br class="">
</div>
I looked into #6 (iOS App) and #5 (OVMS Server) and switching to
use SSL is trivial in both.
<div class=""><br class="">
</div>
<div class="">The commit for the server side is already done and
pushed. Running as tcp/6870 on <a
href="http://www.openvehicles.com" class=""
moz-do-not-send="true">www.openvehicles.com</a> server.
Perhaps @michael can do the same on his (so the servers are at
least ready for this)?</div>
<div class=""><br class="">
</div>
<div class="">But before doing the iOS App, I think we should
discuss the bigger issue of authentication and passwords. Once
we SSL encrypt (and authenticate the server), we no longer need
to use the password for encryption (although we do need to use
something for authentication). Looking at a recent intro video
for OVMS reminded me of how many passwords we current have:</div>
<div class=""><br class="">
</div>
<div class="">
<ul class="MailOutline">
<li class="">Website user account and password</li>
<li class="">Vehicle ID</li>
<li class="">Server password</li>
<li class="">Module password</li>
<li class="">Hologram account + password</li>
</ul>
</div>
<div class=""><br class="">
</div>
<div class="">I think we must have website user account and
password. Some identifier for the vehicle is also probably
necessary (so we can have more than one vehicle per account). If
we use the website user+password for authentication, we don’t
need the server password (which is the one that causes the most
confusion). The module password perhaps needs to stay for local
admin. Same for hologram (unless we offer packages with credits
purchased under <a href="http://openvehicles.com" class=""
moz-do-not-send="true">openvehicles.com</a> or the server -
which is something I have been reluctant to do).</div>
<div class=""><br class="">
</div>
<div class="">We can remove the requirement for server password in
one of two ways:</div>
<div class=""><br class="">
</div>
<div class="">
<ol class="MailOutline">
<li class="">Simply extend/replace the MP-C / MP-A calls to
have an authentication mechanism passing the website user,
website password, and vehicle ID. The server would then
validate the user and password provided, and ensure that the
provided Vehicle ID matches a registered vehicle for that
user. No more ’server password’. This is close to what the
mqtt v3 protocol does already (except it doesn’t need the
vehicleid as everyone’s namespace is kept separate).<br
class="">
<br class="">
</li>
<li class="">Move to an authentication token system. Have some
API (HTTP or within the v2 protocol) to authenticate website
user+password and return a token (stored persistently in a
database). Subsequent API calls can simply pass that token
to authenticate themselves. A page on the website (similar
to our current vehicles page) could show the authenticated
tokens (apps/cars) and allow them to be cleared. There are
various standard mechanisms for this, and it is considered
better suited to API style usages with third party apps.</li>
</ol>
</div>
<div class=""><br class="">
<div>There is also the whole OAUTH thing we could just move to
(probably in combination with option 2).</div>
<div><br class="">
</div>
<div>What do people think?</div>
<div><br class="">
</div>
<div>Regards, Mark.</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 10 Feb 2020, at 11:24 AM, Mark Webb-Johnson
<<a href="mailto:mark@webb-johnson.net" class=""
moz-do-not-send="true">mark@webb-johnson.net</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8" class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode:
space; line-break: after-white-space;" class="">
<div class=""><br class="">
</div>
<div class="">Given that we use the mongoose library for
most of our stuff, adding SSL support should not be
hard. This would finally bring strong encryption and
server side authentication. Given the number of
attacks now on IoT devices that would not be a bad
thing.</div>
<div class=""><br class="">
</div>
<div class="">I think what we need is:</div>
<div class=""><br class="">
</div>
<div class="">
<ol class="MailOutline">
<li class="">A set of helper functions to make it
easier for components to use SSL. Build on top of
mongoose.<br class="">
<br class="">
</li>
<li class="">A way to manage a list of trusted
Certificate Authorities, including adding to the
trusted list via:<br class="">
</li>
<ul class="">
<li class=""><span style="caret-color: rgb(0, 0,
0);" class="">Components providing Certificate
Authorities in firmware.</span></li>
<li class=""><span style="caret-color: rgb(0, 0,
0);" class="">Certificate Authorities in
configuration.<br class="">
<br class="">
</span></li>
</ul>
<li class="">Extensions to ovms_server_v2 to support
an SSL connection option.<br class="">
<br class="">
</li>
<li class="">Extensions to ovms_server_v3 to support
an SSL connection option.<br class="">
<br class="">
</li>
<li class="">Extensions to the Ovms Server v2 code
to support an SSL connection listener.<br class="">
<br class="">
</li>
<li class="">Extensions to the iOS App to support an
SSL connection option.<br class="">
<br class="">
</li>
<li class=""><span style="caret-color: rgb(0, 0,
0);" class="">Extensions to the Android App to
support an SSL connection option.</span><br
class="">
<br class="">
</li>
<li class="">Migration of any components already
supporting SSL to this new standardised approach.<br
class="">
<br class="">
</li>
<li class="">Then we can open up the discussion of
the whole thing of passwords. We have far too many
of these at the moment (user account+password,
vehicle ID, server password, module password,
hologram account+password, etc). Once we have an
encrypted connection, we don’t need to use the
password for encryption, but merely for
authentication. That simplifies things, as we can
perhaps just use the user account+password for
most things (giving access to all vehicles
registered under that user account - in a similar
way to MQTT does it already for ovms_server_v3).</li>
</ol>
</div>
<div class=""><br class="">
</div>
<div class="">I will take on the majority of this
project. I can do #1, #2, #3, #4, #5, and #6).</div>
<div class=""><br class="">
</div>
<div class="">If anyone has any feedback on
requirements, please let me know.</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark.</div>
<div class=""><br class="">
</div>
</div>
_______________________________________________<br
class="">
OvmsDev mailing list<br class="">
<a href="mailto:OvmsDev@lists.openvehicles.com" class=""
moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br
class="">
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br
class="">
</div>
</blockquote>
</div>
<br class="">
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</body>
</html>