Thor Lancelot Simon wrote:
> On Fri, Aug 01, 2008 at 03:49:01PM +0200, Lutz Jaenicke wrote:
>
>> Thor Lancelot Simon wrote:
>>
>> The record size of the SSL record is predetermined by the sender with
>> 16k being the maximum size specified by the protocol.
>>
>
> 32K for SSLv2, no?
>
I stopped caring for SSLv2 quite some time ago.
>> In order to return the (decrytped and authenticated) data to the
>> application, the full record must have been received as the MAC
>> (Message Authentication Code) is at the end of the record and
>> checking it requires to calculate the hash over the complete record
>> anyway. Hence, SSL_read() will only return and provide data once
>> the full record has been recevied from the underlying socket.
>>
>
> Yes, I understand this. The problem is that since the API doesn't include
> SSL_select() or SSL_poll(), there's no way for an application to sleep
> once SSL_read() consumes the data out of the socket buffer. This means
> SSL_read() can't work quite like read(2) here -- it requires the "read to
> completion" behavior you mention.
>
Yes.
> This leads to another problem, actually:
>
> A malicious peer which sends data as fast as it can can get _more_ data
> into the socket buffer while the application is trying to "read to
> completion". This can deny service to _other_ peers.
>
This type of fairness has to be implemented by the application.
This will include modifying the event handling.
> Basically an event-driven application which had an event loop like this
> (which worked with the Unix model):
>
> while (1)
> {
> select(....)
>
> for(selected writable) {
> write(it all);
> }
> for(selected readable) {
> read(fixed size for fairness);
> }
> }
>
> Now has to do something like this:
>
> while (1)
> {
> select(....)
>
> for(selected writable) {
> SSL_write(it all);
> }
> for(SSL_pending() was true after last read) {
> SSL_read(another fixed size chunk);
> if (SSL_pending(this SSL)) {
> flag as "more coming" in private datastructure;
> }
> }
> for(selected readable) {
> SSL_read(fixed size for fairness);
> if (SSL_pending(this SSL)) {
> flag as "more coming" in private datastructure;
> }
> }
> }
>
> This will work, but it will require restructuring the event loops of
> many applications written to expect the Unix was (which is not great, but
> so long as it's documented, it's better).
>
What kind of application are you talking about?
So far I have not seen any appliation that is collecting data from different
peers based on a "amount of data sent" round robin fashion. More or
less every application tends to have a higher level protocol with
handshake etc. that is actually responsible to deal with the peers
data.
Even though the interface might seem read()/write() compatible on the
first glance it finally is not and probably can never be as the protocol is
using bidirectional traffic for both read and write such that a simple
"select" model cannot be used.
> The SSL_read() manual page should at least mention that it's unsafe to
> call select again if SSL_pending() comes true. At present, it doesn't
> mention SSL_pending() at all.
>
That is true indeed.
> And this will work only as long as we're guaranteed SSL_pending() will
> never actually read from the socket buffer, which someone might want to
> make a note of somewhere!
>
It better should not because actually SSL_pending() should be
usable in the blocking case as well which would not hold if it
would actually try going down the chain.
Best regards,
Lutz
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
