> From: owner-openssl-us...@openssl.org On Behalf Of Moisés Barba
Pérez
> Sent: Thursday, 05 May, 2011 14:52
> Firstly I apologize for my insistence about this topic but it is
very important to me.
> I cleared my head a little and I'm exposing my issue again:
> There is a client machine integrated in LDAP server (389 DS).
(Language nit: connected to, maybe integrated with, not integrated in.)
To my knowledge ldap(plain) is 389 and ldaps(SSL) is 636.
Your trace excerpts definitely are 636 (except one oddity below).
> in this client machine I tried to run "getent group", "sudo -l" or "id"
> and usually fail. I have tried to run these commands without ssl and
> everything is ok. The problem appears with ssl enabled.
Do you know what code actually does ldap or ldap+SSL client here?
I.e. Are those utilities modified to do or invoke ldap themselves,
or do they go through some kernel hook that comes back out to some
other thing, maybe a helper process? This could make a difference
in where errors get reported or recorded. On Unix they probably
should be in some syslog, but which? And *might* be somewhere else.
> I have captured traffic with wireshark and ... attached ...
> plain txt with 6 packages ... wireshark says that the transmission
> window is full and the client closes the connection.
(Language nit: packet(s) not package(s).)
This clearly doesn't have the MAC error you reported before;
did you fix/change something or did it just vanish?
Aside: this list seems to support binary attachments, so you could
probably provide the whole .pcap file if (1) it's not too big and
(2) it doesn't contain any sensitive data like passwords.
What you have here does not look like an SSL protocol problem,
and may or may not be an OpenSSL problem. Do you know if the ldap
client code uses OpenSSL's default blocking I/O, or if it does
something 'advanced' like nonblocking, BIO_pair, or custom BIO?
Does it (in your cases) do more than one request/response, and if so
are those sequential or do they (try to) pipeline or overlap?
#268 svr-39950 analyzes as window full but you omitted (filtered?)
the preceding packets which would show how big the window was,
what was in it, and for how long (although you're <2sec from
'reference' so it's not very long). I assume it's encrypted;
did or can you try eNULL so it's (still SSL but) readable?
Is at least the amount of data (about 251k) appropriate?
If you capture a nonSSL case, does it send and receive
the same ldap data (modulo timestamps and nonces and such)
or at least the same amount of data in the same pattern?
Is *some* of the received data acknowledged? I'd expect so,
since 251k is large for an early window (though not impossible),
unless a lot of this is handshake and maybe previous responses.
Could the wire acknowledgement (of the current response only)
be just in the stack (RCVBUF) or is there evidence that OpenSSL
has actually recv-ed, or the client code has recv-ed and
(we hope!) given to OpenSSL, some of it?
#269 39950-svr client immediately sends FIN and then RST.
That's odd; for (Open)SSL shutdown it should send an alert
first (although possibly you omitted/filtered that)
and even if the client went directly to the socket level,
perhaps because there has been an error (or it thinks so),
I would expect to see normal FIN,FIN *xor* abort RST.
But on a quick test it appears (at least some?) Linux
does FIN then immediate RST for linger 0. Yuck.
Is the client on Linux? sudo certainly implies some Unix.
Does the client display or log anything at this point in time?
Is there indication of a timeout happening, or any timeout that
should apply here, that you can increase at least for test?
Hmm- maybe in the omitted packets client called SSL_shutdown
and sent close_notify against a server flow which client didn't
SSL_read; will OpenSSL (discard and) recv from stack in that case?
I don't have time to read through source or set up a test now.
But if client did that because it thinks there's something wrong
with the data it's receiving, it really ought to say so.
#271,272 39951-svr send SYN recv SYNACK normally. This is
presumably the same client, or maybe a reincarnated one,
if it got an error just above, trying a new connection.
#287 svr8807-39950 rcvd RST -- I assume you omitted/filtered here.
Did client#39950 really send to server#8807 (soon) before this?
If so, re-using a port like that is very unusual, though legal.
If it didn't, it makes no sense at all for server to respond with
an unrelated port, unless either it is mangling packets or something
in between is doing so, and your addresses are very close which
*usually* implies same link and nothing in between.
#438 after ~40 sec 39951-svr send FIN. Clearly you've omitted or
filtered plenty here because this shows about 13k sent 26k rcvd,
and noticeable time passing.
#440 immediately send RST, like above except one packet in between?
#441 svr-39951 recv FIN, presumably sent before our RST got there.
#442 39951-svr sent second RST, presumably due to the overlap.
These look like a reasonable though unusual result of the unusual
but not illegal FIN-then-RST by the client.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
