• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 3232
  • Last Modified:

gnutls-cli or any other Linux tool to verify TLS version


refer to the above.

Where can I download the above for RHES 5.x & 6.x?
(not source code but ready to use tool)

Is there any other tool like the above that's not in
rpm package form which doesn't need to be installed
& can just run standalone (just like putty in Windows).
I prefer not to install anything but would like to
verify our TLS version after updating/patching it.
'rpm -qa ...gnu-package...' only shows the updated
/patched package but what's needed is like the
above tool to verify if Apache has effectively used
the new/patched TLS

Besides Apache, what other common apps in RHES
/RHEL uses gnutls ?
  • 6
  • 6
  • 4
  • +1
12 Solutions
Q1 & Q2 For Redhat it's
yum install gnutls-utils
sunhuxAuthor Commented:
Must we install the package gnutls-utils or just download
the gnutls-cli binary & it will run?

Any other tool with similar function that doesn't require
installation (just like putty)?  Even a Windows freeware
is fine
If you find the gnutls-cli binary, it should run if you download the correct version for your system.  If it's compiled against libraries and your version differs, then you may have to also download the libraries to match.
Build your data science skills into a career

Are you ready to take your data science career to the next step, or break into data science? With Springboard’s Data Science Career Track, you’ll master data science topics, have personalized career guidance, weekly calls with a data science expert, and a job guarantee.

A1: yum provides */gnutls-cli
A2: openssl help s_client
A3: apache does not use gnutls. default apache uses openssl, and redhat allows to replace that with NSS library. Actually no serious apps use gnutls, 99% use openssl, just firefox/thunderbird use nss
sunhuxAuthor Commented:
Could point me to URLs/links that have gnutls-cli binary
for RHES 5.8, 5.9, 6.1 ?
sunhuxAuthor Commented:
I mean standalone binary that doesn't need installation:
gnutls-cli (for Linux) or gnutls-cli.exe (for Windows)
you won't easily find such a binary, but you can build one yourself by statically compiling the gnutls binary for each of these systems. you might even be lucky enough to produce a single binary that will work on all of them.

you can also extract the gnutls-cli binary from the rpm of each corresponding system, but this will only work if the dependencies happen to be already installed

check by running ldd (example on a working system)
$ ldd /usr/bin/gnutls-cli
	linux-vdso.so.1 =>  (0x00007fff333fe000)
	libgnutls.so.26 => /usr/lib/x86_64-linux-gnu/libgnutls.so.26 (0x00007fc1e79c2000)
	libgnutls-extra.so.26 => /usr/lib/x86_64-linux-gnu/libgnutls-extra.so.26 (0x00007fc1e77b9000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc1e73f0000)
	libgcrypt.so.11 => /lib/x86_64-linux-gnu/libgcrypt.so.11 (0x00007fc1e7172000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fc1e6f59000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fc1e6d3b000)
	libtasn1.so.3 => /usr/lib/x86_64-linux-gnu/libtasn1.so.3 (0x00007fc1e6b2a000)
	libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007fc1e690a000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fc1e7ca3000)
	libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007fc1e6704000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc1e6500000)

Open in new window

if a library is missing because something that would have been added as a dependency is not present, ldd will show an explicit error message


but then why the hell don't you actually install that rpm ?

if it's just about deployment, you can always use a shell script that performs the install before running the command, but you'll need root privileges

if which gnutls-cli > /dev/null || sudo yum install gnutls-utils
then gnutls-cli "$@"
else ! echo "cannot install gnutls binary, exiting"

Open in new window


you can test from remote machines if what you want to test is the server


you can use openssl which should be installed if you have apache with ssl

$ openssl s_client -connect gmail.com:443
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify error:num=20:unable to get local issuer certificate
verify return:0
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mail.google.com
   i:/C=US/O=Google Inc/CN=Google Internet Authority G2
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
Server certificate
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mail.google.com
issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2
No client certificate CA names sent
SSL handshake has read 3768 bytes and written 375 bytes
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
    Protocol  : TLSv1.1
    Cipher    : ECDHE-RSA-AES128-SHA
    Session-ID: 5C219A93C6F1ECEB67357E90A3F8AE60814603F574B7937601230B8566D47DD7
    Master-Key: 3CE6C0B8510C0FD8FD7D1E7ACF06330259AD49EAAAE715D88531225FEC75A2B1D5859B739A998A5140086D8D87F5DE03
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 100800 (seconds)
    TLS session ticket:
    0000 - 05 ad 1e de 0c 4c ea 3c-65 f5 f6 c2 bd 82 da a8   .....L.<e.......
    0010 - 8f fe bc 80 f1 4b 16 44-cf 98 87 9d a6 77 49 52   .....K.D.....wIR
    0020 - ed 45 57 c4 cc 75 0a 80-c4 8a c0 73 b4 a8 8d cd   .EW..u.....s....
    0030 - cf fe bc 8e 38 c8 86 76-05 ef 01 c7 07 bc 3e 76   ....8..v......>v
    0040 - 29 14 7e dc de ea 8e 52-2e f3 bd 56 3e 2c 20 21   ).~....R...V>, !
    0050 - 1c 99 33 c0 1a 84 6a 94-af 02 ae c6 c8 93 81 5a   ..3...j........Z
    0060 - c2 94 de ea 4e fc 1f e8-ec be 0a 87 a6 b6 ef 65   ....N..........e
    0070 - bb 2b 82 43 e2 ee 8a 56-89 a5 c1 46 b5 a4 a3 25   .+.C...V...F...%
    0080 - de 62 c7 cf 1d ef 6b 54-77 fd 33 ef a1 f8 26 de   .b....kTw.3...&.
    0090 - 2b a8 49 2f ac c3 ae 76-c3 23 05 1e 23 f4 c4 4c   +.I/...v.#..#..L
    00a0 - 27 68 d8 26                                       'h.&

    Start Time: 1396790597
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)

