Introduce LiteSSLAcceptor

[yaronyg]

This is a version of the SSLAcceptor class used by TJWS to handle a few different things. It would be implemented by inheriting from SSLAcceptor and implementing LiteAcceptor per #27.

But there are a few other things I would also like it to do. Specifically:

• So SSLAcceptor.ARG_PORT and Server.ARG_PORT aren't the same. This actually makes sense because there is an acceptor for TJWS that simultaneously supports HTTPS and HTTP. But LiteSSLAcceptor would only support HTTP over SSL. So I want to set the logic so that if Server.ARG_PORT is set but SSLAcceptor.ARG_PORT isn't then we will use Server.ARG_PORT.
• The same situation exists with SSLAcceptor.IFADDRESS and Serve.ARG_BINDADDRESS. I want to use the same solution.

[jessliu]

We're interested in seeing a PR for this, coordinate with Traun in regards to priority

[yaronyg]

Jessica, #28 is only needed if we are going to implement #25 and #26. Otherwise the existing SSLAcceptor built into TJWS should work just fine. I only came up with the custom version to clean up some of the arguments (but the existing ones work) and to provide the hooks to enable #25 and #26.

[jessliu]

Hi @yaronyg apologies for the brusque nature of the comment, we were aggressively bug scrubbing through all three repos for GA.

Okay, good feedback. We had left this issue open because we had some other security concerns. @tleyden in light of Yaron's comment do you want to reconsider the priority of this issue?

[tleyden]

@yaronyg A few questions on the existing SSLAcceptor built into TJWS:

• Do you have a simple example of using this?
• Is it possible to layer access control on this by requiring a certain certificate in order to connect? Eg, can other apps be locked out?

[yaronyg]

Code Sample

Actually CouchBase Lite is missing something needed to use different TJWS acceptors, that's in #24. Without that there is no way to pass in to TJWS the properties needed to tell it which acceptor it should use and how it should be configured. So minimally if you want to support SSL you need #24.

The following is an adaption of the code I use now. It's not going to be exactly correct since I'm hand editing out a bunch of stuff but it will give you the idea.

try {
    manager = new Manager(filesDir, new ManagerOptions());
} catch (CouchbaseLiteException e) {
    Log.error("Manager failed to start", e);
    return;
}

Properties tjwsProperties = new Properties();
tjwsProperties.setProperty(Serve.ARG_ACCEPTOR_CLASS, TjwsSslAcceptor);
tjwsProperties.setProperty(SSLAcceptor.ARG_KEYSTORETYPE, ThaliCryptoUtilities.PrivateKeyHolderFormat);
tjwsProperties.setProperty(SSLAcceptor.ARG_KEYSTOREFILE, ThaliCryptoUtilities.getThaliKeyStoreFileObject(filesDir).getAbsolutePath());
tjwsProperties.setProperty(SSLAcceptor.ARG_KEYSTOREPASS, new String(ThaliCryptoUtilities.DefaultPassPhrase));

tjwsProperties.setProperty(SSLAcceptor.ARG_CLIENTAUTH, "true");

tjwsProperties.setProperty(Serve.ARG_BINDADDRESS, DefaultThaliDeviceHubAddress);

cblListener = new LiteListener(manager, port, tjwsProperties);

cblListener.start();

Also note that my constructor for LiteListener is based on other issues I have filed. But whatever. I think you get the idea.

It all boils down to pass a bunch of name/value pairs in a standard Java Properties object that are then fed to TJWS.

Security

TLDR - Yes, it's possible. But it's hard and too restrictive.

It would be challenging to use an acceptor as a way to keep out unwanted clients in all but the most trivial cases. The reason is that the way TJWS creates an acceptor is by taking a class name as a string and then using reflection to create a new instance of that class. So how would you tell the acceptor what client certs to accept? They would have to be hard coded into the class or you would have to create a new instance of Manager inside of the acceptor in order to get access to the local DBs and look things up.

Also in the case of Thali we have different ACLs for different users on different databases. So if we were going to do access control in the acceptor we would also have to put in code to parse requests in order to figure out what ACL to apply. Do we really want the same parsing code in a SSL acceptor and in router.java?

This all seems way too complicated and too likely to fail. What I did in Thali was use #25 to expose standard SSL connection information and then #27 to make the HTTP and HTTPS acceptors expose the interface from #25. Then my code from https://github.com/couchbase/couchbase-lite-android-core/issues/44 would be able to use the SSL data to directly get to the client certs and validate them against the ACL store. This all happened up in router.java.

But I do recognize that a slightly cleaner solution would be to implement https://github.com/couchbase/couchbase-lite-android-core/issues/39 and have my authorization code use that. But whatever, it's just class wrapping at that point.