Configuration done -
We are trying to configure Filebeat with TLS V1.2
Filebeat sending data to logstash , so logstash output is configured.
For that we configured min and max version to 1.2 along with all the required certificates, root,int. certs and client cert key file. Our CA cert is having 2048 bit encryption
Problem -
We are getting vulnerability in VA as follows -
low] [5044/tcp/unknown] SSL/TLS Diffie-Hellman Modulus <= 1024 Bits (LogJam)
Vulnerable connection combinations : SSL/TLS version : TLSv1.1 Cipher suite : TLS1_CK_DHE_RSA_WITH_AES_128_CBC_SHA Diffie-Hellman MODP size (bits) : 1024 Warning - This is a known static Oakley Group2 modulus. This may make the remote host more vulnerable to the Logjam attack. Logjam attack difficulty : Hard (would require nation-state resources) SSL/TLS version : TLSv1.1 Cipher suite : TLS1_CK_DHE_RSA_WITH_AES_256_CBC_SHA Diffie-Hellman MODP size (bits) : 1024 Warning - This is a known static Oakley Group2 modulus. This may make the remote host more vulnerable to the Logjam attack. Logjam attack difficulty : Hard (would require nation-state resou
Interesting. Can you share you filebeat output configuration? Which tool are you using for the analysis? You have a trace of SSL/TLS handshake we can have a look at?
Which JVM are you running logstash with? Exact filebeat version in use (1.2.3?) ?
The TLS version used is somewhat limited by JVM in use. Logstash with Java 7 VM might only support TLS 1.1, not 1.2.
Unfortunately one can not configure the cipher suites in use with logstash, but beats provides some supports cipher_suites setting.
go already uses elliptic curve Diffie-Hellman (ECDH suites), but no idea about JVM here. The cipher suite mentioned TLS1_CK_DHE_RSA_WITH_AES_128_CBC_SHA is not even defined in go or beats. I guess it's coming from JVM libs.
Thanks for the responce -
Here is the filebeat configuration
logstash:
# The Logstash hosts
hosts: ["irldxvm081.irl.in.ibm.com:5044"]
# Number of workers per Logstash host.
#worker: 1
# Set gzip compression level.
#compression_level: 3
# Optional load balance the events between the Logstash hosts
#loadbalance: true
# Optional index name. The default index name depends on the each beat.
# For Packetbeat, the default is set to packetbeat, for Topbeat
# top topbeat and for Filebeat to filebeat.
#index: filebeat
bulk_max_size: 1024
# Optional TLS. By default is off.
tls:
# List of root certificates for HTTPS server verifications
certificate_authorities: ["/etc/pki/tls/certs/chain.crt"]
# Certificate for TLS client authentication
certificate: "/etc/pki/tls/certnew.pem"
# Client Certificate Key
certificate_key: "/etc/pki/tls/private/irldxvm081.key"
min_version: 1.2
max_version: 1.2
# Controls whether the client verifies server certificates and host name.
# If insecure is set to true, all server host names and certificates will be
# accepted. In this mode TLS based connections are susceptible to
# man-in-the-middle attacks. Use only for testing.
#insecure: true
# Configure cipher suites to be used for TLS connections
cipher_suites: [ECDHE,SHA,SHA256,SHA384]
# Configure curve types for ECDHE based cipher suites
curve_types: [P-256]
[root@irldxvm081 conf.d]# java -version
java version "1.7.0_101"
OpenJDK Runtime Environment (rhel-2.6.6.4.el6_8-x86_64 u101-b00)
OpenJDK 64-Bit Server VM (build 24.95-b01, mixed mode)
[root@irldxvm081 conf.d]# filebeat -version
filebeat version 1.2.3 (amd64)
[root@irldxvm081 conf.d]# openssl s_client -connect irldxvm081.irl.in.ibm.com:5044 -tls1_2
CONNECTED(00000003)
depth=2 C = US, O = International Business Machines Corporation, CN = IBM Internal Root CA
verify error:num=19:self signed certificate in certificate chain
verify return:0
140444073035592:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:598:
---
Certificate chain
0 s:/C=IN/ST=New Delhi/L=New Delhi/O=ibm.com/OU=Research/CN=irldxvm081.irl.in.ibm.com/UID=AVJBYJ744/mail=vinodar3@in.ibm.com
i:/C=US/O=International Business Machines Corporation/CN=IBM INTERNAL INTERMEDIATE CA
1 s:/C=US/O=International Business Machines Corporation/CN=IBM INTERNAL INTERMEDIATE CA
i:/C=US/O=International Business Machines Corporation/CN=IBM Internal Root CA
2 s:/C=US/O=International Business Machines Corporation/CN=IBM Internal Root CA
i:/C=US/O=International Business Machines Corporation/CN=IBM Internal Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
.
-----END CERTIFICATE-----
subject=/C=IN/ST=New Delhi/L=New Delhi/O=ibm.com/OU=Research/CN=irldxvm081.irl.in.ibm.com/UID=AVJBYJ744/mail=vinodar3@in.ibm.com
issuer=/C=US/O=International Business Machines Corporation/CN=IBM INTERNAL INTERMEDIATE CA
---
No client certificate CA names sent
Server Temp Key: ECDH, secp521r1, 521 bits
---
SSL handshake has read 4350 bytes and written 230 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-SHA
Session-ID: 57BAF570551E8F25E87BE0D8383B2D3A7EAC93DCB4A235E36E12FD17AE6E4941
Session-ID-ctx:
Master-Key: 605609BB67E5832B02066A1C248B40C24D1E956EF7C77FF925525234CF4D3502317F4B46FFD544BE4971542CBA58E671
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1471870320
Timeout : 7200 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
Does your filebeat config load as is? The cipher_suites config is pretty much wrong. I wonder if you have some indentation error (you only used spaces, right?). It must be one of the longer names. The openssl client for example uses ECDHE-RSA-AES-256-CBC-SHA.
I find it kinda weird the cipher suite used by openssl client being different from suite reported to be used by beats (the one reported for beats doesn't even exist in beats).
Can you capture a trace (use tcpdump) of SSL handshake? I'd like to have a look at the SSL envelope in wireshark.
Which tool exactly are you using checking for SSL vulnerabilities?
Thanks for the response. It was openjdk 7 jvm issue. I was able to fix using java 8.
In the latest scan report I do not see any vulnerabilities now.
Yes cipher suite configuration is wrong, so I have commented it now.
Am I really supposed to configure cipher suites and curve types or let it take whatever default ones.
If I configure cipher suites according to what you have mentioned , I get following error but filebeat is started -
[root@irldxvm081 opt]# /etc/init.d/filebeat restart
2016/08/23 11:47:10.488034 transport.go:125: ERR SSL client failed to connect with: EOF
Stopping filebeat: [ OK ]
Starting filebeat: 2016/08/23 11:47:10.612413 transport.go:125: ERR SSL client failed to connect with: EOF
[ OK ]
[root@irldxvm081 opt]# /etc/init.d/filebeat status
filebeat-god (pid 28169) is running...
[root@irldxvm081 opt]#
Great it works with java 8. I think java 7 also supports TLSv1.2, but disables it by default.
Unless you've got some specific cipher requirements (use this, but make sure that one can not be used), I don't think cipher_suites and curves must be configured. One might want to configure multiple cipher_suites, as some libs might not support all.
For connections to succeed, 'connection parameters' must be supported by both sides. Most likely you the see EOF in beats, due to java 8 not supporting some parameters configured in beats (I cipher_suite, as set of allowed suites must have at least some suites in common). Due to parameters-check failing early, the connection is closed during handshake by server and we see the EOF. If you're lucky you can find some logs on server side telling you what went wrong. Unfortunately, working with SSL can be very frustrating both as user and as developer, for reasons like this. E.g. libs just closing connections, but never getting any report/logs/code telling you what actually did happen. That is, once you get it working correctly, SSL is great. But until you get it working right, it all feels super fragile
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.
