not-yet-commons-ssl



Download Not-Yet-Commons-SSL!

Not-Yet-Commons-SSL currently has NO affiliation with the Apache Software Foundation (apache.org), but we're hoping to start Incubation one day.
Current Version (March 16th, 2015):
Full source:not-yet-commons-ssl-0.3.17.zip15 MBAlphaMD5: abbba5b3d0a67a0ff50bc9716bc5c6f8
Binary only:not-yet-commons-ssl-0.3.17.jar991KBAlphaMD5: f81f13575bd317ab4d9a6e73f58d4f36
Previous Version (September 23rd, 2014):
Full source:not-yet-commons-ssl-0.3.16.zip5.8MBAlphaMD5: a76a059767d3e67881da1680a32f16a8
Binary only:not-yet-commons-ssl-0.3.16.jar267KBAlphaMD5: ac3c7c1722222970677e723c22f1d4c8
All Previous Versions (use "svn export"):
 /svn/not-yet-commons-ssl/tags/

Warning:  All versions of not-yet-commons-ssl should be considered to be of "Alpha" quality! This code probably contains bugs. This code may have security issues.

Future versions will definitely break the current API in a non-reverse compatible way. After commons-ssl-0.5.0, though, we plan on always being reverse compatible with ourselves.


Changelog for not-yet-commons-ssl-0.3.17:

1. Bug fix for using SNI names with TLS.
We now call "setHost()" on the underlying sun.security.ssl.SSLSocketImpl socket class if possible to make interop with SNI-enabled servers possible. Called via reflection to maintain backwards compatibility with Java 5. (Note: SNI + TLS seems to only work on Java 7 or newer.)
2. Update ASN1 parsing code with latest from BouncyCastle.org.
We've also moved all the ASN1 parsing code into a new "org.apache.commons.ssl.org.bouncycastle" namespace to make the code provenance clear. Warning: this change could introduce regressions --- the BouncyCastle update required we update some of our own code to accommodate changes in their API.

Changelog for not-yet-commons-ssl-0.3.16:

1. Bug fix for TrustMaterial constructor.
Re-introduce ability to load an X509 certificate specified as raw bytes (e.g., byte[]) in the constructor. (Thanks to Brent Putnam for the bug report).
2. Remove protocol / cipher whitelists.
Got rid of useStrongCiphers() method (and its converse, useDefaultCiphers()), since all ciphers in Java 7 are at least 128 bit, and my approach used a white list that was starting to get out-of-date. If users want to ensure only strong ciphers are used in their SSL connections, they can either upgrade to Java 7 or newer, or invoke SSLClient.setEnabledCiphers() or SSLServer.setEnabledCiphers(). Also got rid of all logic that was setting default protocols, because again it was a white list that was getting out of date. We do still call SSLContext.getInstance("TLS") by default (can be overridden), but I figure that one should be okay for at least another decade.

Changelog for not-yet-commons-ssl-0.3.15:

1. Security patch from Redhat for CVE alert.
The way we parse the Principal (e.g., "CN=a,OU=b,O=c") from an X509 Certificate had a serious security flaw. Thanks to Redhat, Arun Babu Neelicattu, and David Jorm for notifying us, and for the patch they submitted.
2. Upgrade to Java 1.5.
Not-yet-commons-ssl now requires at least Java 1.5 to run (a.k.a. Java 5). If you really need Java 1.3 or Java 1.4 compatibility, please email the mailing list; it's not too late for us to rejig things to bring that back, but we're not going to bother unless someone actually needs it.

Changelog for not-yet-commons-ssl-0.3.13:

1. Fix bugs in AuthSSLProtocolSocketFactory and TrustSSLProtocolSocketFactory.
KeyMaterial's constructor has been checking that KeyMaterial contains at least one private key, but this assumption was invalid with these guys. The fall-back to the TrustMaterial constructor if necessary. (Wonder how long this has been broken! Oops!)
2. Upgraded from JUnit3 to JUnit4. Added some extra unit tests.

