[Ovmsdev] OTA status check timeout / SSL problem?

[Michael Balzer]

Am 07.04.2018 um 09:34 schrieb Mark Webb-Johnson:
>> support for HTTPS will help but not be a 100% protection against MITM attacks.
>
> Why not? I think it should protect MITM ok - but certainly doesn’t address issues at the server end. Using SSL certificate verification, the client can verify
> the server certificate, and the encrypted SSL link should be sufficient to protect against tampering. But, no idea how good the ESP32 SSL library is for
> server certificate verification.

The main attack vector besides compromising the server itself is (of course) the CA system. If you're in control of a CA key, you can create whatever
certificate you need. There are currently about 1500 "trusted" CAs, any of them can possibly be used to produce fake certificates right now. even (or
especially?) the large ones.

https://blog.qualys.com/ssllabs/2017/09/26/google-and-mozilla-deprecating-existing-symantec-certificates

https://security.stackexchange.com/questions/42406/how-to-detect-the-nsa-mitm-attack-on-ssl


>> So we could store the public key in the firmware instead and use that to verify all downloads & uploads. That way, anyone can create his/her own key pair to
>> use for personal builds.
>> Installing a firmware with another key would still be possible by flashing via USB or SD.
>
> Can you elaborate how you suggest this would be done? During OTA download, I guess (as otherwise this would require boot loader work)?

Yes, I would check the firmware signature after download/upload and invalidate the file/partition if it doesn't match.

Regards,
Michael


>
> Regards, Mark.
>
>> On 7 Apr 2018, at 3:21 PM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>
>> Mark,
>>
>> support for HTTPS will help but not be a 100% protection against MITM attacks.
>>
>> Regarding code signing, I think we don't need the ESP32 chip level protection, the primary concern is malicious downloads / uploads.
>>
>> So we could store the public key in the firmware instead and use that to verify all downloads & uploads. That way, anyone can create his/her own key pair to
>> use for personal builds.
>>
>> Installing a firmware with another key would still be possible by flashing via USB or SD.
>>
>> Regards,
>> Michael
>>
>>
>> Am 07.04.2018 um 08:03 schrieb Mark Webb-Johnson:
>>> Not at the moment.
>>>
>>> From my understanding, there are two ways to do this (not mutually exclusive):
>>>
>>>  1. 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).
>>>
>>>  2. 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 <mailto: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
>>>>  
>>>> _______________________________________________ OvmsDev mailing list OvmsDev at lists.openvehicles.com
>>>> <mailto:OvmsDev at lists.openvehicles.com> 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
>>>
>>>
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at 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 at lists.openvehicles.com <mailto: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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180407/2ee5918e/attachment-0001.html>