Re: [lwip-users] HTTPS support in lwip

[Jan Menzel]

On 18.05.2017 21:37, address@hidden 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