search

Moddable-OpenSource / moddable

Tools for developers to create truly open IoT products using standard JavaScript on low cost microcontrollers.
http://www.moddable.com
1.32k stars 236 forks source link

tls.json manifest bundles unused ca.subject and probably ca.ski #691

Closed gavrilyak closed 3 years ago

gavrilyak commented 3 years ago

There are no references in source to ca.subject resource, but it is bundled and adds 4k to flash size. There are references to ca.ski in modules/crypt/ssl/ssl_cert.js , but at least in my case it is safe to delete, freeing 4k more.

phoddie commented 3 years ago

Good observation. Thanks for passing that along. I believe ca.subject is historic and can safely be removed. I'll double check that and make the change.

As you note, ca.ski is still used. It is used to quickly resolve to the built-in certificates. If you are providing your own certificate (as I'm guessing you are?), that isn't necessary and can be safely removed. Removing it by default would break existing code, but perhaps there's a way to run if it isn't present.

gavrilyak commented 3 years ago

Yes, I am using my own certs, your guessed right. I added "~": ["$(MODULES)/crypt/data/ca"] to my app manifest and that's seems to fix issue for me. Is that a proper way?

Thank you!

phoddie commented 3 years ago

Yes, using "~" to exclude the resources is a good solution.

I've removed ca.subject from the build for our next update. Every byte counts, so that will help -- especially on an ESP8266 with just 1 MB of code space.

I've left ca.ski because many projects rely on it. When we get to revisiting the SecureSocket implementation (perhaps as part of future Ecma-419 standardization) it would also be a good time to rework the handling of certificates.

I'm curious.... did you run into this because you were having flash space pressure in a project or by reviewing code or link maps? It is a subtle mistake to notice.

gavrilyak commented 3 years ago

That was totally accidentally and it's a long story :-) I wanted to run mqtt client to AWS IoT in simulator because it's faster to develop this way. But I couldn't connect, though everything works perfectly on Moddable Two. One difference in my case was certificate storage: I'm using raw flash "factory" partition on ESP and Resource on simulator. And one of my certs was named ca.der, so there was a subtle name collision here and I renamed my file. But I was curios and tried to remove ca.subject and ca.ski. Turned out that problem was with buffer size in modSocket.c for Linux, so I patched that:

-#define kTxBufferSize 1024
+#define kTxBufferSize 1024*4

Connection crashed during handshake, because I need to send 2 certificates (device and my ca, AWS requirement) and total size of packet was larger than 1024. But finally it worked and without ca.subject and ca.ski. That's when I decided to share this finding, because yes, every byte counts, and probably that will help somebody. I didn't file issue about buffer size because I do not have a good idea how to easily fix that and probably simulator is not so important anyway. That was my story. Thank you for you time, hard work and very cool project!

phoddie commented 3 years ago

@gavrilyak - thanks for the background. Glad you tracked down the subtle error.

The buffer size on Linux is deliberately small, so that code running in the simulator experiences the reality that the device has limited network buffers. But, perhaps it is too aggressively small, if it is causing failures on Linux that don't happen on Moddable Two.