OpenSSL with Java

后端 未结 6 1007
栀梦
栀梦 2021-02-02 10:06

I have to use OpenSSL in a Java web project and I don\'t know anything about \'OpenSSL\'.

How can I integrate OpenSSL with my project? is there any good fundamental tuto

相关标签:
6条回答
  • 2021-02-02 10:25

    There are lots of Java native libraries for crypto. However they are generally not fully interoperable with OpenSSL, are sometimes significantly slower (see the metrics on the site below), and aren't supported on all platforms. OpenSSL is definitely supported on nearly every platform and is, generally, performant.

    That being said, there are some security advantages to using VM-based crypto. This should also be a consideration.

    The Apache group has built a library for Java that uses JNI to access openssl for AES encryption. I think it's the best public example of using JNI to access openssl, and you can reference it easily using maven.

    https://github.com/apache/commons-crypto

    If you want, you can pull out the JNI binding portion of the libary and implement the functions you need.

    This makefile shows how to use javah to get what you need from the .class to build the .c code:

    https://github.com/apache/commons-crypto/blob/master/Makefile

    Specifically, this line in the Makefile calls javah: $(JAVAH) -force -classpath $(TARGET)/classes -o $@ org.apache.commons.crypto.cipher.OpenSslNative to produce the correct "OpenSslNative.h" file based on the OpenSslNative.class.

    https://github.com/apache/commons-crypto/blob/master/src/main/java/org/apache/commons/crypto/cipher/OpenSslNative.java

    Note how import java.nio.ByteBuffer; is used to allow for C output buffers.

    The associated .c program is here:

    https://github.com/apache/commons-crypto/blob/master/src/main/native/org/apache/commons/crypto/cipher/OpenSslNative.c

    It's written with cross-platform support in mind, and is a good example. Every exported function must begin with JNIEXPORT, and you can see how the full class path is in each function name.

    I've seen a lot of bad JNI bindings, passing strings around, etc. Starting with a solid base goes a long way toward building good OpenSSL integration in Java.

    0 讨论(0)
  • 2021-02-02 10:26

    Best solution: Use Java's built-in security for simple tasks or use BouncyCastle for more advanced ones.

    If you HAVE TO use OpenSSL from Java you have 2 choices:

    1. Call openssl as a process from Java.
    2. Make a JNI layer to OpenSSL, but that seems like a complete waste of time to me. None of those are really good ways of doing it.
    0 讨论(0)
  • 2021-02-02 10:33

    You need to answer a few important questions before any suggestions

    1) Do you really want to call C(native) implementation form JAVA?

    2) What are the features in OpenSSL which cannot be solved by JCE and BouncyCastle

    3) Is the scope just limited to using certificates generated by OpenSSL, decrypting files generated by OpenSSL?

    0 讨论(0)
  • 2021-02-02 10:39

    First of all: what do you need the library for?

    • If you are going to use simple cryptographic functions, then use the Java SE Security components deployed with the JDK.
    • If you need more advanced functions (such as some digital signing formats, etc), use a cryptographic library (BouncyCastle is one of the the most popular)
    • But, if what you need is to open SSL connections from Java code, and handle certificates authentication, etc, you won't need any of these:
      • If you are working on a Java EE Container, your container can validate incoming SSL requests: it's just a matter of configuration
      • Also, if you need to connect to a SSL port, the JDK presents some basic classes for doing so (see this example). Note that in this case, you'll need to set some system properties on your java command.

    Like these properties:

    -Djavax.net.ssl.keyStore=keystore_path
    -Djavax.net.ssl.keyStorePassword=password
    -Djavax.net.ssl.trustStore=truststore_path
    -Djavax.net.ssl.trustStorePassword=trustword
    
    0 讨论(0)
  • 2021-02-02 10:44

    Everyone talks about BouncyCastle, but in our use case Gnu Crypto library won the day. Native java.

    Our database ( aerospike ) spends at least 10% of its time computing hashes in java, for some customers, simply because these implementations are slow. I welcome when there's a native implementation of the crypto libraries available on every Linux machine. I thought some of the Java7 VMs were going to include more algorithms, but I haven't seen them yet.

    0 讨论(0)
  • 2021-02-02 10:51

    Apache Tomcat Native Library is the solution. https://github.com/apache/tomcat-native

    It uses OpenSSL for TLS/SSL capabilities. You can use it as standalone library (as I did) or connect your Tomcat. It is open source project with well documented Java code.

    Why tomcat native?

    JSSE is slow and hard to use. In my project to get best performance we've decided to find/write JNI wrapper for OpenSSL as possibility for upgrading certificates on-the-fly is a question mark and Key Stores are too complex.

    As Bouncy Castle Crypto APIs is written in Java you cannot expect best efficiency.

    Tomcat Native is a wrapper so you are limited only to capabilities of your OpenSSL version.

    0 讨论(0)
提交回复
热议问题