[lwip-users] Re: SSL / HTTPS above lwIP

[Joe Eykholt]

> Date: Fri, 18 Mar 2011 08:55:52 +0100
> From: "Walter Saegesser"<address@hidden>
> Subject: [lwip-users] SSL / HTTPS above lwIP

> I have been working with lwIP for a few months now and it really works
> fine.
>
> Now I got the job to implement an HTTPS client, sending data to a server
> on the internet periodically. As far as I understand this is not a
> matter of the underlying TCP/IP stack. A SSL stack as well as an HTTP
> client reside in the application layer, don't they?

Yes.  At least, according to Wikipedia.  Maybe it should be though of as
an application to the transport layer below it and as a transport to
the application above it.  But I could be all wet.

> So there's no need
> to switch to another TCP/IP stack, e.g. commercial Interniche? Or am I
> wrong here?

Nothing inherent in SSL would make that necessary, but depending on
which SSL implementation you choose, it may have more natural interfaces
with another TCP/IP stack.

> Would there be a need to change the configuration of lwIP? Sorry, these
> may all be silly questions, but I simply don't know.

I can't think of a need.

> The other question is what SSL stack to use. There are open source
> solutions as CyaSSL or OpenSSL. (CyaSSL is claimed to be faster and up
> to 20 times smaller than OpenSSL). And there are commercial stacks like
> NicheStack SSL from Interniche or MatrixSSL from PeerSec.
>
> If anyone has experience with this subject, any advice - DOs and DON'Ts
> - would be appreciated a lot. Thanks in advance.

> Walter

I asked the same question here a while back and didn't see a response.
It's a very tough question to answer with any authority because there
are so many variables, depending on your application and environment.

I tried CyaSSL, PolarSSL, and matrixssl, they're all available both
open-source and commercially, and all will work over lwip.  You have
to decide which is best for your needs, but for me matrixssl fit best.
I think it's code size is similar to or smaller than the others and
maybe its RAM usage is a bit less, and has smaller stack usage.

I liked its interfaces because they're all asynchronous, if I recall,
or at least can be used that way.  I didn't want a separate thread for
each connection.  I didn't benchmark them.

I still don't have a much experience with this subject, but thought
I'd offer this anyway.  I'd be very interested in other opinions.

        Cheers,
        Joe