Thanks Shawn,
There's some other new stuff too, you may have also noticed the
endpoints in the tests are IPv6 and the use of Atomic Invocation
constraints:
* IPv6 X500 Multicast (includes global announcement), or secure end to
end discovery and connectivity, it makes a lot of sense now with
global deployment of IPv6 at 30%.
* Failure atomic object serialization / marshalling, a security
enhanced re-implementation of Java Serialization, gadget attacks and
serialization attack vectors, such as million laughs attacks simply
don't work. There's no whitelist profiling required or filtering
mechanisims, instead is uses object encapsulation principles and
constructors, there's no implicit object creation or circular object
graphs, deserialization permission is granted dynamically after
authentication. One need only implement a single argument
constructor, which is passed a caller sensitive parameter which can
be passed to super class constructors, each class has it's own
private scope in an object's serial form, and doesn't have access to
parent or child class serial form. Each class validates each of
it's serial fields before it is constructed, or created. Child
classes can even create a super class instance, check superclass
invariants, calling various methods on the superclass instance,
prior to the child class creating an instance of itself.
Implementations are expected to defensively copy any mutable shared
state. Serializers are provided for collections and other java
library classes. Utility methods are provided to assist validating
invariants as well. The stream length is limited and periodical
resets must be sent by the remote end or the stream will throw an
Exception and return control to the caller. When reading an Object,
they stream reads ahead to check the type of object in the stream
matches.
* AtomicILFactory, is a JERI implementation that utilises atomic
serialization, and also provides a new way to manage codebase
annotations, rather than appending annotations in the stream, the
service is consulted for the codebase annotation and any codebase
signer certificates, these are used specifically for the service and
to dynamically grant permissions, ClassLoader's are assigned at each
Endpoint to provide class resolution for the service and it's proxy
(The ServerEndpoint's ClassLoader is a configuration concern, a
class is provided in configuration and it's ClassLoader is used for
unmarshalling. The Endpoints created are service specific. If
another service proxy (eg a Listener) is passed to a service, it
will be marshalled separately and have it's own ClassLoaders
assigned at each Endpoint with it's own unique marshalling streams,
it's service proxy will only be unmarshalled after it's service has
been authenticated, the codebase annotation received, permission to
deserialize granted and a ClassLoader assigned, then the proxy is
unmarshalled into it's assigned ClassLoader. Codebase annotations
become a configuration concern for each service and each service
maintains separate class resolution visibility. This addresses
codebase annotation loss issues, every time a proxy is remarshalled,
it's object graph is marshalled independently and the service is
consulted for it's codebase annotation. Additionally, any
constraints applied to a service proxy will be applied to any other
proxy passed to it as a parameter, for example other services such
as Listeners, at least until the remote endpoint applies a new set
of contraints. A provider interface allows customization of
codebase annotation and ClassLoader provisioning.
* Codebase Signer Certificates can be self signed, they are granted
permission dynamically, this is a convenient way for the service to
allow the client to ensure it's interacting using it's intended
codebase, provided it trusts the client (and authenticated it).
* New constraints to ensure a proxy uses failure atomic serialization.
* ProxyPreparer is still used, however ProxyTrust is no longer
required (it didn't work anyway, it checked too late).
The aim is to allow services to go global and be pervasive.
Some more info about discovery (note the codebase and certificates
included for the registrar proxy), the proxy is also unmarshalled using
failure atomicity, although it is not mentioned in the documentation:
https://pfirmstone.github.io/JGDMS/jgdms-discovery-providers/apidocs/org/apache/river/discovery/x500/sha512withecdsa/package-summary.html
https://pfirmstone.github.io/JGDMS/jgdms-discovery-providers/apidocs/org/apache/river/discovery/ssl/sha512/package-summary.html
https://pfirmstone.github.io/JGDMS/jgdms-discovery-providers/apidocs/org/apache/river/discovery/ssl/sha224/package-summary.html
Cheers,
Peter.
On 6/2/2020 2:58 PM, Shawn Ellis wrote:
Nice! I wasn’t expecting that River would support stateless TLS too.
The other improvements look very useful. Especially the support for
TLS connections with RemoteEvents.
On Jun 2, 2020, at 12:41 PM, Peter Firmstone
<peter.firmst...@zeus.net.au <mailto:peter.firmst...@zeus.net.au>> wrote:
Hi Shawn,
Confirming I have stateless TLS working now.
It required a few more changes, but nothing substantial, it builds
other work I've been chipping away at.
Note this is a fork of River with a significant amount of work done,
this work will be donated back to River:
* QA Test suite has a CertificateAuthority that signs test X509
certificates, (generated every time the suite is built).
* Anon TLS connections are not supported (because MITM attacks),
clients and servers are logged in and have signed certs.
* RemoteEvent's are called with the logged in Subject, enabling TLS
connections with both the server and client logged in. River
doesn't support this currently as calls are made without the
login context.
* Phoenix Activation is running, using TLS Endpoints, the RMI
Registry that Phoenix uses is also using RMI TLS Endpoints.
* The latest TSLv1.3 ciphers are supported.
* Constraints have changed to reflect the current state of security.
<SNIP>
On 6/2/2020 11:24 AM, Peter Firmstone wrote:
Just confirming I've found failing tests, still working on it....
On 6/1/2020 10:12 PM, Peter Firmstone wrote:
Thanks Shawn,
I've been testing on JDK 11 and 13 recently, I've just downloaded
JDK 14.0.1
I ran the qa suite lookupservice tests with JSSE enabled (Using qa
suite on JGDMS which is working with JSSE).
Confirmed the tests hang and fail.
Looked at JDK-8242008
Notably: "SSLSessions obtained after an initial connection may
return a null value when its getSessionContext() method is called."
Worked around this below by obtaining local certificate for valid
session.
Ran tests again.
Confirming tests are now passing... Will run some more.
Regards,
Peter.
/**
* Returns the principal that the server used to authenticate
for the
* specified session. Returns null if the session is not found
or if the
* server did not authenticate itself.
*/
X509Certificate getServerCertificate(SSLSession session) {
X509Certificate cert = null;
synchronized (credentialCache) {
if (sslSessionContext.getSession(session.getId()) != null) {
Object val = credentialCache.get(
Utilities.getKeyAlgorithm(session.getCipherSuite()));
if (val instanceof X500PrivateCredential) {
X500PrivateCredential cred = (X500PrivateCredential) val;
if (!cred.isDestroyed()) {
cert= cred.getCertificate();
}
}
}
}
if (cert == null && session.isValid()){ //Stateless
connection.
Certificate [] certs = session.getLocalCertificates();
if (certs[0] instanceof X509Certificate) {
cert = (X509Certificate) certs[0];
}
}
return cert;
}
On 6/1/2020 5:41 PM, Shawn Ellis wrote:
Hello,
I've seen a TLS problem with JDK 14.0.1 and Apache River 3.0 that
I want to share in case someone else runs into the same issue. A
client will receive a "Contraints are not supported” error when
attempting to perform a reggie lookup when using TLS. The call to
ServerAuthManager.getServerCertificate() returns null instead of
the server certificate because the sslSessionContext doesn't have
any session ids.
ServerAuthManager.java:113
if (sslSessionContext.getSession(session.getId()) != null) { //
sslSessionContext.getSession() returns null with JDK 14.0.1
// returns the server certificate
}
The workaround is to use
-Djdk.tls.server.enableSessionTicketExtension=false on the server
or use JDK 15 according to the OpenJDK bug report:
https://bugs.openjdk.java.net/browse/JDK-8242008
<https://bugs.openjdk.java.net/browse/JDK-8242008>
