Microsoft lists 36 cipher suites available to TLS 1.2 protocol enabled in a vanilla installation of Windows Server 2016 Build 1607:
excludes 2 cipher suites available only used when an application explicitly requests
source: https://learn.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-10-v1607
Accounting for enabled=false Ciphers and KeyExchangeAlgorithms (registry HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL), and verifying that Cipher Suite Order and Elliptic Curve Order is default (gpedit.msc), the list of enabled cipher suites is reduced to 32.
Why does nmap 7.9.1 return only 10 cipher suites?
nmap --script ssl-enum-ciphers -p3389 TestServerName.domain.tld
results
4 x TLS_DHE_RSA_WITH_AES_*, and
6 x TLS_ECDHE_RSA_WITH_AES_*
The most recent update on nmap.org thread "ssl-enum-ciphers not returning all ciphers" is July 23, 2019: https://seclists.org/nmap-dev/2019/q3/4
Has anyone resolved this issue?
PS There is a difference of TLS version in a single network trace frame (shown below) and I'm not certain if this is part of the issue or unrelated.
I have learned that the the ordered set of Cipher Suites that are Enabled on a Windows device is defined in the value data from the Functions value located in the Registry at:
HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002
This can be populated during creation of the Group Policy Object, or locally using Group Policy Editor (i.e. choosing "Enabled" and editing the list and/or order of cipher suites).
If Functions value is absent, then the ordered set of Enabled cipher suites are default for the Edition and Build of Windows:
https://learn.microsoft.com/en-us/windows/win32/secauthn/cipher-suites-in-schannel
Related
According to https://cloud.google.com/iot/docs/how-tos/mqtt-bridge#downloading_mqtt_server_certificates TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 using P-256 is recommended for mqtt.2030.ltsapis.goog
The IoT module that I'm using (Quectel M66) supports only the following cipher suites.
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256
Is it possible to connect to mqtt.2030.ltsapis.goog using one of the above cipher suites?
Thanks
Unfortunately, it will not be possible.
The long term MQTT domain is intended to aid in using a TLS configuration for a long period of time. As such, the TLS features listed in the documentation could be seen as "minimum standard needed" to ensure security.
You can read more about Google's minimum standards for TLS clients here
Do note that you can test the following points:
TLS 1.2 must be supported.
A Server Name Indication (SNI) extension must be included in the handshake and must contain the domain that's being connected to.
The cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 must be supported with P-256 and uncompressed points.
In this link https://cert-test.sandbox.google.com/
It is unlikely support will be added to those older cipher suites, since it could potentially lead to botnets and other security issues over time. You can also verify the security of cipher suites in this link which is updated regularly.
The recommendation would be to look for devices that support TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 using P-256 and uncompressed points for the cipher suite, which will have a higher likelihood of working uninterrupted for a few years.
Does someone now with key size (128-bit?) is used by GLib in GSocketConnection/GTlsConnection? Is this fix implemented or changeable?
In GLib, you are effectively negotiating a TLS (Transport Layer Security) session key/cipher.
Therefore this will depend on the connection partners preferences and supported cipher suite.
Cipher suites will be dependent on the version of TLS used too.
More information on TLS cipher suites here.
The TLS implementation in GLib actually just uses either GnuTLS or OpenSSL, so the key size is handled by them. GLib does not override their defaults or decisions.
I have enabled TLS1.2 on Windows Server 2008 R2. I need this for a CC payment gateway. Recently they disabled acceptance of certain insecure ciphers which has broken my connection to their server. In order to get it to work again I need to get my server to use accepted ciphers. These ciphers are already enabled on the server but my connection keeps defaulting back to these disallowed ciphers.
First I tired disabling these ciphers.
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
This killed RDP and SSL on my server. This is not a good thing.
So instead I tried setting the priority of the ciphers but nothing seems to work. I tried using gpedit to set cipher priority as follows but to no avail.
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_3DES_EDE_CBC_SHA,
SSL_CK_DES_192_EDE3_CBC_WITH_MD5
I tried using IIS Crypto to reorganise the order of ciphers but again, no luck.
I use the following ASP Classic script to see what ciphers my server is using.
dim winhttp
Set winhttp = Server.CreateObject("MSXML2.ServerXMLHTTP")
winhttp.open "GET", "https://howsmyssl.com/a/check", False
winhttp.Send
Response.Write winhttp.responseText
The response get is:
{"given_cipher_suites":
["TLS_RSA_WITH_AES_256_CBC_SHA256","TLS_RSA_WITH_AES_256_CBC_SHA","TLS_RSA_WITH_AES_128_CBC_SHA256","TLS_RSA_WITH_AES_128_CBC_SHA","TLS_RSA_WITH_3DES_EDE_CBC_SHA"],"ephemeral_keys_supported":false,"session_ticket_supported":false,"tls_compression_supported":false,"unknown_cipher_suite_supported":false,"beast_vuln":false,"able_to_detect_n_minus_one_splitting":false,"insecure_cipher_suites":{},"tls_version":"TLS 1.2","rating":"Improvable"}
Link
I am at somewhat of a loss here. Does anyone know how I can set the cipher priority for TLS1.2 so that it uses accepted ciphers or do I have to remove those insecure ciphers completely and if so how can I dot it without killing RDP and SSL on IIS?
Thanks for your time.
Finally got this worked out. If anyone else happens to have this issue this is what I did to fix it.
The easyfix on this page at Microsoft helped by setting the registry keys that I needed. I then opened up IIS Crypto to see my ciphers were all over the place. Fortunately I had Server 2008 R2 running in a VM on my work PC (I was using it to try to find answers to my problem) so I could grab the correct order. Here's what I used (last two may not be necessary).
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P521
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P521
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P521
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P521
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
SSL_CK_DES_192_EDE3_CBC_WITH_MD5
Also, make sure that Diffie-Hellman and ECDH are selected under Key Exchanges in IIS Crypto, otherwise it defaults to weak ciphers.
Based on the following sencryption protocols, what's the supported one by Asterisk?
RC4
RC2
DES
3DES
Are there other encryption protocols suppoorted by asterisk?
Are there an asterisk command to know the supported encryption protocols?
With regards to SIP, Asterisk (via chan_sip) supports encryption of both the signalling and the media. Arheops comment that Asterisk 1.8 doesn't support encryption is incorrect; this is true in Asterisk 1.8 and all later versions. For more information, see the Secure Calling section on the Asterisk wiki.
Signalling is encrypted using OpenSSL (yes, the one with the vulnerability. Upgrade if you haven't). It defers encryption of the SIP signalling to OpenSSL. Which cipher is used is dependent on the version of OpenSSL you have installed, as well as what you configure in sip.conf, via the tlscipher option.
;tlscipher=<SSL cipher string>
; A string specifying which SSL ciphers to use or not use
; A list of valid SSL cipher strings can be found at:
; http://www.openssl.org/docs/apps/ciphers.html#CIPHER_STRINGS
;
Asterisk supports encryption of the media in one of two ways. The first, supported in Asterisk 1.8 and later, is SDES-SRTP, via the libsrtp library. libsrtp uses AES as the default cipher.
As SDES-SRTP has to exchange keys in plain text in the signalling, another method of encrypting the media is available in Asterisk 11 and later, DTLS-SRTP. This uses OpenSSL's DTLS capabilities (available in more recent versions) to exchange the keys between the participants in the encrypted media stream. Note that this is the mechanism mandated by WebRTC (whereas SDES-SRTP got slapped down with a "SHOULD NOT" be implemented).
On a final note, in Asterisk 12, the new SIP stack (based on PJSIP), also supports all of these various encryption mechanisms.
During an SSL/TLS handshake, the client sends up a list of supported cipher suites and the server selects which one to use for the conversation. Windows has a prioritized list of cipher suites (configurable via the registry) and will select the first suite in that list that is supported by the client. Once a list of acceptable ciphers is created using the cipher suite flags, what algorithm does OpenSSL use to select the cipher suite when it's acting as a server? I could not find the answer in the OpenSSL documentation.
The list of cipher suites sent by the client is ordered; the first suite in the list is the one most preferred by the client. Normally, OpenSSL, as a server, honors the client preference: it selects the suite most preferred by the client among the list of suites that both the client and server support.
Since OpenSSL-0.9.7 (released at the end of 2002), OpenSSL has a programmatic flag called SSL_OP_CIPHER_SERVER_PREFERENCE which enforces the server preferences: the list of cipher suites supported by the server is also ordered by preference, and the server selects the suite that the server itself most prefers among those that both the client and server support. This flag is documented in the ssl.h include file.
With the command-line "s_server" command, the "-serverpref" option is used to activate the SSL_OP_CIPHER_SERVER_PREFERENCE flag.
Have a look at this manpage.
The cipherlist command converts OpenSSL cipher lists into ordered SSL
cipher preference lists. It can be used as a test tool to determine the
appropriate cipherlist.