From api-return-1016-archive-asf-public=cust-asf.ponee.io@directory.apache.org Wed Jan 16 22:54:39 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 747A7180645 for ; Wed, 16 Jan 2019 22:54:38 +0100 (CET) Received: (qmail 28124 invoked by uid 500); 16 Jan 2019 21:54:37 -0000 Mailing-List: contact api-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: api@directory.apache.org Delivered-To: mailing list api@directory.apache.org Received: (qmail 28112 invoked by uid 99); 16 Jan 2019 21:54:36 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Jan 2019 21:54:36 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 71C10D0BB0 for ; Wed, 16 Jan 2019 21:54:36 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.203 X-Spam-Level: X-Spam-Status: No, score=-0.203 tagged_above=-999 required=6.31 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id pgy7xc3d6qMS for ; Wed, 16 Jan 2019 21:54:35 +0000 (UTC) Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id A77B15F35B for ; Wed, 16 Jan 2019 21:54:34 +0000 (UTC) Received: by mail-wr1-f54.google.com with SMTP id c14so8786561wrr.0 for ; Wed, 16 Jan 2019 13:54:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=WdJ/eOF2k59zdrjyHLuuMYLxSR5JKTjjHajOIP9PKVw=; b=QA2WNYW7GMy5xp051ny42EJX1ChFOJYotkLFznKRjpjP04DQfYMMPKtyHnpGvU2Giq EH682YvU68CW3lthCLcrGBzmLPNd03m9wGs+WDT0ZENuOAYRw1llNpcVddOJXClHr+4W L0rjRGaejM/OJ0fXTBGaqjQuYJ+VhCDsW+6SjRfHJ5F08pBnNehEXXMXPsO1SORbST68 8M7Wop6La1jBN7PEwp+WQi+IMLDPEOEM+K8G+P4yPEfJuqH64LH2X/fXE+8wrJoxJA6S Yd6xl540mQn2gRw1iBX48VJlervit9R0yh+P2IkbkNGHjPG6VSjZs9yt+CLKAqRaqbeN c2Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=WdJ/eOF2k59zdrjyHLuuMYLxSR5JKTjjHajOIP9PKVw=; b=IYsN8/SaR0cGdYz8Uf/N7IkImaq695zsHVUxrIEz4nIzgLCBeAplCLBsNj0VlSKhZm 2m+4qox3RAsqQVCKe0/Utgu9ncuDLo+kCoAJ0fMaoeVzJRBZ8O0d15MKpjeonx+hGKg7 nFqj657OHxJhac4/4/27oEDQilGib0LtDfnj20f9wsnfEijo2taBK1TxrCp1WxOvwvzB XwVFgEyqniV2YXTb9z06ZMIXc1K80bgMZ3cO0H9Nvfow7VNk/IHT3unT3FW9EQC7XDAy 9nH2aHt+b4FHK4oDl3+Y03QBTFFFurHBGGQ9Dn9BBd9y1PUZpAZ7qwoT4OQ0In/1ltcH Nrww== X-Gm-Message-State: AJcUukecWTcIDTPPw7SQjE9ol+55vEpgs+WOHMLprNbTvglHb7aZeXCy ZU6rD2djDiGSB+xZwODZx2TgoQzr X-Google-Smtp-Source: ALg8bN4zbQ8nkoyG97weLRCEBFT1wI3RU6PG43YvgUR+d0F6NoqO3t+A08oq444bC2oDcqEm2qBJhg== X-Received: by 2002:a5d:4382:: with SMTP id i2mr9213770wrq.172.1547675667539; Wed, 16 Jan 2019 13:54:27 -0800 (PST) Received: from [192.168.8.1] ([109.94.60.193]) by smtp.gmail.com with ESMTPSA id a12sm74669664wrm.45.2019.01.16.13.54.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Jan 2019 13:54:26 -0800 (PST) Subject: Re: Toward a 2.0 GA To: api@directory.apache.org References: <8854975b-ee45-7da1-88c6-2c8e7b2f3c56@gmail.com> <2a233657-877a-db29-b956-0841efc22eb2@stefan-seelmann.de> From: =?UTF-8?Q?Emmanuel_L=c3=a9charny?= Message-ID: <6b5f20f0-2bbe-a347-97e9-555a75ad4e26@gmail.com> Date: Wed, 16 Jan 2019 22:54:25 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <2a233657-877a-db29-b956-0841efc22eb2@stefan-seelmann.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US 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 ?