I am running centos 5.7 with the openssl-0.9.8e-22.el5_11 and it's affected by poodle vulnerability. So to address this I have upgraded my openssl version to openssl-0.9.8e-31.el5_11.
I have confirmed like the fix for poodle vulnerability is available in the above version by using changelog.
[root]# rpm -qa --changelog openssl | grep CVE
- add support for fallback SCSV to partially mitigate CVE-2014-3566
- fix CVE-2014-0221 - recursion in DTLS code leading to DoS
- fix CVE-2014-3505 - doublefree in DTLS packet processing
- fix CVE-2014-3506 - avoid memory exhaustion in DTLS
- fix CVE-2014-3508 - fix OID handling to avoid information leak
But however, still my system is using SSLv3 as per the below test.
[root]# nmap --script ssl-enum-ciphers -p 443 10.197.65.190
Starting Nmap 5.51
Nmap scan report for 10.197.65.190
Host is up (0.00071s latency).
PORT STATE SERVICE
443/tcp open
| ssl-enum-ciphers:
| SSLv3
| Ciphers (
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA
| TLS_RSA_WITH_3DES_EDE_CBC_SHA
| TLS_RSA_WITH_AES_128_CBC_SHA
| TLS_RSA_WITH_AES_256_CBC_SHA
| TLS_RSA_WITH_RC4_128_MD5
| TLS_RSA_WITH_RC4_128_SHA
| Compressors (1)
| uncompressed
| TLSv1.0
| Ciphers (
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA
| TLS_RSA_WITH_3DES_EDE_CBC_SHA
| TLS_RSA_WITH_AES_128_CBC_SHA
| TLS_RSA_WITH_AES_256_CBC_SHA
| TLS_RSA_WITH_RC4_128_MD5
| TLS_RSA_WITH_RC4_128_SHA
| Compressors (1)
|_ uncompressed
Nmap done: 1 IP address (1 host up) scanned in 1.28 seconds
I am getting little bit confused here.Whether really poodle vulnerability is fixed in openssl-0.9.8e-31.el5_11.
Any help on this will be highly appreciatable.
No upgrade for openssl will fix POODLE, because POODLE is a design flaw in SSL 3.0 and not a bug in OpenSSL. All the upgrade does is to add an option which might be used be servers to detect protocol downgrade attempts of the client.
The real fix is to disable SSL 3.0 in all applications which use the OpenSSL library.
Related
We are running our java application on RHEL 8.5 OS platform. We are using the Apache 2.4.35 version. And we made the changes in ssl.conf file like below,
SSLProtocol -ALL +TLSv1.2
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:AES256-CCM:DHE-RSA-AES256-CCM
We used some commands to verify whether we are using TLS1.0 and TLs1.1 protocols or not. As expected, we got positive results that both protocols are disabled. Please find the below commands which we used to verify,
1. openssl s_client -connect <IP_ADDRESS>:8443 -tls1
2. nmap -sV --script ssl-enum-ciphers -p 8443 <IP_ADDRESS>
Starting Nmap 7.70 ( https://nmap.org ) at 2022-09-20 20:02 IST
mass_dns: warning: Unable to open /etc/resolv.conf. Try using --system-dns or specify valid servers with --dns-servers
mass_dns: warning: Unable to determine any DNS servers. Reverse DNS is disabled. Try using --system-dns or specify valid servers with --dns-servers
Nmap scan report for XXXXX (IP_ADDRESS)
Host is up (0.00067s latency).
PORT STATE SERVICE VERSION
8443/tcp open ssl/http Apache httpd
|_http-server-header: Apache
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| compressors:
| NULL
| cipher preference: client
|_ least strength: A
MAC Address: 00:50:56:A7:92:7B (VMware)
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 12.90 seconds
But during the vulnerability scan (Nessus scan), we got that a port (4567) is using TLS1.0 version.
Please let me know how to block the TLS1.0 on that specific port?
while evaluating the network security using nmap on Kubernetes server, we noticed a warning as below
~]# nmap xxx.xx.xx.xx -p 6443 -sVC --script=ssl*
.
.
.
ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| compressors:
| NULL
| cipher preference: server
| warnings:
| 64-bit block cipher 3DES vulnerable to SWEET32 attack
With bit of research got to know that TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C cipher suite is to support 64bit block SSL/TLS Handshake and the suggested solution is to disable the cipher option in Kubernetes etcd. please help me how to do it.
other views on this much appreciated, please let me know what is the better way to secure the environment.
You can use the --cipher-suites CLI option to etcd. See https://etcd.io/docs/v3.4/op-guide/security/ for a summary of all their TLS config options. The default ciphers is based on the version of Go used to compile it.
I'm trying to consume an internal HTTPS service with node inside a container and getting the following error:
# node src/fetch.js
Error: write EPROTO 140284687652672:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../deps/openssl/openssl/ssl/record/ssl3_record.c:332:
at WriteWrap.onWriteComplete [as oncomplete] (internal/stream_base_commons.js:87:16) {
errno: 'EPROTO',
code: 'EPROTO',
syscall: 'write'
}
But if I run the exact same code outside the container (on my machine) it just runs fine.
I'd been googling for a solution but I just keep finding that I'm trying to consume and HTTP service using HTTPS.
Aditionally, this is the result if I run the same URL using cURL inside the container:
# curl https://my-internal-secure-service.com/apitra/v1/health --verbose
* Trying 10.56.13.17...
* TCP_NODELAY set
* Connected to my-internal-secure-service.com (10.56.13.17) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:#STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
* Curl_http_done: called premature == 1
* stopped the pause stream!
* Closing connection 0
curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
Talking with the people who created this service told me that the service is only using TLS 1.2 but I have no idea how to specify that kind of parameter with node.
I found the secureProtocol (https://nodejs.org/api/tls.html#tls_tls_createsecurecontext_options) option for TLS and after trying it with the value TLSv1_2_method the same thing happened.
Anyone have a clue to what is happening here?
Here are some versions:
Docker version: 19.03.5, build 633a0ea
Docker compose: 1.25.4, build 8d51620a
Docker image: node:12.14.1
node version: 12.14.1.
Machine OS: macOS Catalina 10.15.3
And some results of nmap:
Inside the container:
# nmap --script ssl-enum-ciphers -p 443 my-internal-secure-service.com
Starting Nmap 7.40 ( https://nmap.org ) at 2020-03-04 14:06 MST
Nmap scan report for my-internal-secure-service.com (10.56.13.17)
Host is up (0.00081s latency).
rDNS record for 10.56.13.17: mockservice.my-company.io
PORT STATE SERVICE
443/tcp open https
Nmap done: 1 IP address (1 host up) scanned in 88.22 seconds
And in my machine:
# nmap --script ssl-enum-ciphers -p 443 my-internal-secure-service.com
Starting Nmap 7.80 ( https://nmap.org ) at 2020-03-04 14:07 MST
Nmap scan report for my-internal-secure-service.com (10.56.13.17)
Host is up (0.097s latency).
PORT STATE SERVICE
443/tcp open https
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| compressors:
| NULL
| cipher preference: server
|_ least strength: A
Nmap done: 1 IP address (1 host up) scanned in 3.07 seconds
P.S. I don't know if this is important but my machine (MacBook Pro) is connected to a Mac Mini WiFi hotspot, the Mac Mini is connected via ethernet to the corporate network.
I've looked at several similar questions here, but none of them have helped me. I want to connect to a web service that uses single-sign-on via an RSA SecurID keyfob. I start by trying to load any cookies provided by the initial GET request. Here's my command:
curl -A "Mozilla/5.0" -L -b cookies.txt -c cookies.txt -v -X GET \
https://sso.example.com/sso/login.htm
I get this in response:
* About to connect() to sso.example.com port 443 (#0)
* Trying 23.12.245.199... connected
* Connected to sso.example.com (23.12.245.199) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs/
* SSLv3, TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to sso.example.com:443
* Closing connection #0
curl: (35) Unknown SSL protocol error in connection to sso.example.com:443
Here's what I'm using:
# curl --version
curl 7.19.7 (x86_64-suse-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8j zlib/1.2.7 libidn/1.10
Protocols: tftp ftp telnet dict ldap http file https ftps
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
# more /etc/*-release
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 3
# uname -r
3.0.101-0.21-default
Any ideas?
This is OpenSSL in your client that has a problem to understand what the server is saying and it errors out because of that.
You can sometimes work around these kinds of issues by forcing curl to speak SSLv3 (-3), TLS1.0 (-1) or even SSLv2 (-2)
... it is also conceivable that your severely outdated versions of curl and OpenSSL simply have a bug or two that cause this and that you can fix this problem by upgrading to modern versions (and then also fix the numerous security problems your versions contain).
I installed stunnel4 from the program manager. When I try to run stunnel on either of Ubuntu 14 or Linux Mint 17, I get the message below. I have this working on CentOS6.5 and on MacOS X Mavericks. Not sure what to try next. Rebuilding openssl is a mess, if that is even the problem.
idf#idf-ZBOX-ID42-BE ~ $ sudo stunnel
Clients allowed=500
stunnel 4.53 on x86_64-pc-linux-gnu platform
Compiled with OpenSSL 1.0.1e 11 Feb 2013
Running with OpenSSL 1.0.1f 6 Jan 2014
Update OpenSSL shared libraries or rebuild stunnel
Threading:PTHREAD SSL:+ENGINE+OCSP Auth:LIBWRAP Sockets:POLL+IPv6
Reading configuration from descriptor 3
Compression not enabled
PRNG seeded successfully
Initializing inetd mode configuration
Section stunnel: SSL server needs a certificate
str_stats: 2 block(s), 10 data byte(s), 116 control byte(s)
idf#idf-ZBOX-ID42-BE ~ $
my conf file looks like this:
idf#idf-ZBOX-ID42-BE ~ $ more /etc/stunnel/stunnel.conf
;Example stunnel configuration file by Michal Trojnara 2002-2006
; Some options used here may not be adequate for your particular configuration
; Certificate/key is needed in server mode and optional in client mode
; The default certificate is provided only for testing and should not
; be used in a production environment
;cert = stunnel.pem
;key = stunnel.pem
cert = /home/idf/Downloads/cert.pem
key = /home/idf/Downloads/key.pem
fips = no
libwrap=no
;
;Protocol version (all, SSLv2, SSLv3, TLSv1)
;sslVersion = all
sslVersion = all
ciphers = ALL
;
; Some security enhancements for UNIX systems - comment them out on Win32
chroot = /var/run/stunnel4/
setuid = stunnel4
setgid = stunnel4
; PID is created inside the chroot jail
pid = /home/idf/stunnel.pid
; Some performance tunings
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
compression = zlib
; Workaround for Eudora bug
options = DONT_INSERT_EMPTY_FRAGMENTS
; Authentication stuff
;verify = 2
; Don't forget to c_rehash CApath
;CApath = certs
; It's often easier to use CAfile
;CAfile = cacerts.pem
; Don't forget to c_rehash CRLpath
;CRLpath = crls
; Alternatively you can use CRLfile
;CRLfile = crls.pem
; Some debugging stuff useful for troubleshooting
debug = 7
output = /var/log/stunnel/stunnel.log
; Use it for client mode
client = yes
; Service-level configuration
[xxxxxxx-xxx-xxxxx]
client = yes
accept = 127.0.0.1:9099
connect= xx.xx.xx.xx:2506
; vim:ft=dosini
idf#idf-ZBOX-ID42-BE ~ $
If I uninstall the stunnel that is in the repository and replace it with this one:
https://launchpad.net/ubuntu/utopic/amd64/stunnel4/3:5.01-3
I still get even if I disable compression. I don't understand why it is telling me about the "Service [stunnel]: SSL server needs a certificate" since I am trying to use it only in client mode. Also, the other end does not need a certificate.
idf#idf-ZBOX-ID42-BE ~/Downloads $ sudo stunnel
[ ] Clients allowed=500
[.] stunnel 5.01 on x86_64-pc-linux-gnu platform
[.] Compiled/running with OpenSSL 1.0.1f 6 Jan 2014
[.] Threading:PTHREAD Sockets:POLL,IPv6 SSL:ENGINE,OCSP,FIPS Auth:LIBWRAP
[ ] errno: (*__errno_location ())
[.] Reading configuration from descriptor 3
[.] FIPS mode disabled
[ ] Compression disabled
[ ] PRNG seeded successfully
[ ] Initializing inetd mode configuration
[!] Service [stunnel]: SSL server needs a certificate
idf#idf-ZBOX-ID42-BE ~/Downloads $ ps ax | grep stunnel
i just beat my way thru this the other day.
you want stunnel4_5.01-3_amd64.deb - you'll have to download that - not in the repos yet. i believe someone made it work with 4.53, but i didn't manage it.
https://launchpad.net/ubuntu/utopic/amd64/stunnel4/3:5.01-3
openssl 1.0.1f and libssl.1.0.0 and libssl.1.0.0:i386 1.0.1f (they're the current versions) are good. but note this from your start output:
Compiled with OpenSSL 1.0.1e 11 Feb 2013
Running with OpenSSL 1.0.1f 6 Jan 2014
i think updating stunnel as described above will sort that for you.
and the other thing you need to do is turn off compression in your stunnel.conf - none of the different types of compression i tried currently work. hopefully, that's temporary.
regards,
hth
(I'm the same guys as above user3694589 - finally bothered to create an account.)
FYI, I just subscribed myself to this related bug and marked it as affecting me on launchpad.net:
https://bugs.launchpad.net/ubuntu/+source/stunnel4/+bug/1315844
You might want to add yourself as well. Several minutes later, I got this email:
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: stunnel4 (Ubuntu)
Status: New => Confirmed
-- You received this bug notification because you are subscribed to the bug report. https://bugs.launchpad.net/bugs/1315844 Title: won't start with compression on