<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=windows-1252">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 13/11/2015 10:34, Matt Caswell
wrote:<br>
</div>
<blockquote class=" cite" id="mid_5645AEB7_6040608_openssl_org"
cite="mid:5645AEB7.6040608@openssl.org" type="cite">
<pre wrap="">
On 13/11/15 02:56, pratyush parimal wrote:
</pre>
<blockquote class=" cite" id="Cite_710027" type="cite">
<pre wrap="">Hi,
I'm writing a client-server program that uses TLS for communication.
I'm wondering if there's any way to programmatically find out which TLS
protocol versions are supported by the OpenSSL library installed on my
system.
I'm currently aware of three ways which "sort of" provide this information:
(1) After setting up the TLS communication, call: SSL_get_version(ssl);
which returns "TLSV1.2", etc.
(2) Try to connect to a server using TLS by specifying all possible TLS
versions in the client program, and see which connections pass/fail.
(3) Call: SSL_get_ciphers(), print their names, and try to correlate
them with the protocol they're associated with.
Unfortunately, none of the above answer my question completely.
So is it possible to ascertain which TLS protocol versions are actually
supported by my server-program, without trying the above methods? My
purpose is not to simply make a list for my own reference, but rather
finding it out on-the-fly in the server-side program, since I may run it
on different versions of OpenSSL.
</pre>
</blockquote>
<pre wrap="">You can use the define TLS_MAX_VERSION to determine the highest protocol
version supported by the library.
If you also want to know the lowest version then that's a bit more
tricky. All current released versions will define OPENSSL_NO_SSL3 if
SSLv3 support has been compiled out, and OPENSSL_NO_SSL2 if SSLv2
support has been compiled out (its not currently possible to compile out
other protocol versions). In the forthcoming 1.1.0 release SSLv2 support
has been completely removed so you don't get OPENSSL_NO_SSL2 even though
there is no SSLv2 support available (hmmmm...I wonder if we should add
that?). There are other SSLv2 defines in ssl2.h that are removed in
1.1.0 which you could use to detect whether you are on a version with
ssl2.h completely removed such as SSL2_MT_ERROR, i.e. something like
(completely untested):
#ifdef OPENSSL_NO_SSL3
#define TLS_MIN_VERSION TLS1_VERSION
#elif defined(OPENSSL_NO_SSL2) || !defined(SSL2_MT_ERROR)
#define TLS_MIN_VERSION SSL3_VERSION
#else
#define TLS_MIN_VERSION SSL2_VERSION
#endif
How future proof that is if we ever remove SSLv3 support I'm not sure.
Matt
</pre>
</blockquote>
<tt>Unfortunately that presumes that the client is compiled <br>
against configure headers from the library build.</tt><tt><br>
</tt><tt><br>
</tt><tt>This is absolutely useless if you try to share an OpenSSL <br>
shared library compiled by a 3rd party (such as an OS <br>
distribution or an end user).</tt><br>
<br>
<tt>What lots of people need is an ability to interrogate a <br>
compiled shared library about what is enabled in that copy, <br>
similar to how the SSL_get_ciphers() or similar can be used <br>
to determine if the current copy has been compiled without <br>
IDEA, ECC or other optional cipher suites.<br>
<br>
This is what happens in the real world when end users run your <br>
compiled program on various Linux distributions, such as Red <br>
Hat vs. OpenSUSE vs. Ubuntu...<br>
</tt>
<pre class="moz-signature" cols="72">Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. <a class="moz-txt-link-freetext" href="https://www.wisemo.com">https://www.wisemo.com</a>
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded </pre>
</body>
</html>