[Ovmsdev] SSL Support
Chris van der Meijden
chris at arachnon.de
Tue Feb 18 15:28:42 HKT 2020
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 -vgit branch -vgit describegit submodule statusdiff -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 at arachnon.d
> > e> 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). 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/m
> > > e' -u <emailaddress>:<password>
> > >
> > > or, using an API key:
> > >
> > > $ curl --verbose GET 'https://dashboard.hologram.io/api/1/users/m
> > > e' -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 at webb-johnso
> > > > n.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).
> > > >
> > > > 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 validateNo:
> > > > Provide a form to register a new account, then createWhat 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 addressEither 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 at 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).
> > > > >
> > > > >
> > > > >
> > > > > 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:
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > 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 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 at 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 at lists.openvehicles.com
> > > > > > >
> > > > > > > http://lists.openvehicles.com/mailman/listi
> > > > > > > nfo/ovmsdev
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > OvmsDev mailing list
> > > > > > OvmsDev at lists.openvehicles.com
> > > > > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > OvmsDev mailing list
> > > > > OvmsDev at lists.openvehicles.com
> > > > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > >
> > > _______________________________________________
> > > OvmsDev mailing list
> > > OvmsDev at lists.openvehicles.com
> > > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> > _______________________________________________
> > OvmsDev mailing list
> > OvmsDev at lists.openvehicles.com
> > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200218/e6e78708/attachment-0001.html>
More information about the OvmsDev
mailing list