I am using websockify 0.8.0 the latest version, but it doesn't support TLS-1.2 by default. I am looking for the strong cipher to be displayed for sslscan --no-hearbleed hostname:6080 command output.
Adding some extra info to make the question more clear : On running the below command, 3DES cipher is resulted with the least strength i.e. C.
nmap --script ssl-enum-ciphers -p 6080 hostname
On the same host DES is disabled for port 443. So it seems for nginx it has been taken care but for python-websockify it is still present.
So in brief I am finding the way to disable the 3DES cipher on port 6080 of the host. Thanks in advance.
Answering my own question. https://notes.bitfunnel.net/?q=node/54 helped.
Related
I am running CentOS 7.9 (server edition)
I have been searching online for some help on how to disable weak ssh cypher. However, I do not seem to be able to fix the issue. Qualys scans keeps reporting weak cipher in ssh service. I followed some recommendations (i.e: https://www.thegeekdiary.com/how-to-disable-weak-cipher-and-insecure-hmac-algorithms-in-ssh-services-for-centos-rhel-6-and-7/) online without any luck.
Here is what my /etc/ssh/sshd_config looks like
# Addresses Qualys QID 38739 Deprecated SSH Cryptographic Settings (CentOS 6)
## Changed this line:
##ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,cast128-cbc,aes192-cbc,aes256-cbc,rijndael-cbc#lysator.liu.se
## to this line:
ciphers aes128-ctr,aes192-ctr,aes256-ctr
Thank you for your help.
Step 1:
Go to below directory and uncomment the below line
Vi /etc/sysconfig/sshd
Uncomment
CRYPTO_POLICY=
Step 2:
Go to the below directories and append the below lines at the end of file
vi /etc/ssh/sshd_config
KexAlgorithms curve25519-sha256#libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305#openssh.com,aes256-gcm#openssh.com,aes128-gcm#openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm#openssh.com,hmac-sha2-256-etm#openssh.com,umac-128-etm#openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128#openssh.com
Step 3:
systemctl restart sshd
System:
Maxscale 2.5.9
Ubuntu 20.04
In order to access the Web AdminGUI my maxsclale.cnf file looks like this:
[maxscale]
threads=auto
admin_host=0.0.0.0
admin_secure_gui=1
admin_auth=1
admin_enabled=1
admin_gui=1
admin_ssl_key=/etc/ssl/certs/maxscale-key.pem
admin_ssl_cert=/etc/ssl/certs/maxscale-cert.pem
admin_ssl_ca_cert=/etc/ssl/certs/ca-certificates.crt
[...all other configuration..]
With this configuration I can access the Web-AdminGUI on port 8989 from the internal ip address (not 127.0.0.1) by browser.
The SSL key/certs are self-signed .
BUT
When using the command line like:
maxctrl list servers
I get the following error:
Error: Error: socket hang up
When I remove or comment out the lines with the admin_ssl_XXX parameters and restart maxscale, command line works again, but of course the Web-AdminGUI does not.
I tried with various SSL certificate creations (also the one that is listed on the mariadb.com-Website
https://mariadb.com/docs/security/encryption/in-transit/create-self-signed-certificates-keys-openssl/#create-self-signed-certificates-keys-openssl),
the issue remains.
No errors in the maxscale.log whatsoever.
What is the best way to debug this issue?
Or do you have by any chance the right answer at hand?
YOUR help is greatly appreciated!
BR. Martin
You should use maxctrl --secure to encrypt the connections used by it.
Since you are using self-signed certificates, you have to also specify the CA certificate with --tls-ca-cert=/etc/ssl/certs/ca-certificates.crt if it's not installed in the system certificate store.
In addition, you probably need to use --tls-verify-server-cert=false to disable any warnings about self-signed certificates.
I'm attempting to enable SSL on hiveserver2.
I can run in the default binary mode fine. http mode works no problem. As soon as I enable SSL through hive-site.xml, i'm faced with the following error.
ERROR [Thread-28] thrift.ThriftCLIService: Error starting HiveServer2: could not start ThriftHttpCLIService
java.net.BindException: Address already in use
There is nothing using any of the ports, prior to starting hiveserver2. Checked with netstat -tupln
Ports i've configured in hive-site.xml are
hive.server2.webui.port 11002
hive.server2.thrift.http.port 11001
hive.server2.thrift.port 11000
and invoking hiveserver2 via the service /opt/hive/bin/hive --service hiveserver2 &
O/S ubuntu (on kubernetes)
Hive version 3.0.0
Any help greatly appreciate. Google search for problems with ThriftHTTPCliService came up short.
For anyone that come across this post.
I upgraded to Hive 3.1.0, along with the metastore schema.
This fixed the issue, although unsure as to the underlying cause.
I have a Mac running OS X Server 5.2 and due to company policy I need to force the server to use TLS 1.2 only and turn off TLS 1 and TLS 1.2.
I have edit the conf files in the /Library/Server/Web/Config/apache2/sites to SSLProtocol -all +TLSv1.2 but it still allows connection with tls1 and tls1.2
Does anybody know how to enforce TLS 1.2 connections only?
Thanks!
If that is an option, update your Server app. Starting with Server version 5.3, support for TLS 1 and TLS 1.1 has been disabled by default, so this solution would be simple and effective.
If you cannot update for some reason, you will have to remove these protocols in /Library/Server/Web/config/proxy/apache_serviceproxy.conf, and possibly in /library/server/web/config/apache2/httpd.conf. Also note that I have found that you have to restart macOS in order to restart the proxy server (it is not sufficient to issue sudo serveradmin stop/start web). This seems to be unnecessary - see my update below!
Update
It looks like there is a bug in Apache that can prevent the above setting from working as expected. It seems that, if there ciphers active that are not allowed any more in TLS 1.2, the older TLS versions remain available despite the setting in SSLProtocol. These older cipher suites need to be deactivated as well.
Therefore, use this recommended configuration:
SSLProtocol -all +TLSv1.2
SSLCipherSuite ALL:+HIGH:!ADH:!EXP:!SSLv2:!SSLv3:!MEDIUM:!LOW:!NULL:!aNULL
SSLHonorCipherOrder on
Besides that, it looks like it's enough to update /Library/Server/Web/config/proxy/apache_serviceproxy.conf, as SSL/TLS is handled by the proxy process only. To restart the proxy use
$ sudo launchctl unload -w /Applications/Server.app/Contents/ServerRoot/System/Library/LaunchDaemons/com.apple.serviceproxy.plist
$ sudo launchctl load -w /Applications/Server.app/Contents/ServerRoot/System/Library/LaunchDaemons/com.apple.serviceproxy.plist
A server restart is not required.
There might be multiple occurrences in the configuration. I replaced them all, which may or may not be necessary.
I've got a Tcl/Expect program that reads and writes data to the serial port.
I did all of my development and testing on a Fedora 7 machine, but I'm now trying to run the same code in Ubuntu 8.10, and I'm getting the following error:
spawn: returns {0}
bad option "-mode": should be one of -blocking, -buffering, -buffersize, -encoding, -eofchar, or -translation
while executing
"fconfigure $port -mode 19200,n,8,1"
(file "./scan1.tcl" line 31)
I have no issues in Fedora, just Ubuntu. It would seem that it doesn't like the serial options being given to fconfigure, but I don't know of an alternate way of doing this.
Both machines have Tcl 8.4.
Here's the relevant code snippet:
#Open serial port
set portname "/dev/ttyS0"
spawn -open [set port [open $portname "r+"]];#This is a beast!
fconfigure $port -mode 19200,n,8,1
Does anyone know what's wrong? Thanks for your help!
Some research seems to indicate that the [fconfigure] command doesn't offer the -mode switch when it doesn't recognize the channel in question as being a true serial port (though I don't see this mentioned in the docs). Ultimately, that decision seems to rely on an "isatty()" system call, which is apparently failing to report the channel as a TTY. More info can be found here:
http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/ea0e772c59fa1e52/949c04fe4cebc2a3?q=fconfigure+mode+group:comp.lang.tcl#949c04fe4cebc2a3
According to the above thread, this could be due to a misconfigured Tcl.
Update... I see the serial configuration options (including -mode) are documented with the [open] command. There, it mentions that [fconfigure] can be used to query or set the additional options specific to serial ports. The [fconfigure] docs should probably be updated to reflect that fact also.
Bottom line, Tcl doesn't think your port really is a serial port under Ubuntu, though I don't know why...
Could be a bug. It has been in the past.
http://sourceforge.net/tracker/?func=detail&atid=110894&aid=218617&group_id=10894