12

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?

11

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. – dave_thompson_085 Jun 23 '15 at 9:17
  • 1
    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 Sep 7 '16 at 9:43
8

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.

openssl

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
SSL-Session:
  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)

http://testssl.sh

-- output 


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

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


--> 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)** 

python

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))
print repr(ssl_sock.getpeername())
print ssl_sock.cipher()

-- output
> ssl-info
('12.34.56.78', 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). – dave_thompson_085 Jun 23 '15 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 Mar 16 '16 at 0:19
2

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

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.