Hey there,
On Thu, 26 Oct 2000, David Schwartz wrote:
> > The connection setup phase shouldn't need to be "special" - but of course
> > I don't know what interesting things you may be doing :-) If your model
> > requires that this is unique and otherwise you've got I/O logic built
> > around the smooth functioning of the dirty-to-clean and clean-to-dirty
> > traffic, then it would fail (just as the connection setup would) in the
> > event that the peer asked for a renegotiate of the session. The run-time
> > logic needs to assume that data could start to bounce between peers
> > without the continuing arrival of new data on the clean side of either
> > peer. If your logic achieves that, then as a result the "connection setup
> > phase" doesn't really need anything special beyond that (except of course
> > a call to start the SSL handshake in the first place).
>
> That's what I thought, but my test code deadlocked.
yeah, in my initial experimentations with this stuff ages ago, I saw a
fair few deadlocks ... kinda a case of the read and write operations
saying to each other "ok, you go next - no please, I insist, *you* go next
...".
> What I did at first is I wrote the code so that it's triggered by received
> data (either plaintext from higher level code or ciphertext from lower level
> code). When we get data to hand to the SSL code, we BIO_write it to the
> appropriate side and then call a 'churn' loop. The 'churn' loop attempts one
> BIO_read for each direction. If we get a successful read, we hand it to
> lower or higher level code as appropriate.
[snip rest of description + code]
Generally the problem becomes one of a chicken and egg. If you're trying
to do all your "writes" before your "reads", or vice versa, then the SSL
may refuse to accept a write until a suitable read has taken place
creating a deadlock. In fact it may refuse a write altogether if it's
mid-handshake/renegotiation and needs to finish conversing with the peer
before the stream can tunnel raw traffic again. Similarly, (and more
obviously) it may not have data to read until the relevant write has
happened. What's worth noting however is that a read or write that fails
is fairly low-cost.
The solution I generally use to ensure that there's no weird conditions
lurking that can still creep up and create problems, is to do a loop that
first tries writes on both sides (if either side, clean or dirty, had
traffic to deliver to the SSL machine), and reads on both sides. Doing
that entire loop twice should allow any dependency of operation to get
flushed out, leaving the SSL in a "spent" state (an appropriate but
perhaps uncomfortable term to use I think). I've had this approach work in
general for all SSL/TLS protocol levels and with renegotiates
mid-stream. As a result, the initial handshake isn't "special" in any real
sense.
I've just noticed a reply from Bodo actually spotting the precise problem
in your code :-) This stuff is kinda complicated because the SSL machine
is a complicated little beast. Trying to deal with it in terms of
WANT_READ/WANT_WRITE, and other such "intelligent state" concepts is more
than I'm prepared to rely on personally. Operation that happens on the
"clear" side of the SSL, such as SSL_read/write (if you're not using a BIO
in between you and the SSL) has very little to do with what can be going
on in terms of reads and writes on the dirty side of the SSL. I just treat
the SSL machine is a black-box with 2 sides, and in the event of data
arriving on either or both sides - I just whirl around the black box a
couple of times trying to write any data that's waiting and read anything
back out that it will give me. Any "redundant" calls are so thin and
immediate that you probably create less efficient code trying to
intelligently avoid such calls (and make only the "right" ones) than you
get by just doing them all and making sure you don't miss a combination.
:-)
Cheers,
Geoff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
