Bug report for Apache httpd-2 [2014/11/02]

2014-11-02 Thread bugzilla
+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=Critical  REG=Regression  MAJ=Major   |
| |   |   MIN=Minor   NOR=NormalENH=Enhancement TRV=Trivial |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
| 7483|Ass|Enh|2002-03-26|Add FileAction directive to assign a cgi interpret|
| 8713|Inf|Min|2002-05-01|No Errorlog on PROPFIND/Depth:Infinity|
| 8867|Opn|Cri|2002-05-07|exports.c generation fails when using a symlink to|
|10747|New|Maj|2002-07-12|ftp SIZE command and 'smart' ftp servers results i|
|11294|New|Enh|2002-07-30|desired vhost_alias option|
|11580|Opn|Enh|2002-08-09|generate Content-Location headers |
|12033|Opn|Nor|2002-08-26|Graceful restart immidiately result in [warn] long|
|12680|New|Enh|2002-09-16|Digest authentication with integrity protection   |
|13599|Inf|Nor|2002-10-14|autoindex formating broken for multibyte sequences|
|13661|Ass|Enh|2002-10-15|Apache cannot not handle dynamic IP reallocation  |
|14104|Opn|Enh|2002-10-30|not documented: must restart server to load new CR|
|14496|New|Enh|2002-11-13|Cannot upgrade any version on Windows. Must uninst|
|14922|Inf|Enh|2002-11-28|target is currently hardcoded to 'apache2'  |
|15719|Inf|Nor|2002-12-30|WebDAV MOVE to destination URI which is content-ne|
|16761|Inf|Nor|2003-02-04|CustomLog with pipe spawns process during config  |
|16802|New|Enh|2003-02-05|Additional AllowOverride directive Restrict |
|16811|Ass|Maj|2003-02-05|mod_autoindex always return webpages in UTF-8.|
|17107|New|Min|2003-02-16|Windows should not install printenv   |
|17114|New|Enh|2003-02-17|Please add strip and install-strip targets to Make|
|17244|Ass|Nor|2003-02-20|./configure --help gives false information regardi|
|17497|Opn|Nor|2003-02-27|mod_mime_magic generates incorrect response header|
|18325|New|Enh|2003-03-25|PAM support for suEXEC|
|18334|Inf|Cri|2003-03-25|Server crashes when authenticating users against L|
|18497|New|Min|2003-03-30|configure --help gives wrong default for sysconfdi|
|19043|New|Min|2003-04-15|Interesting interaction between cern_meta module a|
|19670|New|Enh|2003-05-05|content type header supplied upon PUT is thrown aw|
|20036|Ass|Nor|2003-05-19|Trailing Dots stripped from PATH_INFO environment |
|21253|New|Nor|2003-07-01|Mime magic doesn't continue if type is specifed fo|
|21260|New|Nor|2003-07-02|CacheMaxExpire directive not enforced !   |
|21533|Ass|Cri|2003-07-11|Multiple levels of htacces files can cause mod_aut|
|22005|Ver|Nor|2003-07-30|Win32: Help I'm Stuck! menu item leads to dead e|
|22138|Inf|Cri|2003-08-05|Webdav is not preccessing special chars right.|
|22237|New|Enh|2003-08-08|option to disable ServerSignature on index pages  |
|22484|Opn|Maj|2003-08-16|semaphore problem takes httpd down|
|22686|Opn|Nor|2003-08-25|ab: apr_poll: The timeout specified has expired (7|
|22898|Opn|Nor|2003-09-02|nph scripts with two HTTP header  |
|23167|Inf|Cri|2003-09-14|--enable-layout never goes to apr apr-util|
|23181|New|Nor|2003-09-15|Status 304 (Not modified) and chunking leads to an|
|23238|New|Cri|2003-09-18|non-async-signal-safe operations from signal handl|
|23330|New|Enh|2003-09-22|Enhance ApacheMonitor to view and control Tomcat s|
|23911|Opn|Cri|2003-10-18|CGI processes left defunct/zombie under 2.0.54|
|24031|New|Enh|2003-10-23|Passphrase protected private key in SSLProxyMachin|
|24095|Opn|Cri|2003-10-24|ERROR Parent: child process exited with status 32|
|24243|New|Enh|2003-10-30|mod_autoindex enhancement ('IndexIgnoreRemove' opt|
|24890|Opn|Nor|2003-11-21|Apache config parser should not be local aware ( g|
|25014|New|Enh|2003-11-26|A flexible interface for mod_log_config   |
|25201|New|Enh|2003-12-04|Provide Cache Purge operation |
|25240|Inf|Enh|2003-12-05|SSL Library Error: 336105671 logged as information|
|25435|New|Enh|2003-12-11|sethandler and directoryindex not playing nice|
|25469|Opn|Enh|2003-12-12|create AuthRoot for defining paths to auth files  |
|25484|Ass|Nor|2003-12-12|Non-service Apache cannot be stopped in WinXP |

Re: Older clients stopped working after server disabled SSLv3

2014-11-02 Thread Kaspar Brand
On 01.11.2014 14:46, Yann Ylavic wrote:
 There is still that a client handshaking with a SSLv2Hello (by using
 SSLv23_client_method()) is likely to accept SSLv[23] protocols (unless
 using SSL_OP_NO_SSLv[23] explicitly like today's mod_ssl, but it's
 probably not the case for legacy clients), so MITM attacks on SSLv2
 for example might still be possible.

Protecting broken clients from MITM attacks is not within mod_ssl's
power (nor is it really its business)... the only thing we can do server
side is to refuse negotiating a protocol version lower than TLS 1.0.

The badness of SSLv3 as a consequence of Poodle is probably also
somewhat overstated, in particular when taking into account that TLS 1.0
isn't really immune to this kind of padding problem, see this thread:

https://www.ietf.org/mail-archive/web/tls/current/msg14058.html

 But is openssl-1.x's TLSv1_server_method() acting differently than
 0.9.8's one with regard to SSLv2Hello?

No, it's the same in both versions. Meanwhile I found that there's
actually a subtle difference between 2.2 and 2.4: this change here (from
2005 already) -

https://svn.apache.org/viewvc?view=revisionrevision=r264621

was never backported to 2.2, but made its way into 2.4, with the
following impact on mod_ssl:

- when httpd/mod_ssl 2.2 is compiled/run with OpenSSL 0.9.8, all -SSLv2
-SSLv3 does allow SSLv2 compatible client hellos

- when httpd/mod_ssl 2.4 is compiled/run with OpenSSL 0.9.8, all
-SSLv3 does *not* allow SSLv2 compatible client hellos

In both cases, all -SSLv2 -SSLv3 or all -SSLv3 with OpenSSL 0.9.8
actually amount to TLSv1, but due to the differences in the
ssl_engine_init.c:ssl_init_ctx_protocol() code between 2.2 and 2.4, the
resulting behavior isn't the same (as for 2.2, SSLv23_server_method() is
chosen, while for 2.4, it's TLSv1_server_method()). My test from
yesterday was with 2.2.29 compiled against OpenSSL 1.0.1, in which case
even setting SSLProtocol TLSv1 won't reject SSLv2 compatible client
hellos.

 The fact is that several today's clients (probably legacy/heavy) do
 support TLSv1 easily by using SSLv23_client_method() (and let the
 linked openssl do the right thing) since a while, and it's not always
 an option to modify these clients, and no option at all when you are a
 httpd admin...

All we currently know (from the message starting this thread) is

 we noticed, that curl itself and libcurl-using programs (such as git) stopped
 working on some of the (older) systems -- such as RHEL5 -- when invoked 
 against
 the https-URLs pointing at the reconfigured servers.

so it's still quite unclear to me what specific issue we are trying to
address (and how common this is).

 Unless we consider/claim these clients are unsafe per se, and/or
 require openssl = 1.0 for mod_ssl, I don't see why we should prevent
 them from connecting to httpd configured with ALL -SSLv3.

IMO, it's more the question of how much tweaks we want to add to mod_ssl
to get OpenSSL behave with regard to supporting SSLv2 compatible client
hellos. If OpenSSL had an official API for enabling/disabling this
setting for the TLS 1.* protocols, then I would be more supportive of
this idea. If we have to rely on implicit OpenSSL behavior in the end,
then it feels more like a hack to me.

Kaspar


Re: [Patch] mod_ssl SSL_CLIENT_CERT_SUBJECTS - access to full client certificate chain

2014-11-02 Thread Kaspar Brand
On 01.11.2014 13:41, Graham Leggett wrote:
 The trouble with doing that is that it makes life really difficult to
 match arbitrary certificate chains - you need to know in advance how
 many certs are in each chain, and you need to perform a lot of
 messing about to perform a match, and to ensure the subjects are in
 the right order.

Assuming that mod_ssl exported the subject DNs as SSL_CLIENT_S_DN_0,
SSL_CLIENT_S_DN_1 etc., what would be left to the application is
assembling them properly (by prepending name= and inserting comma
separators) to get the string you're looking for. Seems fairly
straightforward IMO, and shouldn't be too complex to code in the
application.

 The use case this solves is that I want to uniquely identify a
 certificate and store that identity in an LDAP directory.

I'm not in the position of making a judgement about the fitness of the
suggested approach to your use case, of course (that's your call), but
let me add that an X.509 certificate isn't uniquely identified by the
subject DNs of its certification path. Uniqueness of an X.509
certificate is ensured through its (issuer DN, serial number) tuple.
Certification paths (and hence the suggested SSL_CLIENT_CERT_SUBJECTS
string) may change when cross-certified CAs are added to the mix, see
e.g. RFC 4158.

 The format chosen is the subjects of the certs encoded as RFC2253,
 which are turned into a DN that is in turn RFC2253 encoded again. The
 result is therefore still a valid DN, and so can be stored in any DN
 formatted field in LDAP. This works nicely with 389ds.

I don't dispute that such a string can be stored in any DN formatted
field in LDAP, but consider the use of the name RDN (OID 2.5.4.41)
fairly nonstandard. X.520 defines Name as the attribute supertype
from which string attribute types typically used for naming may be
formed (and string attribute types referring to things like
commonName, surname etc.). distinguishedName (2.5.4.49) would be more
appropriate, though it isn't really meant for use as an RDN attribute
type (but an attribute for specifying the name of an object in an
X.500 DIT).

 In terms of separating them, simply unpack the outer DN as per
 RFC2253, leaving you with the inner subject DNs. In practise you’re
 unlikely to want to separate them, instead you want to say “I want to
 trust this specific certificate issued by this specific CA”. Back in
 time matching the issuer was enough, but as soon as intermediate
 certs came along it became significantly more difficult to do.
 
 (Having said the above I don’t disagree that the _n variables could
 be useful, it’s just that they don’t solve the use case I am
 facing).

My concern with the proposed SSL_CLIENT_CERT_SUBJECTS variable is that
it hardcodes a specific use case instead of adding a generic way to
retrieve the subject DNs of the complete certification path. The latter
is what should be implemented in mod_ssl, while constructing
SSL_CLIENT_CERT_SUBJECTS (or similar stuff) should be done in the
application, IMO.

Kaspar


Re: [Patch] mod_ssl SSL_CLIENT_CERT_SUBJECTS - access to full client certificate chain

2014-11-02 Thread Graham Leggett
On 02 Nov 2014, at 12:07 PM, Kaspar Brand httpd-dev.2...@velox.ch wrote:

 Assuming that mod_ssl exported the subject DNs as SSL_CLIENT_S_DN_0,
 SSL_CLIENT_S_DN_1 etc., what would be left to the application is
 assembling them properly (by prepending name= and inserting comma
 separators) to get the string you're looking for. Seems fairly
 straightforward IMO, and shouldn't be too complex to code in the
 application.

Currently the application in this case is mod_authnz_ldap. While it is possible 
to build a complex expression to match a series of DNs, you are limited in 
knowing the length of the chain in advance, and in my case that isn’t possible 
- chains may be of arbitrary length.

 I'm not in the position of making a judgement about the fitness of the
 suggested approach to your use case, of course (that's your call), but
 let me add that an X.509 certificate isn't uniquely identified by the
 subject DNs of its certification path. Uniqueness of an X.509
 certificate is ensured through its (issuer DN, serial number) tuple.
 Certification paths (and hence the suggested SSL_CLIENT_CERT_SUBJECTS
 string) may change when cross-certified CAs are added to the mix, see
 e.g. RFC 4158.

The problem I am trying to solve is that I trust both CA1 and CA2 to issue 
certificates, but I don’t trust CA2 not to (accidentally or purposefully) issue 
a certificate with the same issuer as CA1. As a result I want to store a record 
of the full sequence of DNs all the way to the root.

Back when CAs were one level deep the issuer was enough, but with arbitrary 
certificate chains this isn’t possible any more.

In other words, you may come in if a) your cert validates to any trusted 
anchor, and b) your cert is issued by a specific pre-agreed trust anchor.

 I don't dispute that such a string can be stored in any DN formatted
 field in LDAP, but consider the use of the name RDN (OID 2.5.4.41)
 fairly nonstandard. X.520 defines Name as the attribute supertype
 from which string attribute types typically used for naming may be
 formed (and string attribute types referring to things like
 commonName, surname etc.). distinguishedName (2.5.4.49) would be more
 appropriate, though it isn't really meant for use as an RDN attribute
 type (but an attribute for specifying the name of an object in an
 X.500 DIT).

Good point, let me change that.

Regards,
Graham
—



Re: svn commit: r1622450 - /httpd/httpd/trunk/support/ab.c

2014-11-02 Thread Yann Ylavic
Hi,

On Thu, Sep 4, 2014 at 12:52 PM,  jkal...@apache.org wrote:
 Author: jkaluza
 Date: Thu Sep  4 10:52:24 2014
 New Revision: 1622450

 URL: http://svn.apache.org/r1622450
 Log:
 ab: increase request and response header size to 8192 bytes,
 fix potential buffer-overflow in Server: header handling.

 Modified:
 httpd/httpd/trunk/support/ab.c

 Modified: httpd/httpd/trunk/support/ab.c
 URL: 
 http://svn.apache.org/viewvc/httpd/httpd/trunk/support/ab.c?rev=1622450r1=1622449r2=1622450view=diff
 ==
 --- httpd/httpd/trunk/support/ab.c (original)
 +++ httpd/httpd/trunk/support/ab.c Thu Sep  4 10:52:24 2014
[snip]
 @@ -1516,12 +1516,14 @@ static void read_connection(struct conne
   * this is first time, extract some interesting info
   */
  char *p, *q;
 +size_t len = 0;
  p = strstr(c-cbuff, Server:);
  q = servername;
  if (p) {
  p += 8;
 -while (*p  32)
 -*q++ = *p++;
 +/* -1 to not overwrite last '\0' byte */
 +while (*p  32  len++  sizeof(servername) - 1)

Maybe ++len above (instead of len++) since we need to leave room for
the final '\0' below?
Otherwise we may still overflow when writing it to
servername[sizeof(servername)]...

 +*q++ = *p++;
  }
  *q = 0;
  }


Regards,
Yann.