I ran an PCI Compliance scan over my system and some vulnerabilities are saying that I have to upgrade openSSH version of my server.
How can I achieve this using AWS Ec2 Instance Ubuntu 16.04?
Solution provided from "Nessus":
https://www.tenable.com/plugins/nessus/96151
Furthermore some vulnerabilities are caused by the current TLS Version used. Currently it's just LetsEncrypt Certificate. Am I right that when I purchase a certificate those vulnerabilities will be gone? Because the "bought ones" are not TLS v1.0 ?
Related
I'm running Red Hat Linux Enterprise Linux 7.9 which hosts a tentacle application.
After a vulnerability scanner on this server, it shows a TLS vulnerability over the port 10993, which is the port used for octopus tentacle and the vulnerability rapport shows that the server is successfully connected over TLSv1.1
I had verified on the server into /etc/octopus/Tentacle/ tentacle-Tentacle.config file but nowhere its mentioned the SSL/TLS settings on the Linux machine. I need someone to help where exactly it’s pointing this TLS1.0, TLS1.1 and where the TLS config file is located to disable the use of the weak version.
Thank you,
I have configured a ListenHTTP 1.7.0 processor in NiFi 1.7.0-RC1. It is listening on a custom port behind a reverse proxy. I have configured a StandardRestrictedSSLContextService with a JKS keystore and have added the keystore password. We have not configured the truststore as we don't expect to need mutual TLS. The certificate is signed by an internal enterprise CA and is (or should be!) trusted by the client.
When I test this with Chrome I receive the following:
This site can’t provide a secure connection
my.server uses an unsupported protocol.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Unsupported protocol
The client and server don't support a common SSL protocol version or cipher suite.
Troubleshooting:
We have tried both TLS and TLSv1.2 in the ListenHTTP processor.
We have treid using curl (Linux) and Invoke-WebRequest (Windows) but have received variations on the bad cipher/SSL version message above.
I don't see anything in the release notes suggesting that the ListenHTTP processor changed much since 1.7.0, so I'm assuming that I don't need to upgrade NiFi.
Can anyone suggest what to try next or explain why we see this error?
I have read the following:
https://www.simonellistonball.com/technology/nifi-ssl-listenhttp/
https://cwiki.apache.org/confluence/display/NIFI/Release+Notes
Nifi: how to make ListenHTTP work with SSL
What version of Java are you running on? Java 11 provides TLSv1.3, which is the default offering if you have generic TLS selected, but NiFi 1.7.0 doesn't support TLSv1.3 (and doesn't run on Java 11). So assuming you are running on Java 8, recent updates have introduced TLSv1.3 but should still provide for TLSv1.2. This can also indicate that the certificate you have provided is invalid or incompatible with the cipher suite list provided by the client. You can use $ openssl s_client -connect <host:port> -debug -state -CAfile <path_to_your_CA_cert.pem> to try diagnosing the available cipher suites & protocol versions. Adding -tls1_2 or -tls1_3, etc. will restrict the connection attempt to the specified protocol version as well.
You should definitely upgrade from NiFi 1.7.0 -- it was released over 2 years ago, has known issues, and there have been close to 2000 bug fixes and features added since, including numerous security issues. NiFi 1.12.1 is the latest released version.
I have updated Docker 1.10 to 1.10.1 on latest CentOS 7 minimal. I am using Docker Remote Socket with self-signed certificates.
Now I get suddenly: 509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate
I guess this is either a CentOS issue or Docker issue. Does anybody know how I can tell Docker or CentOS to verify my personal self-created authority? (file ca.pem)
Solved this: Environment Variable DOCKER_CERT_PATH on client machine pointed to a deprecated directory.
I'm new to Cassandra and just installed DataStax Community Edition 3-node cluster in our QA environment. I'd like to secure node-to-node and client-to-node communications within my cluster using GlobalSign wildcard SSL cert that I already have. So far I found posts showing how to secure cluster using your own CA but wasn't able to find any mentions on how to use wildcard certs. Basically, I'd like to install my wildcard cert to all nodes in the cluster and use DNS A-records to match node IP address and the DNS name (e.g. 10.100.1.1 > node01.domain.com).
Is that even possible? Any help is greatly appreciated!
Mike
Using anything but certificate pinning as described in the reference is insecure, as Cassandra will not validate if the hostname the certificate was created for is actually the host trying to connect. See CASSANDRA-9220 for details.
I have unrealirc running on my aws and it is compiled with ssl. I downloaded the server.key.pem to my machine. When I try to connect to the server I getSSL Error: ssl not available
I can log into aws through a terminal with my server key.
02[10:48] * Connecting to ec2-xx-xx-xx-114.compute-1.amazonaws.com (+6697)
-
02[10:48] * SSL error: ssl not available
-
02[10:48] * Connect cancelled
Also I added the correct port to my Security Group
Any Suggestions?
Are you missing the openssl shared libraries on your ec2 instance? That seems unlikely but without more info seems most likely from the error.
On a Redhat based image try:
yum search ssl
and Debian try
apt-cache search ssl
That will tell you what ssl libraries are installed.