Deployed on my server as well.

I've also added enabling TLS by default to the setup wizard, so new users by default will have strong encryption.

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.

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: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/182).

Maybe we can also provide a similar option for the Hologram registration, or at least some way to hand over the ICCID for registration.

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.

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.

Regards,
Michael


Am 11.02.20 um 07:27 schrieb Mark Webb-Johnson:

I looked into #6 (iOS App) and #5 (OVMS Server) and switching to use SSL is trivial in both.

The commit for the server side is already done and pushed. Running as tcp/6870 on www.openvehicles.com server. Perhaps @michael can do the same on his (so the servers are at least ready for this)?

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:


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 openvehicles.com or the server - which is something I have been reluctant to do).

We can remove the requirement for server password in one of two ways:

  1. 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).

  2. 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.

There is also the whole OAUTH thing we could just move to (probably in combination with option 2).

What do people think?

Regards, Mark.

On 10 Feb 2020, at 11:24 AM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:


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.

I think what we need is:

  1. A set of helper functions to make it easier for components to use SSL. Build on top of mongoose.

  2. A way to manage a list of trusted Certificate Authorities, including adding to the trusted list via:
    • Components providing Certificate Authorities in firmware.
    • Certificate Authorities in configuration.

  3. Extensions to ovms_server_v2 to support an SSL connection option.

  4. Extensions to ovms_server_v3 to support an SSL connection option.

  5. Extensions to the Ovms Server v2 code to support an SSL connection listener.

  6. Extensions to the iOS App to support an SSL connection option.

  7. Extensions to the Android App to support an SSL connection option.

  8. Migration of any components already supporting SSL to this new standardised approach.

  9. 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).

I will take on the majority of this project. I can do #1, #2, #3, #4, #5, and #6).

If anyone has any feedback on requirements, please let me know.

Regards, Mark.

_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev


_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev


-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26