Changelog for not-yet-commons-ssl-0.3.12:

1. Avoid reverse-DNS lookups with literal IP address connections.
Based on my own investigation, InetAddress.getByAddress(String, byte[]) does not do the reverse-DNS lookup that plagues Java SSL users, so we call that whenever possible.

Changelog for not-yet-commons-ssl-0.3.11:

1. Fixed KeyStoreBuilder.
It really can handle KeyStores now where the store-password and key-password differ. It can also now handle all the things 0.3.9 couuld handle, too. Whoops. Sorry about 0.3.10, everyone.
2. KeyStoreBuilder auto-detects BouncyCastle BKS and UBER keystore types.
3. CRL checking no longer blocks forever in bad network situations (Java 5 and newer).
CRL checking was using default java.net.URL behaviour, which unfortunately can cause infinite blocking. CRL checking now waits at most 5 seconds for the CRL server to respond. Note: Only works on Java 1.5 and above.
4. Lot's more unit tests. Especially for KeyStoreBuilder.
5. Base64InputStream's default behaviour changed to DECODE. VERY SORRY!
6. PKCS8Key.getPublicKey() and PEMUtil.toPEM() methods added.

Features as of not-yet-commons-ssl-0.3.10:

1. KeyStoreBuilder broken.
Version 0.3.10 should be avoided!

Features as of not-yet-commons-ssl-0.3.9:

1. PBE is now Compatible with openssl enc -K [key] -iv [IV].
People were asking for this. See the PBE page for more details.
2. DES2 with PBE was broken.
Fixed.
3. directory.apache.org didn't write the ASN.1 code. BouncyCastle did.
Now using latest ASN.1 parsing code from BC, and attributing it properly.
4. The "ping" utility has a few more options.
For those who need more than just a "HEAD /" request. You can also set the HTTP host header, independant of the target host/ip.

Features as of not-yet-commons-ssl-0.3.8:

1. useDefaultJavaCiphers() actually works now.
When you want to allow 40 bit, 56 bit, and MD5 based SSL ciphers, use this. It was 99% functional in 0.3.7, but there was a rare situation where setting ciphers was causing SSL handshake errors.
2. PBE (password-based-encryption) improved.
PBE now has its own HTML page. Support for all of OpenSSL's PBE ciphers implemented and tested, including IDEA and RC5. (DES-X might work, but couldn't find a JCE provider that supported it). Threw in support for some additional BouncyCastle ciphers even though OpenSSL doesn't support them (cast6, gost28147, rc6, seed, serpent, skipjack, tea, twofish, xtea). Around 650 test files created to make sure PBE is working properly.
3. PBE API changed on OpenSSL.encrypt() and OpenSSL.decrypt().
The password is now char[] instead of byte[] (sorry!). Encrypt/decrypt on byte[] introduced. Encrypt/decrypt on InputStream is still available, and is properly streamed so that even extremely large files can be encrypted/decrypted.

Features as of not-yet-commons-ssl-0.3.7:

1. useStrongCiphers() used by default.
40 bit and 56 bit ciphers are now disabled by default. To turn them back on call useDefaultJavaCiphers().
2. addAllowedName() adds some flexibility to the CN verification.
Here's a code example using "cucbc.com" to connect, but anticipating "www.cucbc.com" in the server's certificate:
SSLClient client = new SSLClient();
client.addAllowedName( "www.cucbc.com" );
Socket s = client.createSocket( "cucbc.com", 443 );

