> From: owner-openssl-us...@openssl.org On Behalf Of Mr.Rout > Sent: Saturday, 03 December, 2011 02:59
Aside: this item was apparently delayed in master.openssl.org from 03.0758Z to 03.1907Z and delivered to my mailhost 03.1914Z. > Can somebody please clarify my silly questions ? I need to > understand the behavior of TLS client. Apparently in relation to RFC2818 which you mentioned earlier. Note that there are MANY TLS clients which are NOT HTTP. > 1. How do I verify that TLS Client send connection close > without sending Closure alert ? What do you mean verify? If you want an OpenSSL client to do it, just close the socket without first doing SSL_shutdown. On Unix if the program exits, or is killed by a signal like ^C or a debugger, that closes all files (normally) which for a TCP socket does socket close (FIN) but no TLS close-alert. On Windows these cases do an 'abnormal' TCP close (RST) and again no TLS close-alert. The peer may treat this the same as FIN without close-alert, or it may not. The server may log these always, sometimes, or never depending on the server and perhaps configuration. If you can't depend on the server, a network trace like wireshark or similar shows it. > 2. Is there any way to decrypt Application data (HTTP > data) on wireshark itself ? If using kRSA and you have/get the server's private key, yes. Edit / Preferences / Protocols / SSL and supply the keyfile. If using ephemeral or anonymous DH or ECDH, it is not generally possible to reconstruct keys from stored and transmitted data, called Perfect Forward Secrecy, although if either end uses OpenSSL with _tmp_[ec]dh_ keys that are known or logged, you could; it appears wireshark doesn't. Similarly for temporary (export) RSA, if the server uses _tmp_rsa_ that is known or logged; I don't know if wireshark does that and didn't bother testing because RSA-export is stupid and obsolete. > 3. How would I know whether any memory leak during > handshakes on TLS client ? Same as memory leak in any program. Try valgrind or similar. Or write your code so it's correct in the first place. > 4. Is it required both side need to send TLS Alert for a > failure handshake ? There are alert codes defined for (all?) handshake errors and preferred practice is to use them, but some programs or devices just close (or even abort) the TCP connection. Despite RFC 748, this cannot always be avoided. For any alert with level=failure, only one end sends it. The other end MUST abort the TLS handshake or connection and (always?) close the TCP connection. For an alert with level=warning, either or both ends may send it. For close-notify, best practice is for both to send, but as 2818 explains this is not always done and not strictly required. For other warnings, generally only one end will detect and send. > 5. What is Incomplete Close and Pre-mature close ? > In the context of 2818, paragraph 2.2 defines them. In other contexts they may mean various other things. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
