directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <elecha...@gmail.com>
Subject Re: Toward a 2.0 GA
Date Wed, 16 Jan 2019 21:54:25 GMT

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 ?



Mime
View raw message