#jwst.nasa.gov TLS issue

1 messages · Page 1 of 1 (latest)

sharp ocean
#

so it doesn't seem to be a cipher issue

#

Posting these links here for convenience:

viral widget
#

Could it be the key size? Or is 4096 a normal size?

sharp ocean
#

(same issue on esp32-s3)

soft moon
#

Interesting. Thanks for compiling all of this together here.

I have run into an issue on Android before where the the system time is "too far" off from the actual real time, and it starts causing HTTPS failures because it trusts the (incorrect) system time and concludes that the certificate is not valid because of the date. Could something like that be possible in CircuitPython? Is there anything that could need to be done explicitly before making HTTPS requests to update the datetime to current actual time?

#

My other thought is maybe it would be worthwhile to try writing a program that uses the ESPIDF directly to fetch this URL and verify whether it has the same issue (removing CircuitPython from the mix). If so maybe we can make an issue on the ESPIDF and they would be willing to look into the specifics further. I have limited experience with C though, I'm not sure what the process would be to try writing something that uses the IDF directly.

finite stump
#

Is there a buffer size limit for the server certificate. With all the SubjectAlternativeNames, that cert is 3,950 bytes.

sharp ocean
#

re: Date. We don't even send a Date header, and it doesn't seem to be an issue on other sites. I did add a Date header in the prior round of testing, but same issue.

#

I don't think it's Requests doing something funny. I tried it as a straight-up TCP socket, and got the same error on connect.

finite stump
#

Not sure if this helps, but the left side is a Feather ESP32-S2. The right is a desktop.

unknown.png
sharp ocean
#

esp-idf 4.4 app works (there was a ready-made example in the Espressif repo: https://github.com/espressif/esp-idf/tree/master/examples/protocols/https_request)```I (7021) example: Connection established...
I (7021) example: 157 bytes written
I (7021) example: Reading HTTP response...
HTTP/1.1 200 OK
Date: Tue, 08 Feb 2022 01:00:07 GMT
Server: WebServer/1.0
X-Frame-Options: sameorigin
Last-Modified: Mon, 07 Feb 2022 12:57:07 GMT
ETag: "5bb4f15-2ca-5d76d235165de"
Accept-Ranges: bytes
Content-Length: 714
Content-Type: application/json
Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: upgrade-insecure-requests

{ # ... }```However, there are unknown differences between my locally just-created esp-idf environment, and the CircuitPython esp-idf environment (menuconfig items, code inits, etc.), the details of which are way over my head.

#

(fwiw, I (338) cpu_start: ESP-IDF: v4.4-127-gf98ec313f2-dirty)

soft moon
#

Oooh that is a good sign at least. So theoretically if we could work out the differences between the esp-idf used in CircuitPython and the version 4.4 one and update the one we use, then it may resolve whatever is ultimately the root cause?

sharp ocean
#

Theoretically. I think.

#

I just have no idea why anything that low-level would be different.

#

All I changed in menuconfig was SSID & password. All I changed in the example code was the server/URL and port.

#

The example application does some things that seem very specific to the original example URL (for example, getting the root cert specifically for the example target host). There may be other ways it differs from the CP TLS connect implementation.