I have configured the below cipher list in Apache's ssl.conf file. And my application is running on RHEL 8.5 OS with OpenSSL version 1.1.1k.
SSLCipherSuite ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES256-CCM:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305
I'm running the below Nmap command to test the strength of the cipher suites which I used in my application,
nmap -sV --script ssl-enum-ciphers -p 8443 <IP_ADDRESS>
Please find the below output snippet.
TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| compressors:
| NULL
| cipher preference: client
|_ least strength: A
And I knew that the certificates which I used in the application are signed with RSA. so it displays the ciphers which are having RSA authentication.
Also, When I try to execute the below command, I got "error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:ssl/record/rec_layer_s3.c:1544:SSL alert number 40" error.
openssl s_client -connect XX.XX.XX.XX:8443 -cipher ECDHE-RSA-CHACHA20-POLY1305
My queries,
Why "ECDHE-RSA-CHACHA20-POLY1305 and DHE-RSA-AES256-CCM" are not displayed by Nmap command even though they have RSA authentication?
Why the handshake failure happened with that cipher?
Thanks.
Related
I have configured 4 ciphers in server.xml file as following but ONLY 2 RSA are working and ECDHE_ECDSA does not work. I have scan tomcat with multiple tools only RSA are showing in all.
How can I make TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, and TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 work ?
<Connector port="${tomcat.secure.port}" protocol="org.apache.coyote.http11.Http11NioProtocol"
address="${tomcat.address}" maxThreads="150" SSLEnabled="true"
scheme="https" secure="true" maxSwallowSize="-1" maxPostSize="-1">
<UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" readTimeout="50000" streamReadTimeout ="-1" streamWriteTimeout="-1"
overheadContinuationThreshold="0" overheadDataThreshold="0" overheadWindowUpdateThreshold="0"/>
<SSLHostConfig protocols="TLSv1.2+TLSv1.3"
ciphers="TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256">
<Certificate certificateKeystoreFile="/tmp/tomcat_keystore.jks"
certificateKeystorePassword="${keystore.password}"
certificateKeyPassword="${key.password}"
certificateKeystoreType="PKCS12"
certificateKeystoreProvider="SUN"/>
</SSLHostConfig>
</Connector>
APACHE TOMCAT/9.0.53
java --version
openjdk 11.0.11 2021-04-20
OpenJDK Runtime Environment (build 11.0.11+9-Ubuntu-0ubuntu2.14.04)
OpenJDK 64-Bit Server VM (build 11.0.11+9-Ubuntu-0ubuntu2.14.04, mixed mode, sharing)
Scan Result:
nmap --script ssl-enum-ciphers -p 443 10.40.43.26
Starting Nmap 7.92 ( https://nmap.org ) at 2022-01-28 18:08 PST
Nmap scan report for vd (10.40.43.26)
Host is up (0.021s latency).
PORT STATE SERVICE
443/tcp open https
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| compressors:
| NULL
| cipher preference: client
|_ least strength: A
sslscan 10.40.43.26:443
Version: 2.0.11-static
OpenSSL 1.1.1m 14 Dec 2021
Connected to 10.40.43.26
Testing SSL server 10.40.43.26 on port 443 using SNI name 10.40.43.26
SSL/TLS Protocols:
SSLv2 disabled
SSLv3 disabled
TLSv1.0 disabled
TLSv1.1 disabled
TLSv1.2 enabled
TLSv1.3 disabled
TLS Fallback SCSV:
Server supports TLS Fallback SCSV
TLS renegotiation:
Session renegotiation not supported
TLS Compression:
OpenSSL version does not support compression
Rebuild with zlib1g-dev package for zlib support
Heartbleed:
TLSv1.2 not vulnerable to heartbleed
Supported Server Cipher(s):
Preferred TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384 Curve 25519 DHE 253
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-GCM-SHA256 Curve 25519 DHE 253
SSL Certificate:
Signature Algorithm: sha256WithRSAEncryption
RSA Key Strength: 2048
Update:
You must set up multiple types of certificates for tomcat and all four ciphers worked.
<SSLHostConfig protocols="TLSv1.2+TLSv1.3"
ciphers="TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256">
<Certificate certificateKeystoreFile="/tmp/RSA/tomcat_keystore.jks"
certificateKeystorePassword="${keystore.password}"
certificateKeyPassword="${key.password}"
certificateKeystoreType="PKCS12"
certificateKeystoreProvider="SUN" type="RSA"/>
<Certificate certificateKeystoreFile="/tmp/ECC/tomcat_keystore.jks"
certificateKeystorePassword="${keystore.password}"
certificateKeyPassword="${key.password}"
certificateKeystoreType="PKCS12"
certificateKeystoreProvider="SUN" type="EC"/>
</SSLHostConfig>
ECDSA ciphers require that the server has an ECC certificate. It is likely that you have only a RSA certificate though (which is the common case), which means that ECDSA ciphers will not be supported even if they are configured.
i'm opening a kTLS connection using openssl client and server, how can i verify that it's actually opened a tls connection.
Note: i know that when i supply a certificate and cipher when establishing the connection but i want a way to know the type of the connection even if i don't know who and how someone open it.
i try netstat
Example : netstat -an | grep Port-No
and get tcp6 title but nothing regarding the security of the connection
the command is used:
Client:
env LD_LIBRARY_PATH=#LD_LIBRARY_PATH:`pwd`/.. ./openssl s_client -tls1_2 -debug -connect 1.1.1.2:4433
Server:
sudo env LD_LIBRARY_PATH=#LD_LIBRARY_PATH:`pwd`/.. ./openssl s_server -tls1_2 -cipher ECDHE-RSA-AES128-GCM-SHA256
I'm searching for a tool/command that can show the security protocol that established connection use.
I am hitting this error 'remote error: tls: handshake failure':
~/go/bin/aci-tls 10.0.0.201 user pass
2016/12/20 18:12:04 post error: Post https://10.0.0.201/api/aaaLogin.json: remote error: tls: handshake failure
Code is basic HTTPS client: https://play.golang.org/p/cqPT0oR__q
OpenSSL is happy with this https server:
$ openssl s_client -connect 10.0.0.201:443
(snip)
SSL handshake has read 1383 bytes and written 431 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
(snip)
Tested on:
$ go version
go version go1.7.4 linux/386
C:\>go version
go version go1.7.4 windows/amd64
gotlsscan says:
lab#ubu:~$ go version
go version go1.8beta2 linux/386
lab#ubu:~$ ~/go/bin/gotlsscan -host 10.0.0.201 | grep -v NOT
Testing SSL30 (DISABLED)
Testing TLS1.0
Testing TLS1.1
Testing TLS1.2
lab#ubu:~$
lab#ubu:~$ ~/go/bin/gotlsscan -insecure -host 10.0.0.201 | grep -v NOT
Testing SSL30 (DISABLED)
Testing TLS1.0
Testing TLS1.1
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA [OK]
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA [OK]
Testing TLS1.2
How can I further troubleshoot this issue?
The server for some reason doesn't accept the TLS1.2 handshake, nor does it properly fall back to TLS1.1. You can force the client to use only TLS1.1 and the compatible cipher suites with
cfg := &tls.Config{
CipherSuites: []uint16{
tls.TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
tls.TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
},
PreferServerCipherSuites: true,
InsecureSkipVerify: true,
MinVersion: tls.VersionTLS11,
MaxVersion: tls.VersionTLS11,
}
I have a problem, i made a command "openssl s_client -connect server.server:143", and the error is:
CONNECTED(00000003)
140719622096768:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown proto col:s23_clnt.c:769:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 249 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
I made that because the horde connection gives an error in login.
How can i resolve this?
openssl s_client -connect server.server:143
Port 143 is plain IMAP, that is you can not talk directly TLS to this port. If you try it you will get some data back which are not TLS, and thus strange error messages will occure. If you want to have TLS you have to either use imaps (port 993) or issue a STARTTLS command. You can also use openssl for this with
openssl s_client -connect server:143 -starttls imap
From your output it might even be that you used this option but did not put it into your question (because 7 bytes from the server would match a TLS alert, but is unusually short for an IMAP greeting). If this is the case there might be lots of reasons why the connection fails and it is not possible to pin the problem down just from your description. If you get more help look at http://noxxi.de/howto/ssl-debugging.html#hdr2.2 on how you could narrow down the problem and what you should provide on information if you need help from others.
I am setting up a Nagios/Icinga Monitoring system to monitor my enviroment. I would like to monitor my SSL certs with check_ssl_cert by it is not working on all sites.
My command:
/usr/lib/nagios/plugins/check_ssl_cert -c 7 -w 28 -H 141.85.37.43 -r /etc/ssl/certs/
returns:SSL_CERT CRITICAL: Error: verify depth is 6
(141.85.37.43 is just an example adress, not my own, but makes the same mistake).
if i try
# openssl s_client -connect ftp.myDomain.de:443
CONNECTED(00000003)
140037719324328:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error:s23_clnt.c:741:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 320 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
or
# curl https://ftp.myDomain.de:443 -v
* About to connect() to ftp.myDomain.de port 443 (#0)
* Trying 212.xxx.xxx.xxx...
* connected
* Connected to ftp.myDomain.de (212.xxx.xxx.xxx) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS alert, Server hello (2):
* error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error
* Closing connection #0
curl: (35) error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error
I am using a crushFTP on a ubuntu system called ftp.myDomain.de. I can use it with https://ftp.myDomain.de without any problem.
The cert is installed as a .pem file and was validated vom Thawte.
Is there something wrong with my cert?
I thing i got something. It is something with my SSL-Certs. I need to check with ssl version 3to get a working result.
Icinga plugins # openssl s_client -connect ftp.myDomain.de:443 -ssl3
i modified check_ssl_cert and added a new param -ssl to define version, just like the check-http offered:
http://pastebin.com/f46YQFg3 (need to post it there, to long for stackoverflow.com)
and can check it with
Icinga plugins # /usr/lib/nagios/plugins/check_ssl_cert -c 7 -w 28 -H "ftp.myDomain.de" -r "/etc/ssl/certs/" --ssl 3
SSL_CERT OK - X.509 certificate for 'ftp.myDomain.de' from 'Thawte DV SSL CA' valid until Jun 5 23:59:59 2015 GMT (expires in 676 days)|days=676;28;7;;
so my problem is kind of solved but i need to figure out what is the difference to my old - no workaround needed - certs and if i am in need to change something there?
I got in contact with the developer behind check_ssl_cert and he optimized and implemented my solution in an updated version.
https://trac.id.ethz.ch/projects/nagios_plugins/wiki/check_ssl_cert
I came across this same problem on a new Nagios box and tried the latest version of check_ssl_cert without success.
In the end the solution was to install expect.
I cannot say for certain, as I do not have all the necessary details, but it would seem that your certificate is fine, it is just that it's authentication chain is too long for check_ssl_cert to verify it.
The error message says "Verify depth is 6". This means that the certificate verify chain is >6 items long, not that it is necessarily failing.
Around line 228 and 205 in check_ssl_cert, you see the code:
exec_with_timeout $TIMEOUT "echo 'Q' | $OPENSSL s_client ${CLIENT} ${CLIENTPASS} -connect $HOST:$PORT ${SERVERNAME} -verify 6 ${ROOT_CA} 2> ${ERROR} 1> ${CERT}"
Note the -verify 6 in there limiting the maximum chain length to test. If you change this to -verify 16 (which might be overkill but should handle your chain) it will most likely work.