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/
Related
I am new to learning about certificates & their use in cybersecurity. I was experimenting around with my browser's certificate issued by GTS which is google trust services.
Now, I am confused about what the signature algorithm field means. I tried to google search this and found that the signature algorithm refers to the algorithm used to sign the certificate. If that is the case, I don't understand why I see 3 different signature algorithm fields in my cert. Also, 2 of them have a key size associated with them while the first field does now.
The first signature algorithm is under the category of "Issuer" so I thought maybe this is the algorithm being used to sign the cert. The second & third fields, shown in the second image, are under the category of public key. So what are they being used to sign?
Also, I don't see any key associated with the first signature algorithm, so I am a bit confused with this. Any help is much appreciated! Thank you!
Meta: this is not a programming issue, but I can't fit this in a comment. I am not voting to close because it is inappropriate to do so after answering, but if I am notified the question is closed I will delete (or I authorize a mod to do so) to ensure Q can be deleted or roombad.
I don't know what program you are using to get that decode, or if you have modified it beyond the black-outs, but it appears to be seriously misleading. Here is a better decode from OpenSSL, which follows the ASN.1 structure, with <<# marks added by me:
(redacted)>openssl s_client -connect www.google.com:443 <NUL 2>NUL | openssl x509 -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
45:48:e6:58:30:39:c0:ad:0a:00:00:00:00:ff:65:fa
Signature Algorithm: sha256WithRSAEncryption <<#1A
Issuer: C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
Validity
Not Before: Sep 13 04:06:57 2021 GMT
Not After : Nov 20 04:06:56 2021 GMT
Subject: CN = www.google.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:d7:27:92:c3:bb:e0:95:f4:20:46:a4:1a:5f:96:
78:a7:58:9d:cb:7c:2a:9c:7c:cb:2d:be:30:e9:c1:
71:80:11:da:c3:57:c4:c1:74:5c:a6:26:64:c3:49:
53:7c:44:19:f2:b3:c4:b3:5f:fc:90:30:b3:d4:31:
d1:16:09:b2:97:44:43:99:d6:13:19:20:ef:92:9e:
6e:41:44:56:32:c8:1c:5b:54:48:38:6b:5d:c5:00:
a4:62:be:7e:51:76:26:f6:5b:9c:e0:ed:b3:b8:dd:
16:eb:c6:9d:fc:b6:16:c0:60:1a:84:d8:b1:a5:d1:
5d:1f:35:eb:40:08:f0:2b:a1:a8:e8:d0:93:8f:85:
c6:25:a3:63:d0:d8:09:2e:fa:d2:6f:12:73:4e:aa:
ad:6f:c6:cb:b0:24:b4:65:e3:e3:fd:03:f9:d4:64:
07:2a:4b:6b:df:6b:ae:b2:90:eb:7e:57:f0:a8:3e:
08:d1:07:06:e8:04:dc:a6:bd:02:ee:07:97:1f:cf:
41:2c:8a:b0:15:bc:de:c9:13:b9:0a:8f:38:78:4c:
03:d1:46:36:e6:54:e4:3b:5f:eb:f4:02:14:82:09:
d9:0e:60:ea:29:b4:e3:7e:81:8d:4c:81:ee:4b:6d:
6e:a8:7f:f5:79:39:21:20:01:eb:77:4d:ea:22:d8:
15:13
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
C0:43:06:E9:20:B5:1E:51:86:CF:27:BB:3B:91:D5:0B:AE:F8:99:A6
X509v3 Authority Key Identifier:
keyid:8A:74:7F:AF:85:CD:EE:95:CD:3D:9C:D0:E2:46:14:F3:71:35:1D:27
Authority Information Access:
OCSP - URI:http://ocsp.pki.goog/gts1c3
CA Issuers - URI:http://pki.goog/repo/certs/gts1c3.der
X509v3 Subject Alternative Name:
DNS:www.google.com
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
Policy: 1.3.6.1.4.1.11129.2.5.3
X509v3 CRL Distribution Points:
Full Name:
URI:http://crls.pki.goog/gts1c3/QqFxbi9M48c.crl
CT Precertificate SCTs:
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : 7D:3E:F2:F8:8F:FF:88:55:68:24:C2:C0:CA:9E:52:89:
79:2B:C5:0E:78:09:7F:2E:6A:97:68:99:7E:22:F0:D7
Timestamp : Sep 13 05:06:59.644 2021 GMT
Extensions: none
Signature : ecdsa-with-SHA256 <<#2
30:45:02:21:00:84:00:48:E0:6F:E9:0F:D7:AF:A6:67:
22:C8:D3:D3:A8:E4:FB:38:11:3E:5B:C2:EF:AC:E2:54:
7A:94:AC:1A:47:02:20:1E:84:FB:69:49:C2:1B:2E:0B:
84:8C:AD:CA:13:FF:97:19:3C:57:8A:0A:AC:23:DD:61:
C2:AB:7F:07:46:45:65
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : 94:20:BC:1E:8E:D5:8D:6C:88:73:1F:82:8B:22:2C:0D:
D1:DA:4D:5E:6C:4F:94:3D:61:DB:4E:2F:58:4D:A2:C2
Timestamp : Sep 13 05:06:59.161 2021 GMT
Extensions: none
Signature : ecdsa-with-SHA256 <<#3
30:45:02:21:00:D5:16:13:47:CE:39:C6:60:AF:11:24:
61:A3:D3:B6:50:BF:32:01:0D:6F:5F:5F:2E:37:E4:F8:
1E:60:9E:70:E6:02:20:09:6A:39:F4:15:FC:36:6C:5F:
9B:C7:E1:B5:48:64:7F:BC:FD:36:6E:1D:7B:E5:74:6A:
55:B0:6E:0F:AF:CF:FF
Signature Algorithm: sha256WithRSAEncryption <<#1B
3a:11:f4:ac:db:fe:63:eb:40:ae:09:4e:d2:3a:89:90:37:c2:
bd:f5:bf:8e:69:7b:48:4e:33:6a:35:46:35:50:bc:94:2e:c3:
87:b4:66:e4:d6:bd:2f:98:99:d4:ba:0f:56:04:de:20:44:86:
61:35:50:3f:66:95:fc:4a:2a:69:b7:3b:0c:70:0f:17:cc:60:
a4:fe:1d:b3:f8:90:0c:b9:fa:3d:69:d0:2f:a9:15:91:cd:89:
bb:92:7d:f5:c6:7f:2f:b8:89:0a:95:f3:71:93:1c:52:77:22:
e8:af:54:f1:b2:0f:9c:4f:9b:28:59:c4:de:ed:63:0f:7b:06:
69:ac:af:5d:bd:1c:52:ca:67:3a:db:52:10:f3:16:55:20:dd:
db:4c:e7:93:e5:d1:56:d1:1f:07:12:0c:da:8c:df:c8:d7:91:
98:5c:c2:f7:f4:dc:ff:66:6b:35:95:f8:b9:cc:cd:1d:0b:cf:
d1:99:5e:ce:1a:d9:97:f3:c5:85:65:e0:17:b9:88:c6:1e:5f:
51:01:97:21:4e:49:6b:a6:ed:3d:df:8d:95:b5:be:54:5a:e4:
58:0d:4c:50:64:5f:47:91:48:45:d4:2b:37:50:bf:d5:fb:cd:
54:f3:c5:a2:72:38:fd:44:da:f9:6f:6a:2a:45:2c:ac:c5:a5:
37:3f:e8:fe
#1A and #1B are the algorithm of the signature on the cert by the issuer, which is in the block following #1B. Yes, there are two copies of this AlgorithmIdentifier in the ASN.1 structure, at the places shown, because X.509 was designed back in the 1980s and people then were concerned about algorithm substitution attacks based on experience with symmetric/secret-key systems, which turned out not to be a significant problem for asymmetric/public-key systems. It is SHA256withRSA because the issuing CA, GTS CA 1C3, uses an RSA (2048-bit) key. Edit: found crossdupes https://security.stackexchange.com/questions/24788/signaturealgorithm-vs-tbscertificate-signature and https://security.stackexchange.com/questions/114746/why-is-the-signature-algorithm-listed-twice-in-an-x509-certificate .
#2 and #3 are the algorithms for signatures on the two Signed Certificate Timestamps (SCTs) embedded in the certificate to support Certificate Transparency. You can see each one is part of an indented block under a heading Signed Certificate Timestamp:. The SCTs are created and signed by various transparency log systems, identified by their logid, and the two log systems GTS CA 1C3 chose to use happen to both have used ecdsa-with-sha256 signatures with P-256 keys. (We can directly see only that the R,S values are 256 bits corresponding to some curve group with a 256-bit order, but RFC6962 confirms that the only acceptable ECDSA curve is P-256.)
Aside: I don't understand why you thought it necessary to black-out some information from a certificate that everyone in the world can easily get and look at. The entire purpose of a certificate (at least an Internet server certificate) is to be publicly known to everybody.
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.
The Goal
I'm trying to make a call to a telephone number. I'd like to be able to make a call from the raspberry pi, and also make a call to my voip.ms phone number and be able to answer or auto-answer and play some generic .wav file.
My current understanding of things
This maybe should be titled "My current misunderstanding of things". I'm new to sip and pjsip, and I think I must be missing some part of the process I don't understand. I was under the impression that, if I register with voip.ms, when I make a call it would route to voip.ms and they would do a lookup on the number/address, and then respond with an address that I would then begin to communicate with.
What I've done so far
Compiled
I've compiled Pjsip on a Raspberry Pi 3B+ properly, for what I can tell. I can include pjsua2.hpp in my c++ applications. I've roughly followed this tutorial
Tested compilation with pjsua binary && demo.cpp
I'm running into identical problems running a modified pjsua2_demo.cpp and the binary included in the pjsip build. For the sake of simplicity, I'll ask about the binary located (for me) at <project-path>/pjproject-2.8/pjsip-apps/bin/pjsua-armv7l-unknown-linux-gnueabihf.
Successfully registered with voip.ms
I have an account and phone number with Voip.ms and can become registered with voip.ms by executing the following script:
call_and_auto_answer.sh
./pjsua2-cpp/pjproject-2.8/pjsip-apps/bin/pjsua-armv7l-unknown-linux-gnueabihf \
--play-file ~/CantinaBand60.wav \
--local-port=5060 \
--auto-answer 200 \
--auto-play \
--auto-loop \
--max-calls 5 \
--config-file ./sip.cfg
Where the config looks like:
sip.cfg
#
# Logging options:
#
--log-level 5
--app-log-level 4
#
# Account 0:
#
--id sip:<my-subaccount-username>#sip.voip.ms
--registrar sip:<server-location>.voip.ms
--reg-timeout 300
--realm *
--username <my-subaccount-username>
--password <my-subaccount-password>
--use-timer 1
#
# Network settings:
#
--local-port 5060
#
# Media settings:
#
--srtp-keying 0
--auto-play
--auto-loop
--play-file /home/pi/CantinaBand60.wav
--snd-auto-close 1
#using default --clock-rate 16000
#using default --quality 8
#using default --ec-tail 200
#using default --ilbc-mode 30
--rtp-port 4000
#
# User agent:
#
--auto-answer 200
--max-calls 5
#
# SIP extensions:
#
--use-timer 1
When I enter the cli, I see for my account list:
Account list:
[ 0] <sip:192.168.1.49:5060>: does not register
Online status: Online
[ 1] <sip:192.168.1.49:5060;transport=TCP>: does not register
Online status: Online
*[ 2] sip:<my-subaccount-username>#sip.voip.ms: 200/OK (expires=285)
Online status: Online
Buddy list:
-none-
Voip.ms shows I've registered on their website.
The problem
I'm trying to call my personal cell phone from my pi (I assume using the registered voip.ms phone number), and call my pi from my personal cell phone. While calling out I'm typically getting either 408 Request Timeout errors or 502 gethostbyname errors.
Different destinations, different errors
Depending on the destination for my call from the pi, I get one of two different errors most of the time
Timeout Error
I get an error that says,
18:19:19.757 pjsua_app.c ....Call 4 is DISCONNECTED [reason=408 (Request Timeout)]
18:19:19.757 pjsua_app_comm ....
[DISCONNCTD] To: <destination-sip-address>
where is any of the following:
sip:
sip:
sip:thetestcall#sip2sip.info
sip:thetestcall#iptel.org
sip:201#ideasip.com
and the phone numbers are formatted like: 3035551234, though I've tried prepending a 1 and a +1 just to check.
Lookup Error
I get an error that says,
19:09:45.435 sip_resolve.c ....Failed to resolve '<destination-sip-address>'. Err=70018 (gethostbyname() has returned error (PJ_ERESOLVE))
19:09:45.435 tsx0x18520dc ....Failed to send Request msg INVITE/cseq=10722 (tdta0x185012c)! err=70018 (gethostbyname() has returned error (PJ_ERESOLVE))
19:09:45.435 pjsua_app.c .......Call 4 is DISCONNECTED [reason=502 (gethostbyname() has returned error (PJ_ERESOLVE))]
19:09:45.435 pjsua_app_comm .......
[DISCONNCTD] To: sip:<destination-sip-address>
where is any of the following:
sip:
sip:
sip:abcd1234
Possible Successes
I'm getting what looks like a success while calling:
sip:**12340#ideasip.com
It confirms the call and has a bunch of messages, notable including:
19:16:17.550 pjsua_core.c ....TX 1300 bytes Request msg INVITE/cseq=13899 (tdta0x15c263c) to UDP 208.97.25.11:5060:
...
19:16:17.551 pjsua_app.c .......Call 4 state changed to CALLING
...
>>> 19:16:17.606 pjsua_core.c .RX 575 bytes Response msg 100/INVITE/cseq=13899 (rdata0x6d7008a4) from UDP 208.97.25.11:5060:
...
19:16:17.609 pjsua_core.c .RX 946 bytes Response msg 200/INVITE/cseq=13899 (rdata0x6d7008a4) from UDP 208.97.25.11:5060:
...
19:16:17.609 pjsua_app.c .....Call 4 state changed to CONNECTING
...
19:16:17.610 pjsua_app.c .....Call 4 state changed to CONFIRMED
...
19:16:17.676 pjsua_core.c .RX 594 bytes Response msg 100/INVITE/cseq=13900 (rdata0x6d7008a4) from UDP 208.97.25.11:5060:
...
19:16:17.678 conference.c ......Port 5 (sip:**12340#ideasip.com) transmitting to port 5 (sip:**12340#ideasip.com)
...
19:16:17.678 conference.c ......Port 1 (/home/pi/CantinaBand60.wav) transmitting to port 5 (sip:**12340#ideasip.com)
...
19:16:36.931 pjsua_app.c ......Call 4 is DISCONNECTED [reason=200 (Normal call clearing)]
Same Network
Additionally, if I set up a second pjsip client on the same network, I can call it from pi1 and answer the call on pi2.
Incoming calls
When I register with voip.ms, then try to call my voip.ms phone number from my personal cell phone, the call fails with a message on my iPhone that says, User Busy. This makes me think I'm messing something up with the registration, or that I'm missing some component, like a subscribe or link with that voip.ms account.
Final thoughts
I'm not sure what I'm missing here. I've read through a ton of the pjsip and pjsua docs, and I can't find anything I'm missing. Does anybody have insight into how to make a call to a phone number and allow for incoming calls? This has been quite a few days of solid work.
So I figured out the answer to my question. Here's the skinny:
Voip.ms registration
My registration with voip.ms wasn't configured properly. I was given credentials by a coworker, but upon further inspection of the sip endpoint, I found that the DiD number purchased for the account wasn't associated with the subaccount my coworker created for me. So, depending on the recipient's phone carrier, I was given different errors. Additionally, when I was testing inbound calls and receiving the error, User Busy, this was because the account I registered wasn't associated with the phone number.
To fix this, on voip.ms I associated the DiD number to my subaccount, and then went to my subaccount information and set the callerId number to be my DiD number, though I think you can override this value via pjsip.
Outbound sip calls
Secondly, to call a phone number, outbound calls should follow the following format:
sip:<phoneNumber>#<endpoint>
So for me, this looked very much like:
sip:5551234567#newyork.voip.ms
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 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.