I went through a lengthy process removing mod_ssl and replaced it with gnutls because I wanted to use TLS 1.3.
The difference I’ve noticed is gnutls doesn’t support older, legacy methods, only new ones.
OpenSSL supports them all. Is that a better choice? I could find very little support configuring with gnutls and Apache other than the RTFM pages.
Cons pro? Should I move back to mod_ssl? I'm leaning towards, I made a mistake with GnuTLS just for TLS 1.3 and to get a good security ranking score.
Most people use OpenSSL, and it has been updated to work with newer versions of TLS as well as older versions (backwards compatibility).
As far as which is better, I don't know, but most use OpenSSL.
And regarding "Server Fault" in the comment, the user could have been more informative, and likely was referring to the domain, serverfault.com, which they did not elaborate to, making it confusing.
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 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 am using openssl 1.0.1 on os x el capitan. I want to enable TLS compression. I have set SSLCompression on but still doesn't do compression.
P.S. I know that compression is unsafe but I have to enable it to demonstrate CRIME attack for my class. I have also got browser that supports compression, so browser doesn't seem to be issue. The ServerHello message always decide to use null(0) compression.
Then the issue seems to be located serverside.
If you are the administrator of the server and if the server runs a recent OS, I'm afraid you'll probably have to manually compile OpenSSL with option zlib on it.
It is said that openssl are widely used, however, as far as I know, the most popular browsers seem not use openssl, instead, they use other SSL libraries like:
NSS (for all firefox and chrome in Linux)
SChannel (for browsers in Windows)
Secure Transport (for browsers in Mac OS X).
Am I right? Or is there any concept I'm taking wrong?
Thanks.
OpenSSL is widely used in web server, according to netcraft survey (http://news.netcraft.com/archives/2015/06/25/june-2015-web-server-survey.html) it can be over 60% of all web servers : Apache with mod_ssl, Google and Nginx. For browser it is just not widely used.
We have apache 2.2.14 but need to upgrade to a higher version due to security vulnerabilities. Apache 2.2.19 is the highest and available now, but we are not sure if it will be compatible with Tomcat 6 we are having. How can I find out about the compatibilities & possible risks? and will it be compatible with tomcat 7?
Nobody will guarantee you 100% absence of any issues when upgrading, but then there is little chance of anything breaking when just hopping a few steps in the 2.2 line. It also depends on how you proxy to Tomcat, only AJP (mod_jk) integrates tighter with it, slightly raising the probability of possible but unlikely issues.
In the end, if you're worried, it's a matter of reading the changelogs. The "just try" approach works too, in the assumption you have a proper testing/QA stage.