[sr-dev] git:andrei/tcp_tls_changes: tls: deal with internal openssl buffering
Andrei Pelinescu-Onciul
andrei at iptel.org
Mon Jun 21 16:02:10 CEST 2010
Module: sip-router
Branch: andrei/tcp_tls_changes
Commit: 0d8b211d146dad87a5751928b44c6f791352559a
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=0d8b211d146dad87a5751928b44c6f791352559a
Author: Andrei Pelinescu-Onciul <andrei at iptel.org>
Committer: Andrei Pelinescu-Onciul <andrei at iptel.org>
Date: Sun Jun 20 18:58:58 2010 +0200
tls: deal with internal openssl buffering
SSL_read() will not only buffer data internally (behaviour
exacerbated by setting readahead to 1), but will also return the
decrypted data on a record basis (even if readahead is 1 and it
has read several records, it will return only the decrypted data
from the current record). SSL_pending() can be used to see if
there is more data buffered internally only if readaahead is not
set and if the SSL_read() returned because it did not have enough
space in the output buffer (it's useless for any other case
because it returns the bytes in the current record that can be
retrieved immediately and hence if SSL_read() stopped at a record
boundary it will return 0).
The solution is to repeat the SSL_read() call until the output
buffer is completely filled or error (repeat it even if it did
consume the whole input, it could still have the data buffered
internally).
In the case when the output buffer is completely filled, the
entire tls_read_f() call should be retried as soon as more space
becomes available (set RD_CONN_REPEAT_READ).
Fixes read data delayed until the next packet arrives or possible
lost reads (if no other data is sent and part of the previous
data is buffered inside openssl).
---
modules/tls/tls_server.c | 178 +++++++++++++++++++++++++++++++++------------
modules/tls/tls_server.h | 1 -
2 files changed, 130 insertions(+), 49 deletions(-)
Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=0d8b211d146dad87a5751928b44c6f791352559a
More information about the sr-dev
mailing list