[Ovmsdev] TLS CA question
Mark Webb-Johnson
mark at webb-johnson.net
Fri Mar 12 14:31:48 HKT 2021
I suggest to merge into for-v3.3 and just include it in the testing for that.
I have a tag ‘pre’ setup on api.openvehicles.com <http://api.openvehicles.com/> server to allow that ‘preview’ from for-v3.3 branch to be OTA updated automatically (I ran out of good names after edge, eap, and main). I build it when worthwhile. This allows me to easily run it in my cars for live testing.
Regards, Mark.
> On 12 Mar 2021, at 2:08 PM, Stephen Casner <casner at acm.org> wrote:
>
> Oh, you guys are not testing my mongoose-wolfssl branch, you are
> testing master and/or for-v3.3 branch. I see that commit
> c6911c91432cada337bef46f6a541af46304b5cf went into master on 2/11 but
> commit 9607979e91da7a53da1cd0bd8325ab390abe18bb is only on my
> mongoose-wolfssl branch.
>
> On master or for-v3.3 the SSH/SSL code is updated to 1.4.5/4.6.0 but
> mongoose is still using MBEDTLS for TLS.
>
> So, Craig, you're not actually "building/booting this" where this was
> referring to my wolfssl-based TLS. If you would like to do so, what
> rebasing and or merging is needed? Should my new code be moved over
> to a new branch from for-v3.3?
>
> Actually, I guess all of the changes to wolfssh and wolfssl components
> could be merged. The control of whether TLS goes through MBEDTLS or
> wolfssl is controlled by changes in mongoose.
>
> -- Steve
>
> On Fri, 12 Mar 2021, Mark Webb-Johnson wrote:
>
>> The for-v3.3 branch should be up-to-date and merged from master. It should have everything that master has.
>>
>> I see it has this:
>>
>> commit 9607979e91da7a53da1cd0bd8325ab390abe18bb
>> Author: Stephen Casner <casner at acm.org>
>> Date: Wed Feb 24 23:53:28 2021 -0800
>>
>> SSH: Don't emit error message if wolfssl debugging is unconfigured
>>
>> diff --git a/vehicle/OVMS.V3/components/console_ssh/src/console_ssh.cpp b/vehicle/OVMS.V3/components/console_ssh/src/console_ssh.cpp
>> index 21549bad..6fa0e5e5 100644
>> --- a/vehicle/OVMS.V3/components/console_ssh/src/console_ssh.cpp
>> +++ b/vehicle/OVMS.V3/components/console_ssh/src/console_ssh.cpp
>> @@ -177,9 +177,8 @@ void OvmsSSH::NetManInit(std::string event, void* data)
>> ESP_LOGI(tag, "Launching SSH Server");
>> wolfSSH_SetLoggingCb(&wolfssh_logger);
>> wolfSSH_Debugging_ON();
>> - if ((ret=wolfSSL_SetLoggingCb(&wolfssl_logger)) || (ret=wolfSSL_Debugging_ON()))
>> - ESP_LOGW(tag, "Couldn't initialize wolfSSL debugging, error %d: %s", ret,
>> - GetErrorString(ret));
>> + wolfSSL_SetLoggingCb(&wolfssl_logger);
>> + wolfSSL_Debugging_ON();
>> ret = wolfSSH_Init();
>> if (ret != WS_SUCCESS)
>> {
>>
>> But current code in both master and for-v3.3 branches is:
>>
>> ESP_LOGI(tag, "Launching SSH Server");
>> wolfSSH_SetLoggingCb(&wolfssh_logger);
>> wolfSSH_Debugging_ON();
>> if ((ret=wolfSSL_SetLoggingCb(&wolfssl_logger)) || (ret=wolfSSL_Debugging_ON()))
>> ESP_LOGW(tag, "Couldn't initialize wolfSSL debugging, error %d: %s", ret,
>> GetErrorString(ret));
>>
>> Seems commit c6911c91432cada337bef46f6a541af46304b5cf seems to have brought back the old code?
>>
>> Mark
>>
>>> On 12 Mar 2021, at 11:34 AM, Stephen Casner <casner at acm.org> wrote:
>>>
>>> Craig and Mark,
>>>
>>> I do have the OvmsSSH::NetManInit() function calling
>>> wolfSSL_Debugging_ON() which would be expected to return -174 meaning
>>> NOT_COMPILED_IN as Mark correctly found. At one point I had code to
>>> print that error messge because I was having trouble getting the
>>> wolfSSL debugging to work, but I took out that error message in
>>> commit 9607979e91da7a53da1cd0bd8325ab390abe18bb so now the return
>>> value is ignored. I'm baffled. I'll have to look deeper after
>>> dinner.
>>>
>>> My mongoose-wolfssl branch is off of master on 2/17. I should
>>> probably have rebased to the current master or perhaps merged it to
>>> for-v3.3 as Mark recently requested. Have you guys done that merge
>>> for what you are testing now?
>>>
>>> -- Steve
>>>
>>> On Fri, 12 Mar 2021, Mark Webb-Johnson wrote:
>>>
>>>> P.S. Error code -174 seems to be 'NOT_COMPILED_IN’.
>>>>
>>>> Regards, Mark.
>>>>
>>>>> On 12 Mar 2021, at 9:56 AM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
>>>>>
>>>>> Craig,
>>>>>
>>>>> I get the same (with for-v3.3):
>>>>>
>>>>> W (2940) ssh: Couldn't initialize wolfSSL debugging, error -174: Unknown error code
>>>>>
>>>>> I guess it is just a warning. Probably some debugging config setting.
>>>>>
>>>>> But wifi, web and others work ok for me. Only problems I have with for-v3.3 branch are (a) the web dashboard modem status, and (b) the TLS certificate verification against api.openvehicles.com <http://api.openvehicles.com/>. I am working on both.
>>>>>
>>>>> Regards, Mark.
>>>>>
>>>>>> On 12 Mar 2021, at 9:46 AM, Craig Leres <leres at xse.com <mailto:leres at xse.com>> wrote:
>>>>>>
>>>>>> On 3/10/21 11:23 PM, Stephen Casner wrote:
>>>>>>> Michael and anyone else who's game:
>>>>>>> I now have an updated mongoose-wolfssl branch ready to be tested. The
>>>>>>> reason for the 90-second lockup mentioned in the previous post is a
>>>>>>> whole lot of math for a prime-number validation that's part of the
>>>>>>> Diffie-Hellman step. It was actually 87 seconds for Mark's server and
>>>>>>> 28 seconds for Michael's due to differences in certificates. That
>>>>>>> prime-number validation is required for FIPS compliance, which WolfSSL
>>>>>>> supports, but we don't need it. I spent quite a while digging into
>>>>>>> this to find where the process was getting stuck. Finally I got help
>>>>>>> from WolfSSL support suggesting a configuration option that avoids
>>>>>>> this extra check.
>>>>>>> So now I have an implementation using mongoose with wolfssl that
>>>>>>> connects successfully to both servers with a 3-4 second delay. (I
>>>>>>> don't recall what the delay was for the MBEDTLS-based implementation.)
>>>>>>> I think the memory usage looks OK. I still have not taken any steps
>>>>>>> to reduce any resources used by the MBEDTLS code as accessed for other
>>>>>>> purposes.
>>>>>>> Included in the debugging was another version update on the Wolf code
>>>>>>> to wolfssh 1.4.6 and wolfssl 4.7.0.
>>>>>>
>>>>>> I tried building/booting this on my dev module( 3.2.016-66-g93e0cf3e); but for some time now the for-v3.3 branch has been broken for me. When the module first boots the web gui works long enough for me to login and then it times out. From that point on I can't get the web gui or ssh to respond. It will return pings. The serial console is fine (and that's how I switch back to build based on master).
>>>>>>
>>>>>> I just did a fresh reboot and captured the serial console output and noticed this:
>>>>>>
>>>>>> W (4484) ssh: Couldn't initialize wolfSSL debugging, error -174: Unknown error code
>>>>>>
>>>>>> I think it happened around the time I lost wifi connectivity.
>>>>>>
>>>>>> My sdkconfig is close to support/sdkconfig.default.hw31, I have CONFIG_SPIRAM_CACHE_WORKAROUND turned off along with a lot of vehicles.
>>>>>>
>>>>>> Craig
>>>>>> _______________________________________________
>>>>>> 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
> _______________________________________________
> 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/20210312/33cf18c1/attachment-0001.htm>
More information about the OvmsDev
mailing list