your version might support the -trace option for more verbosity. mine does not
sunhuxAuthor Commented:
>why the hell don't you actually install that rpm ?
To install an rpm is a change & will require an approved CR.
Just running the binary that's copied to the server is not a

I just googled & found that cygwin has this tool built into it
but I'll need to install cygwin on a laptop (or non-critical
openssl executable is present in default install
like we both said, you already have openssl

you can test from remote machines
be it a windows + cygwin, a virtual machine or whatever machine you can actually install a package on
come on you can install oracle linux or centos in vrtualbox or vmware or virtual pc, and extract 1:1 gnutls-cli from their RPMs.
I'd say it is better to ask admin to extract the binary you need in your directory (or at least they will handle your request for new software)
sunhuxAuthor Commented:
Ok, thanks got your point now.

Just to sidetrack, how do I detect if I have a vulnerable OpenSSL
for the bugnote below.  What's the openssl command that I can
execute to detect/verify this?

Google Security's Neel Mehta and 3 researchers from security vendor Codenomicon,
explains that the Heartbleed vulnerability could expose some of the most sensitive
data transmitted over the Internet, including the secret keys used for X.509 certificates,
usernames and passwords, emails and instant messages, and any other
communications supposedly protected by an OpenSSL implementation.

"This bug has left [a] large amount of private keys and other secrets exposed to the Internet. Considering the long exposure, ease of exploitation, and attacks leaving no trace, this exposure should be taken seriously."
There should be a patch released recently to fix openssl.

The fixed version is OpenSSL 1.0.1g. If you're stuck with a previous version of OpenSSL for some reason, you can block the vulnerability by re-compiling it using the OPENSSL_NO_HEARTBEATS flag. OpenSSL 1.0.2 will have the bug fixed in the upcoming 1.0.2-beta2 release. ®
From: http://www.theregister.co.uk/2014/04/08/running_openssl_patch_now_to_fix_critical_bug/

I believe you can detect it with
egrep dtls1_process_heartbeat libssl.so.1.0.0

Open in new window

You can read more about it here: http://heartbleed.com/
It is fixed week ago
Ask your admin to apply redhat security patch due yesterday.
also not that (as far as redhat is concerned it only affects a few versions

This issue does affect Red Hat Enterprise Linux 6.5, Red Hat Enterprise Virtualization Hypervisor 6.5, and Red Hat Storage 2.1, which provided openssl 1.0.1e.

... and obviously some update freaks


the issue can also be corrected on impacted versions (1.0.1a-1.0.1f) by recompiling with the following option



actual on-the-fly https session hijacking is pretty much impossible. session SNIFFING (and password stealing) is on the hand quite possible assuming the attacker manages to retrieve the private key

given the above, if you feel you are concerned with this bug, it is quite foolish to update without changing the certificates as well


back to the topic, you can download the heartbeat.py script here which will attempt to actually perform the attack


run it on any machine that has python and the required (standard) libraries  (incuding a windows host), and get the information. (not tested on my side)
sunhuxAuthor Commented:
Gee, thanks a lot guys.

We have Solaris x86 that run OpenSSL 0.97.x : is this affected?
The official vulnerability site did not indicate if this is affected.
no, it does not implement any TLS version
SSLv3 has its own dragons
Only version 1.0.1a through 1.0.1f are affected.  Older versions are not affected.
Such an old openssl is no more fixed at openssl.org, so you need vendor staement on each and every vulnerability...
here is the list

most of these are less dangerous than the one you noticed at first (which is one very good example of why updating like crazy is not that good an idea)

they will allow an attacker with physical access to either link side or the capacity to run an arp MIM attack on internet routers along the way (wow that IS a long shot) to (maybe) crash the server and IF they get very lucky, IF you are using a lame webserver, and IF they can run a MIM attack undetected for a Looong time to read a few individual already established sessions

... even most banks don't bother that much... did you make an enemy country angry at you ? or run spy activity in yours ? if you run a web site with challenge-response authentication and sessions that do not exceed the time it takes to load a dozen pages, openssl 0.97 is more than enough, and there is no actual guarantee that the latest version is more secure
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

We Need Your Input!

WatchGuard is currently running a beta program for our new macOS Host Sensor for our Threat Detection and Response service. We're looking for more macOS users to help provide insight and feedback to help us make the product even better. Please sign up for our beta program today!

  • 6
  • 6
  • 4
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now