From dev-return-13539-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Tue Jan 11 19:13:42 2005 Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 67693 invoked from network); 11 Jan 2005 19:13:42 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 11 Jan 2005 19:13:42 -0000 Received: (qmail 81669 invoked by uid 500); 11 Jan 2005 19:13:41 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 81626 invoked by uid 500); 11 Jan 2005 19:13:41 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 81611 invoked by uid 99); 11 Jan 2005 19:13:41 -0000 X-ASF-Spam-Status: No, hits=0.4 required=10.0 tests=DNS_FROM_RFC_ABUSE X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from sinclair.provo.novell.com (HELO sinclair.provo.novell.com) (137.65.81.169) by apache.org (qpsmtpd/0.28) with ESMTP; Tue, 11 Jan 2005 11:13:40 -0800 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Tue, 11 Jan 2005 12:13:39 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.4 Beta Date: Tue, 11 Jan 2005 12:13:28 -0700 From: "Brad Nicholes" To: Cc: Subject: Start_tls failure detection Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N >This is the app's problem though - if starttls fails it will return an >error, and it's normal on error to give up, which is the expected >behaviour. If the app chooses to ignore the error and go on with the >insecure connection, then it was the app's choice - it may have wanted >to do so. I think it should be pretty clearly documented that this is >the case though. If this is the apps problem then we need to do some work on mod_authnz_ldap because it isn't pay attention to the failure and allowing the authentication to happen anyway. Brad >>> Graham Leggett Tuesday, January 11, 2005 11:08:51 AM >>> Brad Nicholes wrote: > One thing that bothered me while I was testing this. Even if the > start_tls fails, authentication still succeeds and content is returned. > Since we are assuming forced TLS, authentication should fail if the TLS > connection fails. It probably shouldn't be allowed to fall back to > unsecure. This is the app's problem though - if starttls fails it will return an error, and it's normal on error to give up, which is the expected behaviour. If the app chooses to ignore the error and go on with the insecure connection, then it was the app's choice - it may have wanted to do so. I think it should be pretty clearly documented that this is the case though. Regards, Graham --