[Date Prev][Date Next]
Re: Problems when closing LDAPS sessions ?
At 02:12 AM 9/17/2004, VANHULLEBUS Yvan wrote:
>I use a slapd server (OpenLDAP 2.1.30 on FreeBSD 4.10),
This version is historic. I suggest you upgrade to at least
the latest stable version of OpenLDAP Software, and retest.
>clients (same version, same OS) to make LDAPS access to this server.
>Everything works fine, but if I have many requests at the same time
>(by "request", I mean "connect, request, disconnect"), some of them
>will timeout, without apparent reasons.
>After some investigations, I found what seems to be a problem when
>closing TLS sessions.
>Here is a dump of one connection (ethereal output):
> 1 0.000000 Client Server TCP 12085 > ldaps [SYN] Seq=255346966 Ack=0 Win=57344 Len=0
> 2 0.000045 Server Client TCP ldaps > 12085 [SYN, ACK] Seq=4179512178 Ack=255346967 Win=57344 Len=0
> 3 0.000236 Client Server TCP 12085 > ldaps [ACK] Seq=255346967 Ack=4179512179 Win=57408 Len=0
> 4 0.000936 Client Server SSLv2 Client Hello
> 5 0.002033 Server Client TLS Server Hello, Certificate, Server Hello Done
> 6 0.004940 Client Server TLS Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
> 7 0.017231 Server Client TLS Change Cipher Spec, Encrypted Handshake Message
> 8 0.017888 Client Server TLS Application Data, Application Data
>[Some more application data and ACKs between client and server]
>21 0.021257 Client Server TLS Encrypted Alert
>Here, client sends a SSL_shutdown.
>22 0.021275 Server Client TCP ldaps > 12085 [ACK] Seq=4179515399 Ack=255347678 Win=57339 Len=0
>Server sends it's TCP ACK for the shutdown packet.
>23 0.021302 Client Server TCP 12085 > ldaps [FIN, ACK] Seq=255347678 Ack=4179515399 Win=57408 Len=0
>Client closes it's TCP connection.
>24 0.021320 Server Client TCP ldaps > 12085 [ACK] Seq=4179515399 Ack=255347679 Win=57371 Len=0
>25 0.021602 Server Client TLS Encrypted Alert
>Server wants to send it's SSL_shutdown
>26 0.021621 Server Client TCP ldaps > 12085 [FIN, ACK] Seq=4179515436 Ack=255347679 Win=57408 Len=0
>Server's TCP FIN.
>27 1.216566 Server Client TLS Encrypted Alert
>28 3.417394 Server Client TLS Encrypted Alert
>29 7.618977 Server Client TLS Encrypted Alert
>30 15.822066 Server Client TLS Encrypted Alert
>31 20.793937 Server Client TLS Encrypted Alert
>32 32.028167 Server Client TLS Encrypted Alert
>33 36.379810 Server Client TLS Encrypted Alert
>Now here is the problem:
>Client -> server side of the TCP session is already closed when the
>server wants to send it's SSL_shutdown, so this SSL_shutdown will
>*never* be ACKed !
>And server's TCP/IP stack will resend this packet.
>And if I do a netstat -an on server side, I'll have that:
>tcp4 0 37 Server.636 Client.ephemeral LAST_ACK
>(and one similary line for each connection).
>And sometime, it looks like slapd goes in some kind of "big timeout"
>and tries to clean all it's LAST_ACK connections.
>I think there is at least one problem with the TCP/IP stack, which
>should detect it cannot receive this ACK (but I may be wrong).
>But for what I know about SSL (I am *NOT* an SSL/TLS expert !!), there
>also seems to be a problem with SSL_shutdown.
>Can an SSL expert confirm this problem ?
>Is there an option to reduce/resolve this problem ?