[openssl-users] Receive throttling on SSL sockets

[Alex H]

I think the best solution would be to simply state in the documentation of
my implementation that "throttling receives on SSL sockets will
significantly reduce data receive but will not guarantee a total halt".

Agree?

What do you think of the way Node.js handles this? They _must_ be using
some kind of internal backup queue for cases like these, right?

2018-05-19 11:02 GMT+02:00 Alex H <alexhultman at gmail.com>:

> Okay that's a good theoretical answer but practically not very useful.
>
> I know for instance Node.js to implement their Streams interface with both
> TCP and SSL sockets. They both have pause / resume functions for
> receive-throttling and I've tested it with SSL and it seems to work somehow.
>
> One solution (I guess?) would be to stop polling for readable until
> SSL_write demands data then immediately stop polling for readable again
> once SSL_write is happy. In the case of getting unwanted data while
> throttling then SSL_peek can be used instead of SSL_read. That would not
> guarantee no buildup but would work for the most part, right?
>
> Do you see any flaw with this? Could it still fail due to mass buildup
> when throttling for long?
>
> Den lör 19 maj 2018 04:57Salz, Rich via openssl-users <
> openssl-users at openssl.org> skrev:
>
>> TLS is a bidirectional protocol.  You can’t throttle only one side.
>>
>>
>>
>> *From: *Alex H <alexhultman at gmail.com>
>> *Reply-To: *openssl-users <openssl-users at openssl.org>
>> *Date: *Friday, May 18, 2018 at 7:21 PM
>> *To: *openssl-users <openssl-users at openssl.org>
>> *Subject: *[openssl-users] Receive throttling on SSL sockets
>>
>>
>>
>> How do you properly implement receive throttling on SSL sockets without
>> hindering writing?
>>
>>
>>
>> As opposed to raw TCP sockets, an SSL socket cannot be receive-throttled
>> simply by stop polling for readable events on the underlying raw TCP
>> socket. SSL_write still could require reading of data so simply stop
>> polling for readable would potentially hinder writing of data which is not
>> okay.
>>
>>
>>
>> Is there any such receive-throttling functionality in the SSL protocol
>> itself? I don't see how SSL_peek would solve the issue since I would still
>> be buffering (potentially uncontrolled amount of) data in a BIO.
>>
>>
>>
>> Even if I would _only_ enable readable polling when _absolutely needed_
>> as per SSL_write error, I still cannot guarantee not reading a chunk of
>> data (which I would then need to buffer up in a BIO since the application
>> is not expecting it).
>>
>>
>>
>> How are we supposed to solve this issue without potentially building up
>> backpressure?
>>
>>
>>
>> Thanks
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180519/5cbbc22b/attachment-0001.html>