We have a Java application running on a Linux server and we are transmitting some files using a third party Java library which uses HTTPS internally to connect to external servers. These are legacy libraries and we have only .jar files.

How can I identify which SSL/TLS version is being used by this library? Is there a way to monitor the TCP traffic on my Linux machine to track SSL headers?

3 Answers 3


One of the way that I use to capture the network traffic from the java application using Wireshark. Refer the documentation to capture the traffic. Once the traffic is captured. Click Analyze -> Decode As -> Transport,select the port and the select SSL, apply and the save the settings. The captured traffic will be shown as SSL. Look for the response of the "client hello" message in the captured traffic. This is where SSL/TLS handshake is done.

Refer the below image:

enter image description here

  • 1
    Note Wireshark only runs on Windows and Mac, so you need one of those in a position to see your app's network traffic, such as the same wired hub or wireless AP. Or you can capture to a file with Linux tcpdump -w then use Wireshark's nice GUI to analyze the capture file. Commented Jun 23, 2015 at 9:17
  • 3
    Wireshark runs not only on Windows and Mac, but also on Linux, FreeBSD, NetBSD, PC-BSD, HP-UX and Solaris, as listed on the download page. Of course, running a GUI on a Linux server might be cumbersome, in which case tcpdump is very useful.
    – legoscia
    Commented Sep 7, 2016 at 9:43

please note: all tests from a remote client will always depend on the libs on that client, so if you have an old openssl-version on a client and want to test a new openssl-version on a server, you'll get results that are valid for the client only.


easiest way would be to test via openssl s_client:

$ openssl s_client -host HOST -port PORT

-- output

... .oO( a lot of debug-outout )Oo. ... 

New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
  Protocol  : TLSv1.2
  Cipher    : ECDHE-RSA-AES128-GCM-SHA256

via script

there's a script called testssl.sh which might give some insight into a ssl-setup (you might need to hack it a little bit; i had to use /bin/bash instead of /bin/sh to get it working)


-- output 

testssl.sh v2.0pre  (http://software.drwetter.eu/ssl/)

Testing now (2014-02-24 22:40) ---> blah.org:443 <---
("blah.org" resolves to "") 

--> Testing specific vulnerabilities
Renegotiation Vulnerability (CVE 2009-3555): **NOT vulnerable (ok)** 
CRIME Vulnerability (CVE-2012-4929): **NOT vulnerable (ok)  

--> Testing HTTP Header settings 
HSTS: **365 days (31536000 s)
Server banner: nginux

--> Testing (Perfect) Forward Secrecy  (P)FS) 
PFS seems generally available. Now testing specific ciphers

ECDHE-RSA-AES256-GCM-SHA384 [0xc030]: **works** 
ECDHE-RSA-AES128-GCM-SHA256 [0xc02f]: **works** 
ECDHE-RSA-AES128-SHA256 [0xc027]: **works** 
ECDHE-RSA-RC4-SHA [0xc011]: **works** 
DHE-RSA-AES256-GCM-SHA384 [0x9f]: **works** 
DHE-RSA-AES256-SHA256 [0x6b]: **works** 
DHE-RSA-AES256-SHA [0x39]: **works** 
DHE-RSA-CAMELLIA256-SHA [0x88]: **works** 
DHE-RSA-AES128-GCM-SHA256 [0x9e]: **works** 
DHE-RSA-AES128-SHA256 [0x67]: **works** 
DHE-RSA-AES128-SHA [0x33]: **works** 
DHE-RSA-CAMELLIA128-SHA [0x45]: **works** 
ECDHE-RSA-AES256-SHA384 [0xc028]: **works** 
ECDHE-RSA-AES256-SHA [0xc014]: **works** 
ECDHE-RSA-AES128-SHA [0xc013]: **works** 
(A **"green" cipher doesn't mean any browser will be able to use it)

--> Checking RC4 Ciphers
ECDHE-RSA-RC4-SHA [0xc011] (Kx=ECDH, Mac=SHA1): **available ** 
RC4-SHA [0x05] (Kx=RSA, Mac=SHA1): **available ** 
  RC4 is kind of broken (for e.g. IE6 consider 0xa or 0x13)

--> Testing Protocols
SSLv2: **Local problem: /usr/bin/openssl doesn't support "s_client -ssl2"** 
SSLv3: **NOT offered (ok)** 
TLSv1: **offered (ok)** 
TLSv1.1: **offered (ok)** 
TLSv1.2: **offered (ok)** 

SPDY: Following protocols advertised:** spdy/2, http/1.1** 

--> Testing cipher suites
Null Cipher: **NOT offered (ok)** 
Anonymous NULL Cipher : **NOT offered (ok)** 
40 Bit encryption: **NOT offered (ok)** 
56 Bit encryption: **Local problem: No 56 Bit encryption configured in /usr/bin/openssl** 
Export Cipher (general): **NOT offered (ok)** 
Low (<=64 Bit): **NOT offered (ok)** 
Medium grade encryption: offered
High grade encryption: **offered (ok)** 


import socket
import ssl

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
ssl_sock = ssl.wrap_socket(s,cert_reqs=ssl.CERT_REQUIRED,ca_certs='/etc/ssl/certs/ca-certificates.crt')
ssl_sock.connect((target, port))

-- output
> ssl-info
('', 443)
('ECDHE-RSA-AES128-GCM-SHA256', 'TLSv1', 128)
  • Those are good ways to test what the server can do, but they do not tell you what a particular opaque Java client does do, which is the question. Although if the other answer (look at the net traffic) shows an old protocol or poor cipher is being used, this can help you decide whether to blame the server (can't do it right) or the client app (didn't request it right). Commented Jun 23, 2015 at 9:18
  • if using Python 2.7.9+ you can use ssl_sock.version() to ascertain whether 'TLSv1' actually refers to 'TLSv1.2' (for example, which it can)
    – DrMeers
    Commented Mar 16, 2016 at 0:19

As an alternative you can check the possible ciphers with nmap:

$ nmap -Pn -p 443 --script=ssl-enum-ciphers <hostname or ip>

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .