search

uNetworking / uSockets

Miniscule cross-platform eventing, networking & crypto for async applications
Apache License 2.0
1.29k stars 268 forks source link

Support for mbedTLS #60

Closed snej closed 5 years ago

snej commented 5 years ago

The project I work on very much needs TLS support, but we don't want to use OpenSSL. What would it take to get uSockets to work with mbedTLS?

Looks like it's "simply" a matter of reimplementing the SSL API in internal.h, i.e. rewriting ssl.c ... ? Is that a reasonable project for someone like me who's new to the codebase, but has C++ and networking expertise? Any words of advice or warnings?

ghost commented 5 years ago

Hello,

Yes you would only need to replace ssl.c with another implementation. Then we could add some ifdefs and make a folder, etc.

snej commented 5 years ago

I'm starting on it... Question: Is it OK with you if I implement it in C++ (but of course making all the required functions extern "C")? I haven't coded in plain C in years, and it's kind of painful.

ghost commented 5 years ago

Temporarily yes, it shouldn't be that hard to rewrite it in C later on

snej commented 5 years ago

I’ve gotten it working enough to open a TLS client connection and do an HTTP GET. Next I’ll test the server side and then try a more interactive protocol.

I’m a bit unclear about the division of labor between the loop, context and socket objects. In your implementation, what led you to store data in one vs another? In particular, storing data in a loop rather than a socket. I may have to arrange things somewhat differently in my code because mbedTLS doesn’t allow a single TLS context to be used for both server and client sockets.

Also, what is copying contexts used for?

ghost commented 5 years ago

What kind of error info are you thinking about? I do not want to expose 57 different system specific errors.

snej commented 5 years ago

(Nevermind about the errors, above; I shouldn't have sidetracked this issue! Filed #61 and deleted the equivalent comment above. I'll reply on the other issue's thread.)

I am still curious about the division of labor between loop/context/socket. You're registering the BIO callbacks at the loop level, which then means other fields related to I/O are stored at the loop level although they're really socket-specific. Is this a memory optimization based on the knowledge that the BIO functions are always called (indirectly) from the owning loop so there's no concurrency problem?

ghost commented 5 years ago

Yes the same BIO is shared among all SSL. Put as much as possible in the loop then add much as possible in the context then add little as possible in the socket. It's entirely single threaded

ghost commented 5 years ago

Closing due to inactivity

ghost commented 5 years ago

You mind sharing the code you have so far? I would like to check it against OpenSSL

snej commented 5 years ago

Sure -- https://gist.github.com/snej/a9cde8eb3f8ee0d228898f8715bb4f26

ghost commented 5 years ago

Kool, thanks

xingyun86 commented 4 years ago

Sure -- https://gist.github.com/snej/a9cde8eb3f8ee0d228898f8715bb4f26

Could you give me a copy code with mbedtls usockets? I want to use usockets with mbedtls too.

snej commented 4 years ago

I posted the code I had. I don't use this library anymore, so I don't have anything stable, sorry.

ghost commented 4 years ago

Btw, how is mbedTLS compared to OpenSSL, WolfSSL? Are there any benchmarks?

ghost commented 4 years ago

Every post, benchmark points towards mbedtls being complete shit in performance.

It has cleaner interfaces but performs really bad, the devs don't even care that they haven't added hardware accelerated support on ARM which makes it 10x slower than OpenSSL