[prev in list] [next in list] [prev in thread] [next in thread] 

List:       stunnel-users
Subject:    RE: SSL_read returned WANT_: retrying
From:       "Gorsuch, Eddy" <EGorsuch () Ciena ! com>
Date:       2004-06-12 13:48:34
Message-ID: 9349C1C5DF4ECB429F6D2586A7D778B223DAC0 () w2ksjexg05 ! ciena ! com
[Download RAW message or body]

OK, I tried your suggestion to use ssldump, but have some (minor) 
problems getting it to build on Solaris. When I did get it to build, 
I got core dumps when trying to use the encryption.
So I did a compromise, I used ssldump with the NULL-MD5 encryption 
from an ethereal dump. 

The client (stunnel) sends the data in 2 Application Data records, 
spread across many TCP/IP packets.
(1st Application Record is 16384+21 bytes across 31 TCP/IP packets,
 2nd Application Record is  5633+21 bytes across 11 TCP/IP packets,
 The last TCP/IP packet also contains the close_notify alert.)

The server (my embedded application) gets all this data, no problem.
It reads and writes the data from a 128 byte buffer, so it seems to 
send out all it's data in 128 byte chunks (which comes out to 149 bytes 
when wrapped into the SSL Application Records). These Application 
Records are packed into 512 byte TCP/IP records, so there are several 
AR's in each TCP/IP record, with some AR's split across a TCP/IP packet 
boundary. 
Every so often, the stunnel client glitches on a call to SSL_read 
(which returns SSL_ERROR_WANT_READ). Every one of these glitches is on 
one of the AR's that is split across the TCP/IP packet (makes sense), 
though most split AR's don't generate the glitch (OK, ye olde timing 
issue). When the glitch happens, the data in that AR record gets 
dropped (i.e. stunnel loses that 128 byte chunk of data from the 
server). I can see the data in the AR in the ethereal dump, and it 
looks fine when un-split (ssldump gave up on decoding the server 
data after the very first AR, though it did do all the client data OK).

My problem: why is stunnel dropping these records? And how do I fix it?

On another note: we can't seem to get stunnel to use the TLS v1.0 (or 
SSLv3.1) version of the protocol. It seems to always use SSLv3.0, even 
when specifying options=NO_SSLv3.


eddy
-- 
ed.dy \'ed-e-\ n [ME (Sc dial.) ydy, prob. fr. ON itha; akin to OHG ith-
   again], L et and 1a: a current of water or air running contrary to
   the main current; esp)X : a small whirlpool 1b: a substance moving
   similarly  2: a contrary or circular current  - eddy vb 



> -----Original Message-----
> From: Brian Hatch [mailto:bri@stunnel.org]
> Sent: Tuesday, June 08, 2004 21:39
> To: Gorsuch, Eddy
> Cc: stunnel-users@mirt.net
> Subject: Re: SSL_read returned WANT_: retrying
> 
> 
> 
> 
> > messages, I lose some data. Since I'm using (for this test) 
> the NULL 
> > encryption, I can see the data come across with ethereal, 
> so I see that 
> > my SSL server is sending back all the data.
> 
> Were I you, I'd use actual encryption and sniff it using
> ssldump instead, and feed it the private key so it can decrypt
> everything.  You'll get a lot better results than using eNULL,
> believe it or not.
> 
> -- 
> Brian Hatch                   # chmod o+x /bin/laden
>    Systems and
>    Security Engineer
> http://www.ifokr.org/bri/
> 
> Every message PGP signed
> 
[prev in list] [next in list] [prev in thread] [next in thread]