[Ovmsdev] OTA status check timeout / SSL problem?

[Mark Webb-Johnson]

Not at the moment.

From my understanding, there are two ways to do this (not mutually exclusive):

Signed firmware

This is the most comprehensive way. It involved a public key stored on the OVMS module itself (burned into e-fuses), and a private key used to sign binaries. The boot loader will then refuse to load any App who’s signature doesn’t match. Works with flash encryption as well.

The problem with this is it conflicts with the nature of open source. Once an ESP32 chip is put in that mode, it will only execute code signed with that private key. We can’t make that public (without destroying the entire security).

HTTPS

This at least provides some protection. We can validate the SSL certificate of the server (api.openvehicles.com <http://api.openvehicles.com/>) and protect somewhat from man-in-the-middle attacks.

It doesn’t protect against other side-load attacks (such as SD CARD firmware load) - but those require physical access which is pretty much game over anyway, right?

I would like to do #2, and made allowance for that with ‘ota flash http’ leaving room for ‘ota flash https’. Just our http client library is pretty crappy at the moment, and it will take some effort to make it support https.

Regards, Mark.

> On 6 Apr 2018, at 10:57 PM, Tom Saxton <tom at idleloop.com> wrote:
> 
> I don’t have the full context for this discussion, but I’m wondering: is the OTA update mechanism protected against a man-in-the-middle attack?
>  
>      Tom
>  
> From: OvmsDev <ovmsdev-bounces at lists.openvehicles.com <mailto:ovmsdev-bounces at lists.openvehicles.com>> on behalf of Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>>
> Reply-To: OVMS Developers <ovmsdev at lists.openvehicles.com <mailto:ovmsdev at lists.openvehicles.com>>
> Date: Wednesday, April 4, 2018 at 11:51 PM
> To: OVMS Developers <ovmsdev at lists.openvehicles.com <mailto:ovmsdev at lists.openvehicles.com>>
> Subject: Re: [Ovmsdev] OTA status check timeout / SSL problem?
>  
> I think it was a fault on the  <>api.openvehicles.com <http://api.openvehicles.com/> config - that shouldn’t be redirecting to https.
>  
> I fixed it, and it should be ok now.
>  
> Regards, Mark.
>  
>> On 5 Apr 2018, at 12:44 AM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>  
>> Mark,
>> 
>> the server check for an OTA update now fails every time, times out after 10 seconds.
>> 
>> I think that's because the new server currently does a redirect from http to https also on the api.openvehicles.com <http://api.openvehicles.com/> host. Not sure why the module doesn't fail
>> directly on that, maybe it tries to validate the certificate which also does not match.
>> 
>> As the openvehicles server has frequent connectivity issues from here I've added a "nocheck" option to the ota status command and use that for the standard web
>> status page. The OTA page still checks for the update.
>> 
>> Regards,
>> Michael
>> 
>> -- 
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
>  
> _______________________________________________ OvmsDev mailing list OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>_______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180407/51afffd6/attachment.htm>