Re: Toward a 2.0 GA
On 17/01/2019 15:14, Shawn McKinney wrote: On Jan 16, 2019, at 3:54 PM, Emmanuel Lécharny wrote: 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) Hi Emmanuel, Thinking out loud here so forgive the naive comment, but shouldn’t the server use the a. default Java keystore (if found), or b. what’s passed to it, and only if not (a or b) c. create a new? The server is currently trying to load a keystore that is passed to it as a parameter, and if not, it creates an internal keystore that fetches the admin user Certificate. There is no such thing as a 'default java keystore', unless you mean the one you manage using keytool - but then you have to tell the app where this keystore is -. Correct me if I'm wrong. The rational, when this part of the server was implemented, was to make dead simple to have TLS working: wze create the certificate 'on the fly', and store it in a keystore that is wrapped around the server itself, for the storage. Somehow, it makes sense. There is even an extended operation that allows a client to create a certificate (CertGenerationRequest). So passing an existing Keystore is a way to use signed certificates, instead of self-signed ones generated by teh server at startup. Funny enough, you can also reconfigure the server to use a signed certificate without using a keytstore, but it's a 2 steps init : - first start the server as is - change the admin certificate/public/private key to replace them with the signed one - restart the server In any case, I do think we have to have a serious conversation about all those aspects which are critically important from a security PoV !!! FTR, I'm checking the code provided by Daniel Fisher (DIRAPI-72) which point to the code that can be used to verify the server name on the startTLS extended operation. It's based on the sun.security.util.HostnameChecker class.
Re: Toward a 2.0 GA
> On Jan 16, 2019, at 3:54 PM, Emmanuel Lécharny wrote: > > 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) Hi Emmanuel, Thinking out loud here so forgive the naive comment, but shouldn’t the server use the a. default Java keystore (if found), or b. what’s passed to it, and only if not (a or b) c. create a new? Thanks, —Shawn
Re: Toward a 2.0 GA
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 ?
Re: Toward a 2.0 GA
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. DIRAPI-301 you already fixed, so now the default JVM trust manager is just, thanks for that. The hostname verification should also be implemented, I agree. In Studio that is implemented [1] by using DefaultHostnameVerifier from Apache HTTP client library which is anyway included in Eclipse. This class does not exacly what is defined in the LDAP RFC but better than nothing. If we implement our own verifier in the LDAP API we can change it. [1] https://github.com/apache/directory-studio/blob/remove-jndi-provider-and-jndi-layer/plugins/connection.core/src/main/java/org/apache/directory/studio/connection/core/io/StudioTrustManager.java#L157 > To be fixed for 2.0GA > - > DIRAPI-136, Add the TLS closure alert support in the API > DIRAPI-149, LdapNetworkConnection should not create user-Threads > DIRAPI-202, Can't get LdapConnectionTemplate working > DIRAPI-237, Make the API threadsafe > DIRAPI-299, Unable to change expired password unless logging in as admin. > DIRAPI-300, Weird batchResponse when batchRequest contains grammar error > DIRAPI-320, ClassCastException on Objects.equals(Value,Value) for > userPassword attribute Sounds good. I don't plan beyond that :)
Toward a 2.0 GA
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. To be fixed for 2.0GA - DIRAPI-136, Add the TLS closure alert support in the API DIRAPI-149, LdapNetworkConnection should not create user-Threads DIRAPI-202, Can't get LdapConnectionTemplate working DIRAPI-237, Make the API threadsafe DIRAPI-299, Unable to change expired password unless logging in as admin. DIRAPI-300, Weird batchResponse when batchRequest contains grammar error DIRAPI-320, ClassCastException on Objects.equals(Value,Value) for userPassword attribute Postponed to 3.0 DIRAPI-61, We don't support referral chasing on the API DIRAPI-73, Creating new schema and injecting schema elements into it DIRAPI-104, Schema registries are not getting updated after adding a new AT to an ObjectClass entry present in the Schema partition DIRAPI-111, Move some Subentry classes from core-API DIRAPI-115, LdifEntry should expose methods to manipulate attributes. DIRAPI-179, Referral Hop Count DIRAPI-209, Failover configuration for 2 ldap servers: master and slave DIRAPI-222, Make the LdifReader accept changes *and* entries in the same file DIRAPI-256, We need to implement the SASLPrep RFC (RFC 4013) DIRAPI-281, Unable to connect LDAP server via proxy DIRAPI-327, Add stream support to Entry and Attribute Long term issues DIRAPI-116, Review the API to have the method trhow meaningful exceptions DIRAPI-216, Improvements in OSGi tests DIRAPI-259, Add support for some missing Microsoft AD controls and extended operations: will be added on the fly, when needed. I would add I want to review the way we manage schema elements. We have two flavors of AT, OC and MR: a mutable one, and a immutable one. This does not make a lot of sense. I'd rather have immutable elements, with a factory to create new ones. I still have to investigate the impact of such change, it will be covered in a coming mail. In the mean time, please feel free to comment, give your input about this list of JIRA. I'd like to be able to cut the milestone next week, if possible. Many thanks !
