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.
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.
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);
I'm trying to use the Qt Cryptographic Architecture to generate public/private key pairs for nodes, and want to have a protocol in which nodes confirm that a message came from a given source (public key) by issuing a challenge to ensure they are the owners of the corresponding private key. I'm a little stuck on the actual syntax for QCA though ...
This should get me a private key, from which I can also get the public key:
QCA::KeyGenerator generator;
QCA::PrivateKey privateKey = generator.createRSA(1024);
Does QCA already have some sort of challenge protocol built in? If so, how can I use it? If not, how can I apply some of the standard cryptographic challenge protocols using these keys? I'm really just trying to demo a simple security concept - I'm not looking for anything complicated or even particularly robust.
Also, this is a side question, but since I don't need encryption, should I be opting for DSA as opposed to RSA?
There are more than one of doing that. But since all clients already have their asymmetric key pairs you may deploy two-way TLS in establishing connection.
In this scheme both client and server allow establishing connection only, if they trust certificates (public keys) of each other. This guarantees client authentication and non-repudiation.
From your side you will need to provision server certificate to all clients and all client certificates to the server. To avoid dealing with certificate authorities, certificates could be self-signed.
QCA has examples for TLS client and server.
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.