This technique is also useful if you don't want to use DNS, and want to connect using the IP address.
3. SSLServer can re-use a Tomcat-8443 private key if running from inside Tomcat.
SSLClient server = new SSLServer();
server.useTomcatSSLMaterial();
4. RMI-SSL support improved.
Attempts to re-use the Tomcat-8443 private key for all RMI SSL Server sockets. Anonymous server-sockets (port 0) will always be set to port 31099. Analyzes the server certificate CN field and tries to set "java.rmi.server.hostname" to something compatible with that. Probably the only free implementation around that does a good job on the hostname verification!
5. KeyMaterial constructor blows up earlier.
If a JKS or PKCS12 file is provided that isn't going to work (e.g. no private keys), the KeyMaterial constructor throws an exception right away.
6. getSSLContext() now available to help inter-op with Java 5 SSL-NIO libraries.
Oleg has been working hard on SSL-NIO for the Apache httpcomponents library. Go check it out!
7. Fixed bug where SSLClient couldn't be used with javax.net.ssl.HttpsURLConnection on Java 1.4.x
I was wrapping the SSLSocket, but Java 1.4.x guards against that inside HttpsURLConnection and throws this exciting exception:
java.lang.RuntimeException: Export restriction: this JSSE implementation is non-pluggable.
  at com.sun.net.ssl.internal.ssl.SSLSocketFactoryImpl.checkCreate(DashoA6275)
  at sun.net.www.protocol.https.HttpsClient.afterConnect(DashoA6275)
  at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(DashoA6275)
  at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:560)
  at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(DashoA6275)
Silly Java - I'm still using your JSSE implementation, I'm just wrapping it!

Features as of not-yet-commons-ssl-0.3.4:

1.  "javax.net.ssl.keyStore" and "javax.net.ssl.trustStore"
SSLClient and SSLServer now set their default TrustMaterial and KeyMaterial from these system properties if they are present.
2.  ssl.setCheckCRL( true/false ) Note: CRL is an abbreviation for "Certificate Revocation List"
Set to true by default. If you're using SSLClient, then the remote server's certificate chain is checked. If you're using SSLServer, CRL checking is ignored unless client certificates are presented. Commons-SSL tries to perform the CRL check against each certificate in the chain, but we're not sure if we always know the entire chain.

Implementation note: To reduce memory consumption all CRL's are saved to disk using File.createTempFile() and File.deleteOnExit(). CRL's are re-downloaded every 24 hours. To reduce disk IO the "pass/fail" result of a CRL check for a given X.509 Certificate is cached using the 20 byte SHA1 hash of the certificate as the key. The cached "pass" result is discarded every 24 hours. The cached "fail" result is retained until the JVM restarts.

3.  ssl.setCheckExpiry( true/false )
Certificate expiry checking can be turned off. Turned on by default. For Java 1.4 and newer we're intercepting the CertificateException thrown by the TrustManager. But we still implemented our own expiry checking because Java 1.3 doesn't check expiry. We check every certificate in the chain, but we're not sure if we always know the entire chain.
4.  ssl.setCheckHostname( true/false )
Certificate hostname checking improved. Turned on by default for SSLClient, but turned off by default for SSLServer. If turned on for SSLServer, only applied to client certificates by checking against a reverse DNS lookup of the client's IP address. Turning on for SSLServer will probably be quite rare. We imagine that applications (such as Tomcat) will pass the client chain back up into the business layer where people can code in any kind of validation logic they like. But we put it in anyway to keep things consistent.

Support added for certificates with wildcards in the CN field (e.g. *.credential.com). Java already had this, to be fair. We broke it by accident!

s: CN=*.credential.com, OU=Domain Control Validated - RapidSSL(R), OU=See www.rapidssl.com/cps (c)05,
   OU=businessprofile.geotrust.com/get.jsp?GT27402892, O=*.credential.com, C=CA
i: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US

5.  PKCS8 support.
Support for OpenSSL "Traditional" and PKCS8 encrypted private keys added. Private keys can be RSA or DSA. See our pkcs8 page for more details.
6.  New Utility: "KeyStoreBuilder"
Command line utility converts an OpenSSL pair (private key + certificate) into a Java Keystore ("JKS") file. To see the command-line options, visit our utilities page, or just run:

java -cp commons-ssl-0.3.4.jar org.apache.commons.ssl.KeyStoreBuilder