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 <http://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:

* Website user account and password * Vehicle ID * Server password * Module password * Hologram account + password

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 <http://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 <mailto: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 <mailto: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

I forgot to answer one question:

...

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

Hologram has an API. Authentication is either by API key or username+password (from hologram.io <http://hologram.io/>). So, we could ask for the hologram credentials and then request to activate the SIM: POST https://dashboard.hologram.io/api/1/links/cellular/bulkclaim (the data is JSON containing things like the SIM ICCID, plan, zone, orgid (from user account), etc) For example, to retrieve your own account information: $ curl --verbose GET 'https://dashboard.hologram.io/api/1/users/me' -u <emailaddress>:<password> or, using an API key: $ curl --verbose GET 'https://dashboard.hologram.io/api/1/users/me' -u apikey:<apikey> I don’t see any API to create a hologram account. Regards, Mark.

On 17 Feb 2020, at 3:04 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

I guess about 50% of new user support requests are related to not understanding ’server password’, with the other 50% being vehicle ID registration and modification.

From a user’s point of view, they are very aware of web service usernames and passwords. They know how to register for an account, and are used to it. They know that when they get an App, they put in the corresponding website credentials and it simply works.

...

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

We have a to be careful, because many users have more than one vehicle on their account (at least on my server). I think from the user interface point of view it should be server username/email and password. We may implement it differently under the hood, but keep it as simple as possible for the user. Note that v3 MQTT works off username+password as well.

An API so that this could be done from the server / app makes good sense. Not too hard to do (in a standard way, with plugins for different backend servers). Something like:

Which server would you like to use? Do you already have an account? Yes: Enter username and password, then validate No: Provide a form to register a new account, then create What ID would you like to use for this vehicle?

I too would like to do away with pre-registered vehicle IDs, and was thinking about ways around this last week. The way I see this working is:

When the module logs on with a particular user+password and vehicle ID, if the vehicle record doesn’t exist we can simply add it. This is similar to the way MQTT does it. For the Apps, we can provide an API to enumerate the available vehicle IDs for user selection. I also like your suggestion for a QR code on the module for quick App setup. The server can continue to show the registered vehicles on each account. However, there is one issue here in that for v2 the vehicle ID must be unique on that server. For MQTT, it only needs to be unique for each user. We should change the database structure, and ovms_server.pl code, to add owner ID as a key field (along with Vehicle ID), to address this. The change is not too complex.

I did spend some time reviewing the v2 protocol, and it seems easy to add another protocol scheme. Our current scheme 0x30 is for RC4 encryption based on the server password. We can add say 0x40 for just plaintext within SSL. The MP-C and MP-A methods currently pass the encryption scheme, followed by some secure tokens and the vehicle ID for authentication. The 0x40 scheme can simply be passed the desired vehicle ID, plus the server username/email and password (or authentication token).

The other thing to think about is the password itself. If we simply use server username/email and password, then it becomes an issue if the password is changed. Suddenly, three different systems break. The module in particular is worrying (as a password change on the server would break the module). So perhaps best to use tokens, and have a way for a module/app to request a persistent token. We could present that on the server as authorised apps/modules, and provide a facility to cancel (delete) a token. That is a lot more secure as the user can easily see what is authorised. My suggestion is that authentication works based on:

Either server username OR server eMail address Either server password OR authentication token

Whatever we do, the concentration should be on v3 MQTT protocol. We need to eventually migrate the Apps to that, as it is the future. The other option is to forget about supporting this in v2, and concentrate solely on v3 MQTT. Get this new arrangement working with v3, upgrade the Apps to support it, and then migrate to that.

Regards, Mark.

...

On 16 Feb 2020, at 8:04 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:

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 <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 <http://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:

Website user account and password Vehicle ID Server password Module password Hologram account + password

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 <http://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:

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

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 <mailto: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:

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

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.

Extensions to ovms_server_v2 to support an SSL connection option.

Extensions to ovms_server_v3 to support an SSL connection option.

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

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

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

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

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 <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>

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

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

It sounds like your build system is not up to date, or sdkconfig parameters incorrect. Most likely MBEDTLS is not enabled. Can you make sure you have ‘git pull’, and ‘git submodule update’, and then provide: git status -v git branch -v git describe git submodule status diff -u support/sdkconfig.default.hw31 sdkconfig Can you also try a ‘make clean’, and then ‘make’? Regards, Mark.

On 18 Feb 2020, at 8:41 AM, Chris van der Meijden <chris@arachnon.de> wrote:

Today I checked out the new code and tried to compile OVMS.V3.

No success :-(

I get this error:

ovms_server_v2.cpp:791:10: error: 'struct mg_connect_opts' has no member named 'ssl_ca_cert' opts.ssl_ca_cert = MyOvmsTLS.GetTrustedList(); ^ ovms_server_v2.cpp:792:10: error: 'struct mg_connect_opts' has no member named 'ssl_server_name' opts.ssl_server_name = m_server.c_str();

I tried to figure out what goes wrong for about two hours now, but I'm stuck ...

Can you give me an hint on what goes wrong here?

Thanx

Chris

Am Montag, den 17.02.2020, 15:34 +0800 schrieb Mark Webb-Johnson:

...

I forgot to answer one question:

...

...

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

Hologram has an API. Authentication is either by API key or username+password (from hologram.io <http://hologram.io/>). So, we could ask for the hologram credentials and then request to activate the SIM:

POST https://dashboard.hologram.io/api/1/links/cellular/bulkclaim <https://dashboard.hologram.io/api/1/links/cellular/bulkclaim>

(the data is JSON containing things like the SIM ICCID, plan, zone, orgid (from user account), etc)

For example, to retrieve your own account information:

$ curl --verbose GET 'https://dashboard.hologram.io/api/1/users/me <https://dashboard.hologram.io/api/1/users/me>' -u <emailaddress>:<password>

or, using an API key:

$ curl --verbose GET 'https://dashboard.hologram.io/api/1/users/me <https://dashboard.hologram.io/api/1/users/me>' -u apikey:<apikey>

I don’t see any API to create a hologram account.

Regards, Mark.

...

On 17 Feb 2020, at 3:04 PM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:

I guess about 50% of new user support requests are related to not understanding ’server password’, with the other 50% being vehicle ID registration and modification.

From a user’s point of view, they are very aware of web service usernames and passwords. They know how to register for an account, and are used to it. They know that when they get an App, they put in the corresponding website credentials and it simply works.

...

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

We have a to be careful, because many users have more than one vehicle on their account (at least on my server). I think from the user interface point of view it should be server username/email and password. We may implement it differently under the hood, but keep it as simple as possible for the user. Note that v3 MQTT works off username+password as well.

An API so that this could be done from the server / app makes good sense. Not too hard to do (in a standard way, with plugins for different backend servers). Something like:

Which server would you like to use? Do you already have an account? Yes: Enter username and password, then validate No: Provide a form to register a new account, then create What ID would you like to use for this vehicle?

I too would like to do away with pre-registered vehicle IDs, and was thinking about ways around this last week. The way I see this working is:

When the module logs on with a particular user+password and vehicle ID, if the vehicle record doesn’t exist we can simply add it. This is similar to the way MQTT does it. For the Apps, we can provide an API to enumerate the available vehicle IDs for user selection. I also like your suggestion for a QR code on the module for quick App setup. The server can continue to show the registered vehicles on each account. However, there is one issue here in that for v2 the vehicle ID must be unique on that server. For MQTT, it only needs to be unique for each user. We should change the database structure, and ovms_server.pl code, to add owner ID as a key field (along with Vehicle ID), to address this. The change is not too complex.

I did spend some time reviewing the v2 protocol, and it seems easy to add another protocol scheme. Our current scheme 0x30 is for RC4 encryption based on the server password. We can add say 0x40 for just plaintext within SSL. The MP-C and MP-A methods currently pass the encryption scheme, followed by some secure tokens and the vehicle ID for authentication. The 0x40 scheme can simply be passed the desired vehicle ID, plus the server username/email and password (or authentication token).

The other thing to think about is the password itself. If we simply use server username/email and password, then it becomes an issue if the password is changed. Suddenly, three different systems break. The module in particular is worrying (as a password change on the server would break the module). So perhaps best to use tokens, and have a way for a module/app to request a persistent token. We could present that on the server as authorised apps/modules, and provide a facility to cancel (delete) a token. That is a lot more secure as the user can easily see what is authorised. My suggestion is that authentication works based on:

Either server username OR server eMail address Either server password OR authentication token

Whatever we do, the concentration should be on v3 MQTT protocol. We need to eventually migrate the Apps to that, as it is the future. The other option is to forget about supporting this in v2, and concentrate solely on v3 MQTT. Get this new arrangement working with v3, upgrade the Apps to support it, and then migrate to that.

Regards, Mark.

...

On 16 Feb 2020, at 8:04 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:

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 <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 <http://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:

Website user account and password Vehicle ID Server password Module password Hologram account + password

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 <http://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:

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

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 <mailto: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:

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

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.

Extensions to ovms_server_v2 to support an SSL connection option.

Extensions to ovms_server_v3 to support an SSL connection option.

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

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

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

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

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 <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>

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

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

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

---

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

Yes, unfortunately we cannot provide sdkconfig with the git, as everyone has their own small changes. So we provide the default sdkconfig in support directly. We also try to let people know (via this list) if there are changes suggested. The diff command I gave is a good way of seeing if you are up-to-date. Regards, Mark

On 18 Feb 2020, at 3:28 PM, Chris van der Meijden <chris@arachnon.de> wrote:

Hi Mark,

it is compiling again :-)

The build system was OK, status and submodules too. It was the sdkconfig.

When you check out "a blank canvas" and start the make you get some minimal sdkconfig. With the previous code, that sdkconfig compiled after adding some CONFIG_PPP_ parameters. Now, with the new code just adding the CONFIG_PPP_ parameters was not enough.

I now took the sdkconfig.default.hw31 and voila, everything runs fine :-)

Thanx for your help.

Regards

Chris

Am Dienstag, den 18.02.2020, 09:05 +0800 schrieb Mark Webb-Johnson:

...

It sounds like your build system is not up to date, or sdkconfig parameters incorrect. Most likely MBEDTLS is not enabled.

Can you make sure you have ‘git pull’, and ‘git submodule update’, and then provide:

git status -v git branch -v git describe git submodule status diff -u support/sdkconfig.default.hw31 sdkconfig

Can you also try a ‘make clean’, and then ‘make’?

Regards, Mark.

...

On 18 Feb 2020, at 8:41 AM, Chris van der Meijden <chris@arachnon.de <mailto:chris@arachnon.de>> wrote: Today I checked out the new code and tried to compile OVMS.V3.

No success :-(

I get this error:

ovms_server_v2.cpp:791:10: error: 'struct mg_connect_opts' has no member named 'ssl_ca_cert' opts.ssl_ca_cert = MyOvmsTLS.GetTrustedList(); ^ ovms_server_v2.cpp:792:10: error: 'struct mg_connect_opts' has no member named 'ssl_server_name' opts.ssl_server_name = m_server.c_str();

I tried to figure out what goes wrong for about two hours now, but I'm stuck ...

Can you give me an hint on what goes wrong here?

Thanx

Chris

Am Montag, den 17.02.2020, 15:34 +0800 schrieb Mark Webb-Johnson:

...

I forgot to answer one question:

...

...

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

Hologram has an API. Authentication is either by API key or username+password (from hologram.io <http://hologram.io/>). So, we could ask for the hologram credentials and then request to activate the SIM:

POST https://dashboard.hologram.io/api/1/links/cellular/bulkclaim <https://dashboard.hologram.io/api/1/links/cellular/bulkclaim>

(the data is JSON containing things like the SIM ICCID, plan, zone, orgid (from user account), etc)

For example, to retrieve your own account information:

$ curl --verbose GET 'https://dashboard.hologram.io/api/1/users/me <https://dashboard.hologram.io/api/1/users/me>' -u <emailaddress>:<password>

or, using an API key:

$ curl --verbose GET 'https://dashboard.hologram.io/api/1/users/me <https://dashboard.hologram.io/api/1/users/me>' -u apikey:<apikey>

I don’t see any API to create a hologram account.

Regards, Mark.

...

On 17 Feb 2020, at 3:04 PM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote: I guess about 50% of new user support requests are related to not understanding ’server password’, with the other 50% being vehicle ID registration and modification.

From a user’s point of view, they are very aware of web service usernames and passwords. They know how to register for an account, and are used to it. They know that when they get an App, they put in the corresponding website credentials and it simply works.

...

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

We have a to be careful, because many users have more than one vehicle on their account (at least on my server). I think from the user interface point of view it should be server username/email and password. We may implement it differently under the hood, but keep it as simple as possible for the user. Note that v3 MQTT works off username+password as well.

An API so that this could be done from the server / app makes good sense. Not too hard to do (in a standard way, with plugins for different backend servers). Something like:

Which server would you like to use? Do you already have an account? Yes: Enter username and password, then validate No: Provide a form to register a new account, then create What ID would you like to use for this vehicle?

I too would like to do away with pre-registered vehicle IDs, and was thinking about ways around this last week. The way I see this working is:

When the module logs on with a particular user+password and vehicle ID, if the vehicle record doesn’t exist we can simply add it. This is similar to the way MQTT does it. For the Apps, we can provide an API to enumerate the available vehicle IDs for user selection. I also like your suggestion for a QR code on the module for quick App setup. The server can continue to show the registered vehicles on each account. However, there is one issue here in that for v2 the vehicle ID must be unique on that server. For MQTT, it only needs to be unique for each user. We should change the database structure, and ovms_server.pl code, to add owner ID as a key field (along with Vehicle ID), to address this. The change is not too complex.

I did spend some time reviewing the v2 protocol, and it seems easy to add another protocol scheme. Our current scheme 0x30 is for RC4 encryption based on the server password. We can add say 0x40 for just plaintext within SSL. The MP-C and MP-A methods currently pass the encryption scheme, followed by some secure tokens and the vehicle ID for authentication. The 0x40 scheme can simply be passed the desired vehicle ID, plus the server username/email and password (or authentication token).

The other thing to think about is the password itself. If we simply use server username/email and password, then it becomes an issue if the password is changed. Suddenly, three different systems break. The module in particular is worrying (as a password change on the server would break the module). So perhaps best to use tokens, and have a way for a module/app to request a persistent token. We could present that on the server as authorised apps/modules, and provide a facility to cancel (delete) a token. That is a lot more secure as the user can easily see what is authorised. My suggestion is that authentication works based on:

Either server username OR server eMail address Either server password OR authentication token

Whatever we do, the concentration should be on v3 MQTT protocol. We need to eventually migrate the Apps to that, as it is the future. The other option is to forget about supporting this in v2, and concentrate solely on v3 MQTT. Get this new arrangement working with v3, upgrade the Apps to support it, and then migrate to that.

Regards, Mark.

...

On 16 Feb 2020, at 8:04 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: 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 <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 <http://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: > > Website user account and password > Vehicle ID > Server password > Module password > Hologram account + password > > 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 <http://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: > > 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). > > 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 <mailto: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: >> >> A set of helper functions to make it easier for components to use SSL. Build on top of mongoose. >> >> 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. >> >> Extensions to ovms_server_v2 to support an SSL connection option. >> >> Extensions to ovms_server_v3 to support an SSL connection option. >> >> Extensions to the Ovms Server v2 code to support an SSL connection listener. >> >> Extensions to the iOS App to support an SSL connection option. >> >> Extensions to the Android App to support an SSL connection option. >> >> Migration of any components already supporting SSL to this new standardised approach. >> >> 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 <mailto:OvmsDev@lists.openvehicles.com> >> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> > > > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> > http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>

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

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

---

OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

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

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

And #2 now done. To add to the trusted CA list we can now add the CA into firmware (like the 3 already there), or put the PEM formatted certificate in /store/trustedca on the module itself. A set of commands (like ’tls trusted reload’, ’tls trusted list’, etc) are also now provided to help management. I’ve also added a short document to the user guide to explain this. Regards, Mark.

On 12 Feb 2020, at 3:25 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

I managed to get quite a lot done last night, and just committed my changes. Current status:

#1 is done. An extension had to be made to mongoose to support this, so please update submodules. I’ve added the trusted CAs for openvehicles, dexters (letsencrypt) and pushover.

#3 is done. A couple of lines of code. It is enabled by ‘config set server.v2 tls yes’.

#4 is done. A couple of lines of code. It is enabled by ‘config set server.v3 tls yes’.

#5 is done, and live on api.openvehicles.com <http://api.openvehicles.com/>.

#8 can start when ready. Have a look at the ovms_server_v[23] code for an example - it is literally a couple of lines to be added.

I did find a few servers that didn’t support the segment size negotiation option in SSL that we were relying on (including mosquitto!). So had to change my sdkconfig to:

CONFIG_MBEDTLS_SSL_MAX_CONTENT_LEN=16384

I suggest you do the same for best compatibility.

The rest is pending. I will work on #2 next, then move on to the iOS App.

Regards, Mark.

...

On 10 Feb 2020, at 11:24 AM, Mark Webb-Johnson <mark@webb-johnson.net <mailto: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:

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

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.

Extensions to ovms_server_v2 to support an SSL connection option.

Extensions to ovms_server_v3 to support an SSL connection option.

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

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

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

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

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 <mailto: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, I am getting: OVMS# script eval 'HTTP.Request({url: "http://dexters-web.de/f/test.json",always: function() { JSON.print(this, false); } });' I (140781) script: [eval:1:] {"url":"https://dexters-web.de/f/test.json","always":function () { [ecmascript code] },"redirectCount":1,"error":"","response":{"statusCode":200,"statusText":"OK","body":"{\"foo\":\"bar\"}","headers":[{"Date":"Fri, 14 Feb 2020 08:45:05 GMT"},{"Server":"Apache/2.2.15 (CentOS)"},{"Last-Modified":"Sun, 01 Dec 2019 20:36:31 GMT"},{"ETag":"\"73806cb-d-598aa6b0f7003\""},{"Accept-Ranges":"bytes"},{"Content-Length":"13"},{"Cache-Control":"max-age=0"},{"Expires":"Fri, 14 Feb 2020 08:45:05 GMT"},{"Content-Type":"application/json"}]}} OVMS# script eval 'HTTP.Request({url: "https://dexters-web.de/f/test.json",always: function() { JSON.print(this, false); } });' I (169991) script: [eval:1:] {"url":"https://dexters-web.de/f/test.json","always":function () { [ecmascript code] },"redirectCount":0,"error":"","response":{"statusCode":200,"statusText":"OK","body":"{\"foo\":\"bar\"}","headers":[{"Date":"Fri, 14 Feb 2020 08:45:34 GMT"},{"Server":"Apache/2.2.15 (CentOS)"},{"Last-Modified":"Sun, 01 Dec 2019 20:36:31 GMT"},{"ETag":"\"73806cb-d-598aa6b0f7003\""},{"Accept-Ranges":"bytes"},{"Content-Length":"13"},{"Cache-Control":"max-age=0"},{"Expires":"Fri, 14 Feb 2020 08:45:34 GMT"},{"Content-Type":"application/json"}]}} OVMS# metrics list version m.version 3.2.010-15-g931ca3d3-dirty/factory/edge (build idf v3.3-beta3-770-ge97f72ea2 Feb 13 2020 13:01:16) That seems correct to me. Maybe increased ram usage for you? I your memory status ok? The change I made to mongoose would only affect if the ca_cert started with “-----“. Nothing else should have changed (at least in that part). Maybe the increase of fragment size to 16384 has impacted something?

I've seen you set opts.ssl_server_name in server V2 & V3. This could be left NULL for using the hostname before, is it now necessary to set this?

I think you are right. I hadn’t noticed that default ca_cert != NULL, but server_name is null. I don’t think it is necessary to set explicitly, but should not matter. However, I have just noticed: void mg_ssl_if_conn_free(struct mg_connection *nc) { struct mg_ssl_if_ctx *ctx = (struct mg_ssl_if_ctx *) nc->ssl_if_data; if (ctx == NULL) return; nc->ssl_if_data = NULL; MG_FREE(ctx->ssl_cert); MG_FREE(ctx->ssl_key); MG_FREE(ctx->ssl_ca_cert); MG_FREE(ctx->ssl_server_name); memset(ctx, 0, sizeof(*ctx)); MG_FREE(ctx); } Which is scary. But that seems to be the ’simplessl’ version of that function. There are two other ones, for different SSL implementations, which seem to behave differently. That monolithic mongoose.{h,c} is really confusing to work through. Maybe I should look at their python mechanism to pack/unpack from individual scripts and then try to build a mongoose.{h,c} specific to our needs (without the crud we don’t use such as openssl, simplessl)? Regards, Mark.

On 14 Feb 2020, at 6:25 AM, Michael Balzer <dexter@expeedo.de> wrote:

Mark,

something's wrong now with the Mongoose SSL support. I could do this javascript call before (example from scripting API doc):

HTTP.Request({ url: "https://dexters-web.de/f/test.json" <https://dexters-web.de/f/test.json>, always: function() { JSON.print(this, false); } });

This now no longer works, neither with the previous opts.ssl_ca_cert = "*":

E (37350) mongoose: mg_ssl_if_mbed_err 0x3f85befc SSL error: -17040 I (37410) script: [eval:3:] {"url":"https://dexters-web.de/f/test.json" <https://dexters-web.de/f/test.json>,"always":function () { [ecmascript code] },"redirectCount":0,"error":"SSL error"}

…nor with opts.ssl_ca_cert = MyOvmsTLS.GetTrustedList(), it then sometimes fails with…

{"url":"https://dexters-web.de/f/test.json" <https://dexters-web.de/f/test.json>,"always":function () { [ecmascript code] },"redirectCount":0,"error":"Failed to create SSL session"}

…but mostly causes some kind of lockup (USB console not responding) and / or wifi / mongoose restart:

I (55980) wifi: bcn_timout,ap_probe_send_start I (58480) wifi: ap_probe_send over, resett wifi status to disassoc I (58480) wifi: state: run -> init (c800) I (58490) wifi: pm stop, total sleep time: 35296441 us / 53655320 us I (58490) wifi: new:<11,0>, old:<11,2>, ap:<11,2>, sta:<11,0>, prof:11 E (58490) mongoose: mg_ssl_if_mbed_err 0x3f85dd64 SSL error: -1 D (58520) events: Signal(server.web.socket.closed) I (58580) script: [eval:3:] {"url":"https://dexters-web.de/f/test.json" <https://dexters-web.de/f/test.json>,"always":function () { [ecmascript code] },"redirectCount":0,"error":"SSL error"} W (58600) wifi: Haven't to connect to a suitable AP now! W (58630) wifi: Haven't to connect to a suitable AP now! W (58640) wifi: Haven't to connect to a suitable AP now! W (58660) wifi: Haven't to connect to a suitable AP now! W (58680) wifi: Haven't to connect to a suitable AP now! W (58700) wifi: Haven't to connect to a suitable AP now! W (58720) wifi: Haven't to connect to a suitable AP now! W (58740) wifi: Haven't to connect to a suitable AP now! D (58770) events: Signal(system.event) D (58780) events: Signal(system.wifi.sta.disconnected)

I've seen you set opts.ssl_server_name in server V2 & V3. This could be left NULL for using the hostname before, is it now necessary to set this?

Regards, Michael

Am 13.02.20 um 08:26 schrieb Mark Webb-Johnson:

...

And #2 now done. To add to the trusted CA list we can now add the CA into firmware (like the 3 already there), or put the PEM formatted certificate in /store/trustedca on the module itself. A set of commands (like ’tls trusted reload’, ’tls trusted list’, etc) are also now provided to help management.

I’ve also added a short document to the user guide to explain this.

Regards, Mark.

...

On 12 Feb 2020, at 3:25 PM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:

I managed to get quite a lot done last night, and just committed my changes. Current status:

#1 is done. An extension had to be made to mongoose to support this, so please update submodules. I’ve added the trusted CAs for openvehicles, dexters (letsencrypt) and pushover.

#3 is done. A couple of lines of code. It is enabled by ‘config set server.v2 tls yes’.

#4 is done. A couple of lines of code. It is enabled by ‘config set server.v3 tls yes’.

#5 is done, and live on api.openvehicles.com <http://api.openvehicles.com/>.

#8 can start when ready. Have a look at the ovms_server_v[23] code for an example - it is literally a couple of lines to be added.

I did find a few servers that didn’t support the segment size negotiation option in SSL that we were relying on (including mosquitto!). So had to change my sdkconfig to:

CONFIG_MBEDTLS_SSL_MAX_CONTENT_LEN=16384

I suggest you do the same for best compatibility.

The rest is pending. I will work on #2 next, then move on to the iOS App.

Regards, Mark.

...

On 10 Feb 2020, at 11:24 AM, Mark Webb-Johnson <mark@webb-johnson.net <mailto: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:

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

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.

Extensions to ovms_server_v2 to support an SSL connection option.

Extensions to ovms_server_v3 to support an SSL connection option.

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

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

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

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

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 <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>

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

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

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev

That’s good news. An easy change. Regarding performance, I guess the vast majority is the asymmetric crypto during the initial rsa / ec negotiation. That is brutal even for desktop/server class stuff. Once the session is established, bulk symmetric crypto takes over and that is orders of magnitude faster. Session tickets would help for multiple requests, and not too hard to implement. They avoid the expensive asymmetric crypto for subsequent connections to the same server. But the majority of our stuff is reasonably long term connections. For the symmetric crypto part, we could also restrict the ciphers to those we have acceleration enabled in mbedtls, but that might impact compatibility. I haven’t had much chance to test big transfers yet. The OTA stuff is the most obvious - but that doesn’t currently use mongoose. Need to change the ovms_net and ovms_http classes to use mongoose wrapped in the blocking framework. Regards, Mark

On 14 Feb 2020, at 8:18 PM, Michael Balzer <dexter@expeedo.de> wrote:

 Mark,

it's really a memory issue, but I wouldn't have expected that, given… OVMS# mo me Free 8-bit 58944/271108, 32-bit 1900/27848, SPIRAM 3761072/4194252 Switching to vehicle NONE gave me OVMS# mo me Free 8-bit 69124/271108, 32-bit 1900/27848, SPIRAM 3802648/4194252 … and a working HTTP.Request with SSL (but it's sloooooow, see below).

I now did some more tests and could get it working with…

...

CONFIG_MBEDTLS_EXTERNAL_MEM_ALLOC=y … so I assume we need to add that change to our default sdkconfig as well.

Regarding the performance, SSL connections are somewhere beteen awful & unusable now. Test: (function(){ var t0 = performance.now(); HTTP.Request({ url: "http://ovms.dexters-web.de/f/test.json", always: function() { var t1 = performance.now(); print(this.url + " => " + (t1-t0).toFixed(0) + " ms, body.length=" + this.response.body.length); } }); })(); This gives me: I (520500) script: [eval:7:] http://ovms.dexters-web.de/f/test.json => 267 ms, body.length=13 I (550250) script: [eval:7:] https://ovms.dexters-web.de/f/test.json => 5347 ms, body.length=13 … up to … I (68270) script: [eval:7:] https://ovms.dexters-web.de/f/test.json => 11930 ms, body.length=13 … regardless of actually using the CA verification or reverting to "*".

I don't know how much of this is TLS session init overhead. Do you have better performance with the persistent V2 SSL connection? Haven't had time to test that yet.

Regards, Michael

Am 14.02.20 um 10:08 schrieb Mark Webb-Johnson:

...

Michael,

I am getting:

OVMS# script eval 'HTTP.Request({url: "http://dexters-web.de/f/test.json",always: function() { JSON.print(this, false); } });' I (140781) script: [eval:1:] {"url":"https://dexters-web.de/f/test.json","always":function () { [ecmascript code] },"redirectCount":1,"error":"","response":{"statusCode":200,"statusText":"OK","body":"{\"foo\":\"bar\"}","headers":[{"Date":"Fri, 14 Feb 2020 08:45:05 GMT"},{"Server":"Apache/2.2.15 (CentOS)"},{"Last-Modified":"Sun, 01 Dec 2019 20:36:31 GMT"},{"ETag":"\"73806cb-d-598aa6b0f7003\""},{"Accept-Ranges":"bytes"},{"Content-Length":"13"},{"Cache-Control":"max-age=0"},{"Expires":"Fri, 14 Feb 2020 08:45:05 GMT"},{"Content-Type":"application/json"}]}}

OVMS# script eval 'HTTP.Request({url: "https://dexters-web.de/f/test.json",always: function() { JSON.print(this, false); } });' I (169991) script: [eval:1:] {"url":"https://dexters-web.de/f/test.json","always":function () { [ecmascript code] },"redirectCount":0,"error":"","response":{"statusCode":200,"statusText":"OK","body":"{\"foo\":\"bar\"}","headers":[{"Date":"Fri, 14 Feb 2020 08:45:34 GMT"},{"Server":"Apache/2.2.15 (CentOS)"},{"Last-Modified":"Sun, 01 Dec 2019 20:36:31 GMT"},{"ETag":"\"73806cb-d-598aa6b0f7003\""},{"Accept-Ranges":"bytes"},{"Content-Length":"13"},{"Cache-Control":"max-age=0"},{"Expires":"Fri, 14 Feb 2020 08:45:34 GMT"},{"Content-Type":"application/json"}]}}

OVMS# metrics list version m.version 3.2.010-15-g931ca3d3-dirty/factory/edge (build idf v3.3-beta3-770-ge97f72ea2 Feb 13 2020 13:01:16)

That seems correct to me.

Maybe increased ram usage for you? I your memory status ok?

The change I made to mongoose would only affect if the ca_cert started with “-----“. Nothing else should have changed (at least in that part). Maybe the increase of fragment size to 16384 has impacted something?

...

I've seen you set opts.ssl_server_name in server V2 & V3. This could be left NULL for using the hostname before, is it now necessary to set this?

I think you are right. I hadn’t noticed that default ca_cert != NULL, but server_name is null. I don’t think it is necessary to set explicitly, but should not matter.

However, I have just noticed:

void mg_ssl_if_conn_free(struct mg_connection *nc) { struct mg_ssl_if_ctx *ctx = (struct mg_ssl_if_ctx *) nc->ssl_if_data; if (ctx == NULL) return; nc->ssl_if_data = NULL; MG_FREE(ctx->ssl_cert); MG_FREE(ctx->ssl_key); MG_FREE(ctx->ssl_ca_cert); MG_FREE(ctx->ssl_server_name); memset(ctx, 0, sizeof(*ctx)); MG_FREE(ctx); }

Which is scary. But that seems to be the ’simplessl’ version of that function. There are two other ones, for different SSL implementations, which seem to behave differently. That monolithic mongoose.{h,c} is really confusing to work through. Maybe I should look at their python mechanism to pack/unpack from individual scripts and then try to build a mongoose.{h,c} specific to our needs (without the crud we don’t use such as openssl, simplessl)?

Regards, Mark.

...

On 14 Feb 2020, at 6:25 AM, Michael Balzer <dexter@expeedo.de> wrote:

Mark,

something's wrong now with the Mongoose SSL support. I could do this javascript call before (example from scripting API doc):

HTTP.Request({ url: "https://dexters-web.de/f/test.json", always: function() { JSON.print(this, false); } });

This now no longer works, neither with the previous opts.ssl_ca_cert = "*":

E (37350) mongoose: mg_ssl_if_mbed_err 0x3f85befc SSL error: -17040 I (37410) script: [eval:3:] {"url":"https://dexters-web.de/f/test.json","always":function () { [ecmascript code] },"redirectCount":0,"error":"SSL error"}

…nor with opts.ssl_ca_cert = MyOvmsTLS.GetTrustedList(), it then sometimes fails with…

{"url":"https://dexters-web.de/f/test.json","always":function () { [ecmascript code] },"redirectCount":0,"error":"Failed to create SSL session"}

…but mostly causes some kind of lockup (USB console not responding) and / or wifi / mongoose restart:

I (55980) wifi: bcn_timout,ap_probe_send_start I (58480) wifi: ap_probe_send over, resett wifi status to disassoc I (58480) wifi: state: run -> init (c800) I (58490) wifi: pm stop, total sleep time: 35296441 us / 53655320 us I (58490) wifi: new:<11,0>, old:<11,2>, ap:<11,2>, sta:<11,0>, prof:11 E (58490) mongoose: mg_ssl_if_mbed_err 0x3f85dd64 SSL error: -1 D (58520) events: Signal(server.web.socket.closed) I (58580) script: [eval:3:] {"url":"https://dexters-web.de/f/test.json","always":function () { [ecmascript code] },"redirectCount":0,"error":"SSL error"} W (58600) wifi: Haven't to connect to a suitable AP now! W (58630) wifi: Haven't to connect to a suitable AP now! W (58640) wifi: Haven't to connect to a suitable AP now! W (58660) wifi: Haven't to connect to a suitable AP now! W (58680) wifi: Haven't to connect to a suitable AP now! W (58700) wifi: Haven't to connect to a suitable AP now! W (58720) wifi: Haven't to connect to a suitable AP now! W (58740) wifi: Haven't to connect to a suitable AP now! D (58770) events: Signal(system.event) D (58780) events: Signal(system.wifi.sta.disconnected)

I've seen you set opts.ssl_server_name in server V2 & V3. This could be left NULL for using the hostname before, is it now necessary to set this?

Regards, Michael

Am 13.02.20 um 08:26 schrieb Mark Webb-Johnson:

...

And #2 now done. To add to the trusted CA list we can now add the CA into firmware (like the 3 already there), or put the PEM formatted certificate in /store/trustedca on the module itself. A set of commands (like ’tls trusted reload’, ’tls trusted list’, etc) are also now provided to help management.

I’ve also added a short document to the user guide to explain this.

Regards, Mark.

...

On 12 Feb 2020, at 3:25 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

I managed to get quite a lot done last night, and just committed my changes. Current status:

#1 is done. An extension had to be made to mongoose to support this, so please update submodules. I’ve added the trusted CAs for openvehicles, dexters (letsencrypt) and pushover.

#3 is done. A couple of lines of code. It is enabled by ‘config set server.v2 tls yes’.

#4 is done. A couple of lines of code. It is enabled by ‘config set server.v3 tls yes’.

#5 is done, and live on api.openvehicles.com.

#8 can start when ready. Have a look at the ovms_server_v[23] code for an example - it is literally a couple of lines to be added.

I did find a few servers that didn’t support the segment size negotiation option in SSL that we were relying on (including mosquitto!). So had to change my sdkconfig to:

CONFIG_MBEDTLS_SSL_MAX_CONTENT_LEN=16384

I suggest you do the same for best compatibility.

The rest is pending. I will work on #2 next, then move on to the iOS App.

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:

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

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.

Extensions to ovms_server_v2 to support an SSL connection option.

Extensions to ovms_server_v3 to support an SSL connection option.

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

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

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

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

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

_______________________________________________ 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 _______________________________________________ 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 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev