HTTPS support in lwip

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

HTTPS support in lwip

Sandeep
Hi all, 

Does lwip support HTTPS?

Is there any example HTTPS webserver application available? I saw an HTTP webserver example.

Thanks
Sandeep

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: HTTPS support in lwip

Antoine Zen-Ruffinen

Hi Sandeep,

 

Not directly. HTTPS means HTTP+SSL/TLS. SSL/TSL is what bring you the encryption on top of TCP/IP and bellow HTTP. I think this is out of scope of LwIP, the LwIP source does not enable this. But you can use some SSL/TSL library together with lwIP to build HTTPS applications. I have used the” wolfSSL” library with LwIP with success to make HTTPS. They are other alternative such as mbed TLS, Cyclone SSL, etc.. They are plenty of example, just look at they support section.

 

Regards,

 

Antoine

 

From: lwip-users [mailto:lwip-users-bounces+antoine=[hidden email]] On Behalf Of Sandeep V.L.
Sent: 17 May 2017 10:17
To: [hidden email]
Subject: [lwip-users] HTTPS support in lwip

 

Hi all, 

 

Does lwip support HTTPS?

 

Is there any example HTTPS webserver application available? I saw an HTTP webserver example.

 

Thanks

Sandeep


_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: HTTPS support in lwip

Noam weissman

Hi,

 

There is a base code for HTTPS in the Lwip master code that works with mbedTLS.

I have been in contact with Simon regarding this. Simon was very helpful but I was not

able to use it.

 

First of all the code is still in development and secondly you need lots of RAM.

 

At some point I think it will be released…

 

BR,

Noam.

 

From: lwip-users [mailto:lwip-users-bounces+noam=[hidden email]] On Behalf Of Antoine Zen-Ruffinen
Sent: Wednesday, May 17, 2017 2:55 PM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] HTTPS support in lwip

 

Hi Sandeep,

 

Not directly. HTTPS means HTTP+SSL/TLS. SSL/TSL is what bring you the encryption on top of TCP/IP and bellow HTTP. I think this is out of scope of LwIP, the LwIP source does not enable this. But you can use some SSL/TSL library together with lwIP to build HTTPS applications. I have used the” wolfSSL” library with LwIP with success to make HTTPS. They are other alternative such as mbed TLS, Cyclone SSL, etc.. They are plenty of example, just look at they support section.

 

Regards,

 

Antoine

 

From: lwip-users [[hidden email]] On Behalf Of Sandeep V.L.
Sent: 17 May 2017 10:17
To: [hidden email]
Subject: [lwip-users] HTTPS support in lwip

 

Hi all, 

 

Does lwip support HTTPS?

 

Is there any example HTTPS webserver application available? I saw an HTTP webserver example.

 

Thanks

Sandeep


_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: HTTPS support in lwip

goldsimon@gmx.de
Noam Weissman wrote:

First of all the code is still in development and secondly you need lots of RAM.


That "lots of RAM" is a limitation of TLS, not a limitation of mbed TLS or how lwIP uses it.
That code is still not finished though. And I have to come up with RAM/ROM numbers once it is finished...

Anyway, for devices where HTTPS is only one out of many services, that usage is far from ideal as it encrypts/decrypts data in the tcpip_thread. And during potentially slow/long encrypt/decrypt phases, nothing else can be done in lwIP (e.g. no packet processing, no ping, no ACKs...). A socket or netconn-based server might be a better idea for some...

Simon
_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: HTTPS support in lwip

Noam weissman

Simon,


If I was not clear, my apologies... lots of RAM due to the use of SSL and not LwIP


BR,

Noam.




From: lwip-users <lwip-users-bounces+noam=[hidden email]> on behalf of [hidden email] <[hidden email]>
Sent: Wednesday, May 17, 2017 9:34 PM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] HTTPS support in lwip
 
Noam Weissman wrote:

First of all the code is still in development and secondly you need lots of RAM.


That "lots of RAM" is a limitation of TLS, not a limitation of mbed TLS or how lwIP uses it.
That code is still not finished though. And I have to come up with RAM/ROM numbers once it is finished...

Anyway, for devices where HTTPS is only one out of many services, that usage is far from ideal as it encrypts/decrypts data in the tcpip_thread. And during potentially slow/long encrypt/decrypt phases, nothing else can be done in lwIP (e.g. no packet processing, no ping, no ACKs...). A socket or netconn-based server might be a better idea for some...

Simon

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: HTTPS support in lwip

Sandeep
Thank you all for the response.

I am planning to use an RTOS + lwip + mbedTLS in an embedded system which has 6MB flash memory and 768KB RAM. Goal is to run an https web server. RTOS could be eCOS or FreeRTOS; yet to be fixed.

@ Simon - Could you please give me a rough figure of how much RAM it may use, just to know whether it is viable in the above said system?

Regards
Sandeep
Reply | Threaded
Open this post in threaded view
|

Re: HTTPS support in lwip

goldsimon@gmx.de
Sandeep wrote:
> Could you please give me a rough figure of how much RAM it may
> use, just to know whether it is viable in the above said system?

The most consuming part is that TLS requires 16 kByte per direction and connection as encrypt/decrypt buffer.
As modern web browsers open multiple connections (~6?), that means you need >= 192 Byte only for TLS.

Of course that can be stripped down, but that's additional work to do.

Simon

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: HTTPS support in lwip

Noam weissman
Hi Simon,

Is there a way to limit the number of concurrent HTTP connection, say to one ?

If this can be done we may be able to run HTTPS with an overhead of about 40K for SSL/TLS

BR,
Noam.

-----Original Message-----
From: lwip-users [mailto:lwip-users-bounces+noam=[hidden email]] On Behalf Of Simon Goldschmidt
Sent: Thursday, May 18, 2017 3:07 PM
To: [hidden email]
Subject: Re: [lwip-users] HTTPS support in lwip

Sandeep wrote:
> Could you please give me a rough figure of how much RAM it may use,
> just to know whether it is viable in the above said system?

The most consuming part is that TLS requires 16 kByte per direction and connection as encrypt/decrypt buffer.
As modern web browsers open multiple connections (~6?), that means you need >= 192 Byte only for TLS.

Of course that can be stripped down, but that's additional work to do.

Simon

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: HTTPS support in lwip

goldsimon@gmx.de
Noam Weissman wrote:
> Is there a way to limit the number of concurrent HTTP connection, say to one ?

Listen backlog does not help much here. You'd have to close the listener after accepting the first connection.
Reopening it later might require SO_REUSE though.

Alternatively, you could set MEMP_NUM_TCP_PCB to 1 to allow only one TCP connection at all. I guess you'd additionally have to increase the prio of the connection pcb to prevent a new connection from closing the existing one (see tcp_alloc/tcp_kill_prio).

However, in both cases, the browser will still try to open more than one connection and get back a RST. I don't know if resources scheduled over such an attempted connection are retried on a different connection later? Last time I tried with Chrome, they were just missing when the page was rendered :-(


Simon

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: HTTPS support in lwip

Jan Menzel
In reply to this post by goldsimon@gmx.de
Hi Sandeep!
        I've an application where about 500kb of JS-Code, webpages and other
stuff is loaded by the browser initially. This does not require more
then 2..3 connections in parallel (a pool of 4 clients was always enough).
        At the end, the buffer size required for encrypting/decrypting
transmitted/received data is something, that depends on your setup and
on configuration options commonly available. So, if you carefully
control and debug your setup you probably can run with less memory.
        Also, memory (and other resources) heavenly depends on the certificate
validation and chain length which is something you might be also able to
control.
        I agree with Simon, generic HTTPS is something that requires lots of
RAM. But if you can control your setup, you might get a way with much less.
        You may wont to check the mbedTLS webpage to get numbers depending on
the configuration you select. You might then need to multiply this
numbers by 4..6 parallel connections...

        Jan

On 18.05.2017 14:06, Simon Goldschmidt wrote:

> Sandeep wrote:
>> Could you please give me a rough figure of how much RAM it may
>> use, just to know whether it is viable in the above said system?
>
> The most consuming part is that TLS requires 16 kByte per direction and connection as encrypt/decrypt buffer.
> As modern web browsers open multiple connections (~6?), that means you need >= 192 Byte only for TLS.
>
> Of course that can be stripped down, but that's additional work to do.
>
> Simon
>
> _______________________________________________
> lwip-users mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: HTTPS support in lwip

goldsimon@gmx.de
Jan Menzel wrote:
> At the end, the buffer size required for encrypting/decrypting
> transmitted/received data is something, that depends on your setup and
> on configuration options commonly available. So, if you carefully
> control and debug your setup you probably can run with less memory.

Jan, could you explain this a bit more detailed? How I see it, my memory
problems was the per-connection allocation and there, the biggest chunks
were the frame buffer for RX & TX (mbedTLS: *MBEDTLS_SSL_MAX_CONTENT_LEN
*define). Now if you know the pages served (or at least the algorithm
calling write), you know the required buffer for TX, but at least when
providing file upload via HTTPS (e.g. firmware update), I'm not sure how
the RX buffer could be reduced.

Unfortunately, the buffer size negotiation is not mandatory for web
browsers.


Simon

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: HTTPS support in lwip

Jan Menzel
On 18.05.2017 21:37, [hidden email] wrote:

> Jan Menzel wrote:
>>     At the end, the buffer size required for encrypting/decrypting
>> transmitted/received data is something, that depends on your setup and
>> on configuration options commonly available. So, if you carefully
>> control and debug your setup you probably can run with less memory.
>
> Jan, could you explain this a bit more detailed? How I see it, my memory
> problems was the per-connection allocation and there, the biggest chunks
> were the frame buffer for RX & TX (mbedTLS: *MBEDTLS_SSL_MAX_CONTENT_LEN
> *define). Now if you know the pages served (or at least the algorithm
> calling write), you know the required buffer for TX, but at least when
> providing file upload via HTTPS (e.g. firmware update), I'm not sure how
> the RX buffer could be reduced.
>
> Unfortunately, the buffer size negotiation is not mandatory for web
> browsers.
>
Thats my experience with openSSL too, MAX_CONTENT_LEN is a standardized
option that would be very need, but is not supported. To bad, that it's
not available on web browsers too...
        To my understanding, TLS needs large buffers only to hash data for
