I recently upgraded a server based on Python 3.8.6 to Python 3.10.5
The Twisted listener in it allows various devices to connect
Some of those devices only have TLSv1.
The server code specifically enables TLSv1/1.1/1.2/1.3 but only 1.2 and 1.3 work.
According to this issue https://bugs.python.org/issue43998 Python SSL no longer supports less than v1.2. But twisted uses pyOpenSSL, and I cannot find any documentation that states it only supports v1.2 and later.
Can anybody please supply some information on this.
Related
I am running Hazelcast as a cache service, it seems I can improve perf with BoringSSL and this is simpler because I don't need to install additional software
Reading their doc: https://docs.hazelcast.com/imdg/4.1.2/security/integrating-openssl.html
I see that I just need two jars, but I don't see any mention of config settings. Do I just use the Java SSL settings with BasicSSLContextFactory?
I see I can use com.hazelcast.nio.ssl.BasicSSLContextFactory as mentioned here https://docs.hazelcast.com/imdg/4.1.2/security/tls-ssl.html#tlsssl-for-hazelcast-members for the Java SSL implementation
They also provide com.hazelcast.nio.ssl.OpenSSLEngineFactory for OpenSSL integration (https://docs.hazelcast.com/imdg/4.1.2/security/integrating-openssl.html#using-openssl)
BoringSSL is the library to use OpenSSL. So this link is a good source. However, if you not bound to the old Java versions, then nowadays Java TLS is faster than OpenSSL, so no need for BoringSSL.
Since SSL is a Hazelcast Enterprise feature, feel free to raise a Hazelcast Zendesk Ticket if you need some more detailed help.
Starting with Hazelcast version 4.0, there is the following logic deciding which TLS engine is used:
when Java version<11 and a netty-tcnative package (wrapping OpenSSL, BoringSSL, ...) is on the classpath: Use the OpenSSLEngineFactory;
in all other cases: Use the BasicSSLContextFactory.
Surely, you don't need to use the defaults, but you can specify the factory-class-name configuration attribute with the factory of your choice.
You can use the same properties in OpenSSLEngineFactory like the ones in BasicSSLContextFactory (e.g. keyStore*, trustStore*). Nevertheless, the native way of configuring the OpenSSLEngineFactory is by using keyFile and other properties mentioned in the documentation section about OpenSSL.
Why the Java 11 check
As mentioned above, the OpenSSLEngineFactory is not used for Java 11 and newer by default. This decision was based on Hazelcast performance testing which shows OpenSSL performance benefits when used with Java 8, but not with Java 11 (or newer).
Here are throughput graphs from those tests (performed in 2019).
TLSv1.2
TLSv1.3
I have to support an Android device that uses Android API <20 (KitKat and older). We use AWS for our APIs and want to support TLSv1.3 and beyond, but these devices may not be upgraded for some time. Android API <20 doesn't natively support TLSv1.3+, but is it possible to use a third-party TLS library to support TLSv1.3? If so, how? Googling around has not turned up anything apart from "upgrade your device".
It's possible to do this using the Conscrypt Library which goes all the way back to Android 2.x
You can reference that library and then make use of it by:
Security.insertProviderAt(Conscrypt.newProvider(), 1);
I don't think Android device will support TLS 1.3 because TLS 1.3 is too new and almost all the browser cannot support TLS 1.3. The most of theme they use the older version TLS 1.2, TLS 1.2 compatible with all the IDE and Web platforms such as chrome or firefox. Also TLS 1.3 is very hard to create because there is almost no info about encryption with TLS 1.3.
I need to connect a WinCE6.0 device to a web based server using HTTPS.
The problem: WinCE6.0 uses WinInet v6 which supports SSL2, SSL3 and TSL1.0 None of which are supported in the current (2018) best practices due to their security flaws.
I doubt I can drop in a newer version of WinInet and expect it to run.
I had thoughts of porting CURL to WinCE.
I'm thinking this issue has already been addressed by the CE community, but I'm not seeing an available solution.
How can I get an old embedded device to securely connect to the WWW?
From GuruCE:
If you want to use TLS 1.1 and 1.2 on CE a suitable solution is to use mbedTLS library from ARM. It has a BSD-like license, so not too restrictive. Only one change to the makefiles is needed to get it to work on CE.
I'm trying to add SNI to my client-side program (C/C++) that uses Microsoft SDK's Schannel API for TLS.
I've searched everywhere but could not find any documentation on how Schannel supports SNI extension.
I looked up the documentation for AcquireCredentialsHandle(), InitializeSecurityContext() but no success.
So, could anyone please help me with some example code?
The SNI is specified as part of the ClientHello, which is generated by InitializeSecurityContext(). Specficially, Schannel uses the 3rd parameter of that function for certificate validation, as well, as SNI; but not all versions of Windows support TLS extensions (which includes SNI).
TLS Extensions were first introduced in Internet Explorer 7 beta 3 on Windows Vista. Plus, even if your operating system supports it, TLS will likely be turned off, by default.
There is a working example on CodeProject that shows SNI from the client and server side.
I'm trying to test WS-MAN capabilities to manage multiple hypervisors (mainly ESXi and Hyper-V); in terms of Hyper-V, all samples I come across insist on first tuning the Hyper-V authentication to "basic"; does anyone know if this is a shortcoming in current OpenWSMAN implementation or by design it can't support other authentication mechanism OR please correct me if my understanding is wrong :-).
System Details:
Host OS: SL 6.1
OpenWSMAN: 2.2.0 (client version)
Thanks!
I found an explanation for above observation. On linux, OpenWSMAN uses OpenSSL for authentication connections, now OpenSSL on Linux supports "digest" and Windows machines does not. Windows supports Kerbos/GSSAPI which is not currently supported by OpenSSL.
Thanks!