From within a script/application started by the web server all you can see is the protocol version and cipher both sides agree too. To get anything more, i.e. the protocol version offered by the client, the ciphers offered etc you need to have control over the TLS stack of the server which you don't have from inside the script/application.

And even if you are inside the TLS stack you have don't get the kind of version of the TLS stack the client uses. There is nothing similar to a HTTP User-Agent header in TLS and all you could do is to try to fingerprint the client based on used TLS extensions, offered ciphers, handshake version etc and infer from this which TLS stack and version this might be.

But, if you want to know how clients will behave if you make changes to the server (like hardening ciphers and protocol version) the exact TLS implementation is not of much use. What you need are capabilities capabilities of the client which not only depend on the implementation but also on the configuration. I would instead recommend the following to find out if you will have problems with hardening:

• Have bad ciphers like RC4 at the very end and make the server enforce its own cipher preference. Then check SSL_CIPHER if a bad cipher was used. Since the server will choose the best cipher the client supports (based on the servers preference) you will find out this way if you have a client supporting only bad ciphers.
• Check SSL_PROTOCOL to see if client and server agree to a protocol version you will no longer support (like SSL 3.0 and maybe TLS 1.0). The server will pick the best version the client supports so if you server is capable of TLS 1.2 this will be TLS 1.2 with all modern browsers.
• Check SSL_TLS_SNI if the client supports the SNI extension. If not (like with IE 8 on XP) you must keep the SSL server on a dedicated IP address.