I want to disable usage of:
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
I went though this:
https://support.microsoft.com/en-us/help/245030/how-to-restrict-the-use-of-certain-cryptographic-algorithms-and-protoc
I tried something like:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes
Adding DWORD SHA384 to 0x0
But found it is not working.
You can use IIS Crypto.
Click on Chiper Suites and disable the chipers you want. You'll be prompted to restart after click aplly.
Related
Is it possible to set up a reverse proxy in ISPConfig?
I tried this setting on a subdomain, but I only receive a error 500.
The /var/www/influxdb2.*******.***/log/error.log says the following:
==> error.log <==
[Fri Jan 01 21:24:15.963158 2021] [proxy:warn] [pid 30333] [client ***.***.***.***:59356] AH01144: No protocol handler was valid for the URL /favicon.ico (scheme 'http'). If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule., referer: https://influxdb2.*******.***/
For me, the proxy_http mod was missing.
Enable it via sudo a2enmod proxy_http and restart your apache with systemctl restart apache2 (thanks to https://serverfault.com/questions/773449/no-protocol-handler-valid-for-the-url-with-httpd-mod-proxy-balancer).
Also note that the "redirect type" setting sometimes seems to reset itself to "none" on saving (or at least does not display the correct value on loading the page as of ISPConfig 3.2.1). So double check that setting if something does not work.
For the "Domain" tab, settings are pretty straightforward. Just enter your domain and probably enable Let's Encrypt.
Note that this seems to use mod_rewrite for proxying. The Apache2 documentation on mod_rewrite states that better ProxyPass of mod_proxy should be used instead. So if anything breaks with some applications, this might be a starting point for further investigations (worked for me for reverse proxying to the HTTP endpoint of InfluxDB 2.0.3 at http://localhost:8086).
I have moved a PHP script to another server, and now fail to login to an IMAP (TLS) postbox:
TLS/SSL failure for mail.servername.de: SSL negotiation failed
It seems that the problem is caused by OpenSSL, because when I try to connect to the Mailserver from both servers, I get a connection in one case (the mailserver asking for input), but none in the other (the connection is closed, I am back to bash):
openssl s_client -crlf -connect mail.servername.de:993
The most obvious difference is here:
verify return:1
---
<snip>
-----END CERTIFICATE-----
subject=/CN=mail.servername.de
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: DH, 1024 bits
---
SSL handshake has read 3398 bytes and written 483 bytes
Verification: OK
---
New, TLSv1.2, Cipher is DHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
And on th other server (where no connection is made)
verify return:1
depth=0 CN = mail.servername.de
verify return:1
140410888582464:error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small:../ssl/statem/statem_clnt.c:2149:
---
<snip>
-----END CERTIFICATE-----
subject=CN = mail.servername.de
issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
---
No client certificate CA names sent
---
SSL handshake has read 3167 bytes and written 318 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Server public key is 2048 bit
On the mailserver dovecot is configured not to accept non-encrypted connections. But, I assume it already fails due to dh key too small, which seems to relate to cipher negotiation.
Now I simply fail to put the things together... Why does the SSL connection work from one server, but not from the other?
As I own the "remote end" myself, I was able to increase security. The solution is simple, and may be relevant for others as well ...
The dovecot version is 2.2.x, which is of some relevance for the DH parmaters (see Dovecot SSL configuration). In the configuration file /etc/dovecot/conf.d/10-ssl.conf you can simply add this line:
ssl_dh_parameters_length = 2048
And eventually, it may be necessary to add this here to the main configuration file /etc/dovecot/dovecot.conf at the end:
!include conf.d/*.conf
Finally, it is important not to reload, but to restart dovecot.
systemctl restart dovecot
And suddently, the weight, troubles, and frustration of several hours is gone. Great...
Further to the above, there's a change from dovecot 2.3.
ssl_dh_parameters_length is now not used, and ssl_dh must be used instead, to point to a file generated using
openssl dhparam 4096 > dh.pem
see https://doc.dovecot.org/configuration_manual/dovecot_ssl_configuration/ and scroll down to SSL Security Settings. That was the only change I had to make following the upgrade to get it to work properly again. I put the dh.pem file in /etc/dovecot, so my line in 10-ssh.conf is
ssl_dh=</etc/dovecot/dh.pem
TL;DR: your new host has a newer version of OpenSSL probably with higher security settings which prohibit connecting to the host for reasons explained below.
"dh key too small" comes from OpenSSL and because of too low security.
Things changed, and for example in newest Debian versions and with OpenSSL 1.1.1 (and I guess it is similar for newer versions), the security was enhanced.
The best and simplest explanation I have found is on Debian wiki at https://wiki.debian.org/ContinuousIntegration/TriagingTips/openssl-1.1.1
which says:
In Debian the defaults are set to more secure values by default. This
is done in the /etc/ssl/openssl.cnf config file. At the end of the
file there is:
[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT#SECLEVEL=2
This can results in errors such as:
dh key too small
ee key too small
ca md too weak
Now the possible solutions in descending order of preference:
ask the remote end to generate better "DH" values ("Server Temp Key: DH, 1024 bits"); the best explanations are at https://weakdh.org/sysadmin.html; note specifically the "Administrators should use 2048-bit or stronger Diffie-Hellman groups with "safe" primes."
configure your end specifically for this connnection to not use the OS default and lower your settings; it should be enough to set ciphers to "DEFAULT#SECLEVEL=1" in the code that does the connection
(really, really, really not recommended) change the value of SECLEVEL from 2 to 1 in the global configuration file on your end. But this impacts all connections from your host not just this one so you are lowering the global security of your system just because of one low level of security from one remote node.
SNMP_Exporter works fine when snmp.yml file when
default:
version: 3
auth:
username: SomeUser
password: TotallySecret
auth_protocol: SHA
priv_protocol: AES
security_level: SomethingReadOnly
priv_password: SomeOtherSecret
walk:
- ...
metrics:
- ...
AES by default here means with 128 bit key i think
so what changes would i have to make to walk a device that is using AES 256 bit key as privacy protocol.
AES256 is not a part of the SNMP standard, though some vendors have custom support for it. If you want it added to the SNMP exporter you will first need to get it added our upstream at https://github.com/soniah/gosnmp/
I am using Fiddler 5.0 to capture https requests of mobile app. It works fine except one app. Below is logs of Fiddler.
21:31:59:7072 HTTPSLint> Warning: ClientHello record was 508 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance
21:31:59:7072 !SecureClientPipeDirect failed: System.Security.Authentication.AuthenticationException A call to SSPI failed, see inner exception. < 处理证书时，出现了一个未知错误。 for pipe (CN=ci.migudm.cn, O=DO_NOT_TRUST, OU=Created by http://www.fiddler2.com).
21:31:59:7412 !SecureClientPipeDirect failed: System.Security.Authentication.AuthenticationException A call to SSPI failed, see inner exception. < 处理证书时，出现了一个未知错误。 for pipe (CN=ci.migudm.cn, O=DO_NOT_TRUST, OU=Created by http://www.fiddler2.com).
21:31:59:7862 HTTPSLint> Warning: ClientHello record was 508 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance
Have you checked out the link provided by the logs? There's a bunch of very relevant information there that I think might help you get what you need:
Some web servers are unable to process Client Hello messages longer than 255 bytes, even though such messages are allowed by the protocol. Although most Client Hello messages are shorter than this limit, with the use of Server Name Indications (SNI), Elliptic Curve extensions, and the increase in the number of supported suites, the size can easily go over.
Browsers are thought not to be affected, but some other tools may be. In particular, OpenSSL 1.0.1+ is known to be affected. If you are using the s_client tool, try to reduce the size of the handshake by disabling some of the suites offered by OpenSSL (this can be done by specifying the desired suites using the -cipher switch).
OpenSSL Bug #2771: Openssl 1.0.1 times out when connecting to Outlook Exchange 2007; sign in with guest/guest.
F5 tracks this problem under bug #376483 and it is fixed in BIG-IP LTM 10.2.4 (see [SOL14758: SSL client connections may fail if the ClientHello message is greater than 255 bytes and uses TLS 1.1 or 1.2] (https://support.f5.com/kb/en-us/solutions/public/14000/700/sol14758.html) for more details).
Michael Tschannen says:
The issue is fixed according to F5 in 10.2.4, they are however not mentioned in any release notes (I have >just checked until 11.x)
To debug the issue on an F5, the log level of "SSH" needs to be at least "Informational".
Example:
Mar 22 09:44:21 local/tmm info tmm[4696]: 01260013:6: SSL Handshake failed for TCP from x.x.x.x:443 to x.x.x.x:49549
Source: https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance
If you've been through all of this information, could you please provide the F5 version, OpenSSL version, and log information from OpenSSL?
I have setup a WebSphere Application Server on my RHEL 7 virtual machine. When I start the server, it starts fine and I can access the admin console but when I try to stop or get the status of the server using the script
sh stopServer.sh -server1 / sh serverStatus.sh server1
It gives the following message,
ADMU0509I: The Application Server "server1" cannot be reached. It appears to be stopped.
My wsadmin scripts are not working, when I run the script
sh wsadmin.sh -user wasadmin -password Password
I get the following error
WASX7023E: Error creating "SOAP" connection to host "localhost"; exception information: com.ibm.websphere.management.exception.ConnectorNotA
vailableException: [SOAPException: faultCode=SOAP-ENV:Protocol; msg=; targetException=java.net.MalformedURLException]
WASX7213I: This scripting client is not connected to a server process; please refer to the log file /opt/IBM\WebSphere/AppServer
/profiles/AppSrv01/logs/wsadmin.traceout for additional information.
I can access the console on the browser without any issue.
To expand on this more specifically. The file ssl.client.props looks like this typically around the com.ibm.ssl.protocol property:
$ grep -i tls -C 2 /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/properties/ssl.client.props
#-------------------------------------------------------------------------
com.ibm.ssl.alias=DefaultSSLSettings
com.ibm.ssl.protocol=SSL_TLS
com.ibm.ssl.securityLevel=HIGH
com.ibm.ssl.trustManager=IbmPKIX
--
#-------------------------------------------------------------------------
#com.ibm.ssl.alias=AnotherSSLSettings
#com.ibm.ssl.protocol=SSL_TLS
#com.ibm.ssl.securityLevel=HIGH
#com.ibm.ssl.trustManager=IbmX509
This property can take a number of values:
This property is the SSL handshake protocol that is used for this SSL
configuration. This property attempts Transport Layer Security (TLS)
first, but accepts any remote handshake protocol, including SSLv3 and
TLSv1. Valid values for this property include SSL_TLS, SSL, SSLv2
(client side only), SSLv3, TLS, TLSv1, SSL_TLSv2, TLSv1.1, and
TLSv1.2.
These values are described in this table:
References
ssl.client.props client configuration file
Appendix A: Protocols and Cipher Suites
For me this problem came when the security level of the WAS was not consistent.
In the IBM console, it was set to TLSv1.2 and in ssl.client.props file it was set to SSL_TLS. Once they were changed to the same value my console could connect to WAS.