On 11/01/2019 20:03, Stefan Seelmann wrote:
On 1/11/19 11:09 AM, Emmanuel Lécharny wrote:
Hi guys,
I'm currently checking all the pending JIRAs, trying to evaluate those
that need to be closed in the coming release, those that are invalid,
and those that need to be postponed.
While doing that, I see there are quite a few important ones related to
TLS and security checks that probably need to be addressed before we cut
a 2.0 GA (which means the next release with still be a milestone).
Here are the JIRA I'm interested in, ordered accordingly to some release
roadmap (mine ;-) :
To be fixed for the next milestone
----------------------------------
DIRAPI-69, API does not allow StartTLS hostname verification
DIRAPI-72, Provide a default TrustManager for hostname verification to
comply with RFC 2830 Section 3.6
DIRAPI-298, Inconsistent SASL bind API : add the missing bindGssApi()
method
DIRAPI-299, Unable to change expired password unless logging in as admin.
I promised a mail regarding TLS some while ago but never wrote it. But
that are the points.
Here are some thoughts about Certificate handling in both the server and
the API:
Server
------
The Server, when started, will try to load the Keystore content:
o If there is no provided KeyStore file, the server will use create its
own Keystore, based on the default SUN provider.
o Otherwise, the server will try to load the provided KeyStore, using
the paswword that has to be provided too. There are two parameters used
to configure the server : ads-keystoreFile that will contain tha path to
the KeyStore and ads-certificatePassword (which should most certainly be
renamed ads_keyStorePassword)
NOTE: there is no test in the server that check the use of an external
keystore
Internal KeyStore
-----------------
To make it simple for the user, the server implements its own KeyStore
which contains one single KeyPair. The implementation is done through
the CoreKeyStoreSpi class.
Client
------
Validating the server means we have a copy of the CA locally in a
KeyStore. We don't have that by default. We have options here :
- don't validate the server certificate (this is the default)
- use a local KeyStore. It's possible, as soon as we set the connection
config to use a Trustmanager that leverage this keyStore
- we could also use the file containing the CA certificate, leaving the
plumbing to the API (ie creating a in-memory KeyStore).
I do think we must implement one of the 2 last options - or even both of
them -. We can reuse what Fortress is using, that would cover the second
option. This should also be the default when using TLS on the client side.
We should also make it so that the client can be configured to validate
the server certificate with various options :
- never: don't verify the server certificate
- allow: check the server certificate if it's provided, but don't block
if it's not verified
- try: check the server certificate if provided, and if so, terminate
the session if the verification failed
- demand: check the serrver certificate and terminate the session if
it's not sent or if it's invalid
I guess that would be for a future version.
Another thing that need to be fixwed is a mean to verify the server
HostName when using the startTLS extended operation. This will take a
bit of time, I would suggest to do that for 2.0 GA.
Anyway, at this point, I'd like to get the API milestone released, in
order to be able to release ApacheDS (and probably Studio and Fortress
too). Just because there are many fixes and improvements in it.
We have a 2.0 GA pending, that should come shortly after, so I think we
are fine with the milestone.
WDYT ?
