Lee:
We are using your j2ssh Maverick 1.5.4. It works great. However, we found that the default ciphers are aes128-ctr and 3des-ctr only. But, according to API, there are many other ciphers supported in the library. How should I code it so that all ciphers supported can be used?
Thanks a lot in advance.
Mark
Most of the other ciphers are Counter Block Mode (CBC) ciphers which are no longer advised. See https://www.kb.cert.org/vuls/id/958563
You can add any of the cipher implementations in com.sshtools.ssh.components.jce back to the ComponentManager if you wish using the code below. Remember to add each cipher to both the client->server and server->client component factories.
ComponentManager.getInstance().supportedSsh2CiphersCS().add(
Ssh2Context.CIPHER_AES128_CBC, AES128Cbc.class);
ComponentManager.getInstance().supportedSsh2CiphersSC().add(
Ssh2Context.CIPHER_AES128_CBC, AES128Cbc.class);
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.
I am using Qt5 on Windows 7.
I currently have a server app that uses a QSslSocket to communicate with clients.
It works ok so far, but the customer wants me to use only TLS protocol, and make sure we never fall down to SSL protocol (which he considers to be not secure enough).
In my code there's absolutely nothing set explicitly, I only used the default(s) offered by the QSslSocket class.
I saw in Qt doc that by default QSslSocket uses TLSv1_0, yet I am not quite sure, because...
On the other hand, the Qt doc says, see QSsl::SecureProtocols: "The default option, using protocols known to be secure; currently behaves similar to TlsV1Ssl3 except denying SSLv3 connections that does not upgrade to TLS."
So, I am a little bit puzzled about this...
Finally, the question is: Would the default (what I have right now) of QSslSocket class guarantee that the connection is TLS encrypted? If not, what should I do in order to be sure the connection always uses TLS protocol?
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.