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.
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?
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 want to check OpenSSL 1.1.0g against an application ciphersuite lists. The application I have has ciphersuites as follows:
ecdhe-ecdsa-chacha20-poly1305-sha256
ecdhe-rsa-chacha20-poly1305-sha256
By checking Openssl TLS 1.2 ciphers using the command: openssl ciphers -s -tls1_2 -V I got some ChaCha ciphersuites as follows:
0xCC,0xA9 - ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
0xCC,0xA8 - ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
The only difference is that OpenSSL ciphersuite name does not contain the SHA type. There are many SHA types (256, 384, etc.). How can I know what is the SHA type in OpenSSL ciphersuites?
openssl ciphers shows you the codes for this ciphers, i.e. 0xCC,0xA9 and 0xCC,0xA8. According to IANA these codes map to TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 and TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 which are both defined in RFC 7905.
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.
I am failing a server security scan on Windows 2008 R2, with
TLS Protocol Session Renegotiation Security Vulnerability TLS SSL Man In The Middle CVE-2009-3555
The scan results recommend an upgrade to openssl 0.9.8l or higher.
I am using the latest version of tcnative-1.dll (1.1.29 13/02/14) which, as I understand it is built using the native libraries and openssl libraries.
Is the only way I can resolve this is to build tcnative myself with the latest version of openssl?
Looking at the http://tomcat.apache.org/native-doc/ build section I need MS Visual Studio (which I don't have and have never used).
Has anybody else build it? If so I cannot find it.
This result is a false positive. I've performed various tests with various versions of Tomcat using the 1.1.29 APR/native connector and in none of those test did insecure renegotiation occur.
Note that Tomcat - depending on version, connector and configuration may support secure renegotiation.
The most definitive test was with OpenSSL 0.9.8.k (i.e. a version of OpenSSL that is vulnerable to CVE2009-3555 and will attempt an insecure renegotiation). When I try this, the connection blocks and eventually times out.
You need to find a better security scanner.
For completeness, the output of the test was:
$ ./openssl s_client -connect 192.168.23.9:8443
CONNECTED(00000003)
depth=1 /C=US/CN=ca-test.tomcat.apache.org
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
0 s:/C=US/CN=localhost
i:/C=US/CN=ca-test.tomcat.apache.org
1 s:/C=US/CN=ca-test.tomcat.apache.org
i:/C=US/CN=ca-test.tomcat.apache.org
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDSTCCAjGgAwIBAgICEAMwDQYJKoZIhvcNAQEFBQAwMTELMAkGA1UEBhMCVVMx
IjAgBgNVBAMTGWNhLXRlc3QudG9tY2F0LmFwYWNoZS5vcmcwHhcNMTMwMjI4MDUy
ODQyWhcNMTUwMjI4MDUyODQyWjAhMQswCQYDVQQGEwJVUzESMBAGA1UEAxMJbG9j
YWxob3N0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5295PxiHkd0n
mDQkeVhH+cJpK9hbwOC7SlfWALW7arBmhFy48BIKJycynIIqLw9pd6bpDd9kMVHA
QR7c1HRRnKO4URNYc+4hnPljghvCLEnDCXD/qfOvogwLYC9q26UBRT40kI5naetF
8zQphds5ipnCD3IVIf1UNaZ7pzDLHk09MiTGS4RPX2D/ZF5oytj63ph9QARgt65Q
7MiMrt2UgUEYWwNjDysCYwqVau1+aOa21VbpTmDqHZVYM76iElXLf5zElwvbwJQJ
KrOf4Wt4DWMaQdVr29hIWQSI0RHV50UoDnwbeHUgff9/4dbq5MVRd0FCMEv/KTM9
iViUaVtwJwIDAQABo3sweTAJBgNVHRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVu
U1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUMNurcJQ0yv11RqvO
4kqpnnS8abswHwYDVR0jBBgwFoAUsDu8yfooXz4EH5tsx4to2AGw+D0wDQYJKoZI
hvcNAQEFBQADggEBAKvT5ys1022fhypkWPFhy1aohCJ5rA1oH1UN3RYWcsSpdSoO
+LFzaMnuQ9hc+gddP0H7FBe+ZCHYHiVnkrLFu0MdlrbTvRzhpMfu4zcLkhRWyq2o
dluAyUKMifFCboz7odeY1W1Jmf629sbzzI8GVG4C9Y9L8YasFJNsdCUmRHpbgjxX
1uUUbrcpU+RAei8QXf8of+XlVGw4+rknlyppYLpKWihlsYHgt6F01uYHgW24WcNF
vXyoF2cf/FIabJCHTaGYUYwpaoTZDSSohmpearf5J5tSN5a1/ZQRysTZbWmB+pY0
Yzp8SS0GSK6xFFkSKY5ZPQOZQpDmgt8Iz9d37AA=
-----END CERTIFICATE-----
subject=/C=US/CN=localhost
issuer=/C=US/CN=ca-test.tomcat.apache.org
---
No client certificate CA names sent
---
SSL handshake has read 2433 bytes and written 322 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: E98ED9D885D761C7B23AF93DC15C53D0680AF2D8345A37699549E48C9D4E18AE
Session-ID-ctx:
Master-Key: FA2C87FB24C68186D1CC63FEEF459B7DE4BA0F304D60F2293AB3C1C23DF03566F51DDB61A9576A1FE9C021CB3438B4C7
Key-Arg : None
Start Time: 1395309769
Timeout : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
---
GET / HTTP/1.0
R
RENEGOTIATING
7087:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:530: