On Thu, Nov 16, 2000 at 11:16:24PM -0800, Dan Kegel wrote:
>>> My API proposal was meant to generate discussion. I realize it's not an
>>> especially practical direction to move OpenSSL in. Does the idea of
>>> an event-driven SSL API appeal to anybody, at least in the abstract?
>> Well, we nearly have a purely non-blocking model available to us, were it
>> not that sometimes our API calls just hang waiting for public key
>> operations to return. And with a slick non-blocking model, it's not that
>> hard to build an event-driven wrapper around the outside.
> Ah, but consider this: I have the feeling that much of the kludginess of
> the OpenSSL code is there to handle the fact that input arrives not
> as whole SSL Record Layer units, but in dribs and drabs, and lots of
> effort is expended in tracking where you are, and being able to resume
> at that point in the middle of a record on the next call.
> In a purely event-driven model, where the events corresponded to full
> SSL Record Layer units, there'd be none of that fractional state saving
> going on.
Actually it would, because *record* boundaries and handshake *message*
boundaries or alert boundaries need not be aligned, and data of the
various records layer content types may even be interleaved.
Collecting the bytes of an individual record is the easy part -- you
still have to parse its contents. If then layers are separated by
having them pass some sort of events too, then the code could become
clearer, yes; but the downside is that when breaking handshake records
in parts to collect handshake messages, virtual memory usage would go
up for the redundant copies. And the size limit is much higher for
handshake messages than for records, so we'd still have to have the
handshake layer look at incomplete messages to determine an individual
upper size limit for the message in question as 2^24-1 bytes is
usually not appropriate :-)
> While you could implement an event-driven API on top of classic OpenSSL,
> it's not interesting to me. I'm mostly interested in it as a vehicle for
> exploring how to make the OpenSSL source more comprehensible.
>
> The SSL_peek() function, for instance, is broken,
Actually both of them, ssl2_peek and ssl3_peek, appear to be broken
(in different ways), and should be fixed. I must have missed the
bug report, although I now found that you already reported it at
least twice.
--
Bodo Möller <[EMAIL PROTECTED]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
