[Ovmsdev] SSL Support

Tue Feb 11 16:50:25 HKT 2020

I just set up the new OVMS server for my domain. Everything works fine.
I created the ovms_server.pem with the command
openssl req -sha256 -newkey rsa:4096 -nodes -keyout privkey.pem -x509
-days 730 -out fullchain.pem
After that I merged privkey.pem and fullchain.pem to ovms_server.pem
and put it alongside ovms_server.pl
I can see my self-signed certificate by opening https://www.arachnon.de
:6869/api/vehicles in a browser. 
Ready for testing :-))
Authentication within OVMS can be simplyfied I think too. As for
authorisation I prefer OAUTH. Though for me it is important to
implement the possibilty for my own  OAUTH provider service within OVMS
to stay independent. 
Greetinx
Chris

Am Dienstag, den 11.02.2020, 14:27 +0800 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 passwordVehicle IDServer passwordModule
> passwordHologram 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.n
> > et> 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/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/20200211/8396df08/attachment.htm>