About to compile libevent from sources, I just noticed that it seems to have a dependency on OpenSSL for encryption o_O.
This sounds like bloat.
What does a library that provides OS-independent asynchronous IO abstractions need encryption for?
How can it justify a dependence on OpenSSL which I assume is also large and complicated?
libevent-2.0.21-stable/README
38 The configure script also supports the following flags:
39
40 --enable-gcc-warnings Enable extra compiler checking with GCC.
41 --disable-malloc-replacement
42 Don't let applications replace our memory
43 management functions
44 --disable-openssl Disable support for OpenSSL encryption.
45 --disable-thread-support Don't support multithreaded environments.
From whatsnew-2.0.txt:
5.4. SSL support for bufferevents with OpenSSL
There is now a bufferevent type that supports SSL/TLS using the
OpenSSL library. The code for this is build in a separate
library, libevent_openssl, so that your programs don't need to
link against OpenSSL unless they actually want SSL support.
There are two ways to construct one of these bufferevents, both
declared in <event2/bufferevent_ssl.h>. If you want to wrap an
SSL layer around an existing bufferevent, you would call the
bufferevent_openssl_filter_new() function. If you want to do SSL
on a socket directly, call bufferevent_openssl_socket_new().
It's for your convenience, if you need SSL sockets. If you do not need it, why not simply disable it using the option from the README snippet from your question?
Related
I am running my JDK8 application in JDK11 enviroment.
I am using TLSv1.2 and TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 cipher suite algorithm which i am suspecting that it is not supported or disabled in JDK11.
There are list of ciphers which are supported by jvm
please refer https://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html
Also if you see here someone has listed cipher which is supported by jdk upto jdk1.8
https://developer.ibm.com/answers/questions/301898/where-i-can-find-list-of-cipher-suites-that-suppor/
but I want to know which cipher suite algorithm is supported/enabled/disabled in jdk11.
I am using TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 cipher algorithm but when i am trying to run my application in jdk 11 run time environment I am getting SSLHandshakeException(Getting javax.net.ssl.SSLHandshakeException in JDK11). That's why I am trying to change my cipher suite algorithm and for the same i want to know which algorithm I can use in JDK11 enviroment.
It will be helpful if i also get to know the ciphers which are supported by both jdk11 and jdk8.
Please help me with it.
Thanks.
For revised Q:
Your first link is to (Oracle, and thus OpenJDK) java 7 not 8; there are differences in TLS ciphersuite support between 7 and 8, although not affecting the ciphersuite you name. Your link for 'upto 1.8' is for IBM Java which uses different cryptoproviders and is not good documentation for Oracle/OpenJDK crypto. Note the question at that link is specifically "... Cipher suites that supported by IBM Java" -- NOT Oracle/OpenJDK Java. For Oracle/OpenJDK 8 see https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#ciphersuites and for 11 see https://docs.oracle.com/en/java/javase/11/docs/specs/security/standard-names.html#jsse-cipher-suite-names . Both include TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 and as expected it works for me in Oracle 11.0.2, and numerous versions of 8. All TLSv1.2 ciphersuites supported in 8 are still supported in 11, although 11 additionally supports TLSv1.3 (which you apparently aren't using).
Aside from the fact that, as commented, the Java defaults usually do better at providing security than overrides by people who don't know what they're doing, the exception you report in your other Q (but didn't provide here)
javax.net.ssl.SSLHandshakeException: Invalid ECDH ServerKeyExchange signature
does not in any way indicate that the ciphersuite you name is unsupported. First, please be clear whether your application is the TLS client or server -- even if there is not a client/server relationship in the application protocol, there always is in the TLS protocol; that's how TLS (and SSL before it) is defined.
Second, follow the standard instructions for SSL/TLS=JSSE debugging by running with system property javax.net.debug=ssl and show the resulting output (probably just the last 100 lines or so, because it's quite voluminous).
Original Q was much vaguer and appeared to be about RC4, but actually wasn't.
Your question text gives no clue what 'cipher suite algorithm' you mean, but you tagged RC4-cipher. If your issue is using (any of the) ciphersuites that include RC4 in TLS 1.2 or earlier, then you shouldn't. RC4 was prohibited for TLS by RFC7465 in Feb. 2015 because of rapid advances in cryptanalytic attacks on it. This applies to all versions of TLS protocol existing in 2015 (1.0, 1.1 and 1.2), and was implemented by all supported versions of Java: 8 from 8u60 up, and all releases of 9 and higher.
If you really want to use RC4 and risk attackers stealing your data -- perhaps it is actually false, meaningless, or otherwise valueless -- either change the setting in the java.security file or call Security.setProperty early in your program (before loading JSSE); see the JSSE Reference Guide e.g. for Java11. Note in j8 the file location is different, <JREhome>/lib/security/java.security. See also RC4 related issue after Java 8 update .
If and when you (want or need to) use TLS 1.3, which Java 11 and up supports, this is no longer an option. TLS 1.3 only supports AEAD ciphers (or modes), which RC4 as originally defined is not, and no proposal for an AEAD construct based on RC4 will be accepted today.
On the other hand if you just want to use good, secure ciphersuites, don't change anything and just use the defaults. The defaults are the defaults precisely because they are secure, at least as far as is currently known. If analytic advances change that, then the defauts will be changed accordingly, and your programs using them will also be secure without you having to make, test, distribute, and verify new releases.
I was looking to enable chacha/poly algorithm in the openssl 1.1.0 version. I googled alot but couldn't get the resolution. please help me if any one knows
How do I enable chacha/poly in openssl1.1.0
ChaCha20/Poly1305 is enabled by default in OpenSSL 1.1.0. With all other things being equal, you will use it if its a common cipher and its selected by the client or server.
If you are not seeing ChaCha20/Poly1305 as the cipher suite, then check the server. It probably lacks support for curve25519 or the cipher suite. You should still see the cipher suite advertised in the ClientHello.
A disappointing thing about ChaCha and Poly1305 is they are only available as a unit via EVP_chacha20_poly1305. You cannot use just ChaCha or just Poly1305. (And ChaCha is TLS's ChaCha, and not Bernstein's ChaCha).
Also see How to use Poly1305 with EVP interfaces? on the OpenSSL Users mailing list.
I am working on a custom dissector for Wireshark in lua.
Certain PDUs in the protocol is encrypted using AES and I would like to decrypt these so that I can show the clear content in Wireshark. Is this possible with a lua dissector and what APIs can I use to make the decryption?
Or do I need to make a c/c++ dissector to make a dissector that decrypts data?
Personally i use lua-crypto but it requires OpenSSL.
You can check lua-wiki.
Recently i create wrapper for this AES implementation called bgcrypto.
It has no external dependencies but i really do not use it yet in real work.
At the moment Wireshark (2.0) does not expose a crypto API to LUA dissectors, so you have to implement it in the Lua dissector.
For a pure Lua solution you can use lua-lockbox (as mentioned on the Lua wiki). This is not recommended if you need performance, but might be useful for prototyping.
Faster AES decryption implementations typically use a native library, for example:
LuaCrypto - uses OpenSSL, though it does not seem maintained
lcrypt - uses libtomcrypt, but there seems to be no development either
Since none of these libraries satisfied my needs, I developed a new one based on Libgcrypt for these reasons:
Wireshark already links to Libgcrypt for things like SSL decryption.
The Libgcrypt library supports sufficiently many ciphers and hashes.
Libgcrypt is widely available and has an active development team.
The Luagcrypt API is simple enough and documented.
The result is luagcrypt which works on the platforms supported by Wireshark (Linux, OS X, Windows). It is used in the KDNET dissector, this commit shows the transformation from lua-lockbox to luagcrypt.
I am currently working on a Hadoop project that requires data encryption (because the data will be stored in S3). While I primarily expect to access the data though Hive, it would be nice to be able to access it via Pig and any other MapReduce methods.
I know Hadoop has built-in support for compression codecs like gzip, snappy, etc... Is there any support for encryption codecs as well (specifically, GPG)? Has anyone written a GPG SerDe (or anything similar) that is publicly available?
Last I knew Hadoop has no internal support for encryption whatsoever. Seems like you could overload the CompressionCodec with your GPG code, ala http://www.mail-archive.com/common-user#hadoop.apache.org/msg06229.html
Happy Hacking & let us know if you find a solution!
My application need to download several web-pages simultaneously and i know this is possible in a single thread because of experience with epoll programming in linux. Currently i use CURL to interact with HTTP but...
update: Discovered the curl's MULTI-interface: http://curl.haxx.se/libcurl/c/libcurl-multi.html I think question is resolved (-;
The cross-platform way is to use select or poll which are specified by POSIX.
Alternatively, and more efficiently, you could use a library. The main advantage of a library is that it can do things way more effectively than select, by employing system-specific mechanisms.
For example, a nice network library would probably use:
epoll on Linux
kqueue on FreeBSD
/dev/poll on solaris
pollset on AIX
iocp on Win32
etc
I think you can use asio for C++ or libevent for C.