integrity checking. If you do not provide enough buffer space, you can
not validate the hash on incoming data and hence the data is invalid.
There is however no specific requirement to send data in large chunks.
Our firmware updates eg are send out in small chunks (I guess our server
guys are flushing the socket every <buffer size> to overcome the
limitation that they can not control openSSLs buffer size). Receive wise
we send data in small chunks (1k) and openSSL has no problem to handling
that.
        So if you don't need large file uploads, you can safely decrease the
buffers. http data requests are usually very small, so 1k shall be fine.
If you need file uploads, you either have to specify a browser that
accepts your limited buffer size or you have to provide the full 16k. I
don't know of any way to force a sender to send data in smaller chunks.
Maybe you can modify mbedTLS to provide 16k for reception and a smaller
buffer for transmission.
        Server-wise you might be able to reduce the memory requires by
providing a single task that accepts incoming connections and forwards
them to handler tasks that do the actual TLS-handshake and data
processing. Once the TCP connection has been established, there are no
specific timeout requirements anymore. Its application layer depended
then and to my experience, browsers have quite long timeouts. Blocking
incoming TCP connections would trigger timeouts in the OS/IP-Stack,
which shall be avoided.

        Jan

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: HTTPS support in lwip

ankish
In reply to this post by Sandeep
Hi i had a task to implement https server on the lpc mcu with lwip stack
running on it for ethernet communication
Currently a webserver is implemented on the product
Is there any refrence example to do so or is it even possible to implement a
secure server on it



--
Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: HTTPS support in lwip

goldsimon@gmx.de
Am 29.06.2019 um 12:21 schrieb ankish:
> Hi i had a task to implement https server on the lpc mcu with lwip stack
> running on it for ethernet communication
> Currently a webserver is implemented on the product
> Is there any refrence example to do so or is it even possible to implement a
> secure server on it

The raw API httpd included in our sources supports https by adding the
TLS layer. An implementation to use mbedTLS for this is included with
the sources. You just need to compile mbedTLS with lwIP (with the
correct options set) and it should work.

A decent simple example for this is still missing in our repository,
unfortunately.

Regards,
Simon

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: HTTPS support in lwip

Siva Munnaluri
We want to develop secure embedded WebServer in one of our product. Our
product is based on STM32F7 controller and we are using Atollic Truestudio
as IDE.
Our current product firmware is without RTOS.

Can you please share any sample Secure Server example code(without using any
RTOS) with lwip and mbed tls which can run on STM32F7 conttoller.




--
Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: HTTPS support in lwip

goldsimon@gmx.de
Am 05.08.2019 um 15:52 schrieb Siva Munnaluri:
> We want to develop secure embedded WebServer in one of our product. Our
> product is based on STM32F7 controller and we are using Atollic Truestudio
> as IDE.
> Our current product firmware is without RTOS.
>
> Can you please share any sample Secure Server example code(without using any
> RTOS) with lwip and mbed tls which can run on STM32F7 conttoller.

I've finally took the time to write an example:

http://git.savannah.nongnu.org/cgit/lwip.git/tree/contrib/examples/httpd/https_example/https_example.c

However, note that this is *not* meant for production environment:
Private keys should be kept in secure elements, not read from files.

Regards,
Simon

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: HTTPS support in lwip

Siva Munnaluri
Thanks Simon for HTTPS support in lwip with out RTOS. Its working fine



--
Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: HTTPS support in lwip

ankish
Hi siva what is the footprint of your https server and can you share you config.h for mbedtls

On Mon, Aug 12, 2019, 17:36 Siva Munnaluri <[hidden email]> wrote:
Thanks Simon for HTTPS support in lwip with out RTOS. Its working fine



--
Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

HTTP keep alive SSI

wilkxt
In reply to this post by goldsimon@gmx.de

Hi
I read this form "httpd_opts.h" file :
" * A downside of the current SSI implementation is that persistent connections
 * don't work, as the file length is not known in advance (and httpd currently
 * relies on the Content-Length header for persistent connections).
 *

Do you have a way to solve this problem? I need a permanent connection for xml.json.

--
regards
tomek

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: HTTP keep alive SSI

goldsimon@gmx.de
Hi Tomek,

are you aware of email threads and that you just hijacked another thread?
Never use the "reply" feature unless actually responding to a mail!

"tomek wilkxt" wrote:
> Hi
> I read this form "httpd_opts.h" file :
> " * A downside of the current SSI implementation is that persistent connections
>  * don't work, as the file length is not known in advance (and httpd currently
>  * relies on the Content-Length header for persistent connections).
>  *
>  
> Do you have a way to solve this problem? I need a permanent connection for xml.json.

You could use a form of HTTP chunked encoding, but I never got round to
implementing that.

Instead, I used custom files to create such JSON files (not using SSI). Your
custom file handler code can then set these files to have a length so that
a persistent connection is not a problem.

Regards,
Simon

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
12