There are TLS control messages which could flow in either direction, spontaneously. Renegotiation (pre TLS 1.3), tickets (TLS 1.3), and so on.
I cannot comment on if your proposal would work or not, sorry.
From: Alex H <alexhultman@xxxxxxxxx>
Date: Saturday, May 19, 2018 at 5:03 AM
To: Rich Salz <rsalz@xxxxxxxxxx>, openssl-users <openssl-users@xxxxxxxxxxx>
Subject: Re: [openssl-users] Receive throttling on SSL sockets
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?
TLS is a bidirectional protocol. You can’t throttle only one side.
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?
--
openssl-users mailing list
To unsubscribe:
https://mta.openssl.org/mailman/listinfo/openssl-users
|
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
