Re: http2 tests

[Kaspar Brand]

On 14.10.2015 14:55, Eric Covener wrote:
> On Wed, Oct 14, 2015 at 8:37 AM, Stefan Eissing
>  wrote:
>> Any advice on how to add a test host (e.g. real port) to our test suite in 
>> the most compatible way?
> 
> 1426878 added an SSL vhost. It seems like there is a magic port
> assignment the config-generator and client share info about .

Not sure if I'm too late with this, but just add something like the
below - this will add the required Listen and VirtualHost directives to
the generated config files (with an auto-assigned port number).

Kaspar

--- t/conf/ssl/ssl.conf.in  (revision 1709127)
+++ t/conf/ssl/ssl.conf.in  (working copy)
@@ -252,4 +252,10 @@
  SSLCipherSuite AES256-SHA
 

+
+SSLEngine On
+
+# ...
+
+
 

Re: H2 compatible ciphers

[Kaspar Brand]

On 16.10.2015 12:45, Stefan Eissing wrote:
> If the blacklist in RFC 7540 proves to be totally bogus, I'd favor
> ditching it in our server checks.

Sharing Yann's surprise about this huge blacklist... I'm also wondering
if this won't become a Sisyphean task, in the end (will the httpwg
regularly amend that list, BTW, or how do they intend to prevent
"unwanted" cipher suites from being used with HTTP/2?).

Another - quite radical - approach would consist of using a whitelist,
which consists of a single cipher suite only: given that section 9.2 of
RFC 7540 states

"Implementations of HTTP/2 MUST use TLS version 1.2"

and section 9.2.2 further says

"deployments of HTTP/2 that use TLS 1.2 MUST support
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] with the P-256
elliptic curve [FIPS186]"

then "H2Compliance on" would only have to make sure that this exact
suite is negotiated. (What this MTI cipher suite also means, IINM, is
that you can't run an RFC 7540 h2 compliant server with an ECDSA key
only, actually... not sure if that was really an intended effect of this
requirement.)

Kaspar

Re: this expected?

[Kaspar Brand]

On 10.10.2015 20:14, Stefan Eissing wrote:
> Testing 2.4.17 release tar ball on OS X 10.11 (event/worker/prefork, openssl 
> 1.0.2d):
> 
> t/ssl/varlookup.t ... 1/81 # Failed test 55 in 
> t/ssl/varlookup.t at line 105 fail #55
> # Failed test 56 in t/ssl/varlookup.t at line 105 fail #56
> # Failed test 57 in t/ssl/varlookup.t at line 105 fail #57
> # Failed test 58 in t/ssl/varlookup.t at line 105 fail #58
> # Failed test 75 in t/ssl/varlookup.t at line 105 fail #75
> # Failed test 76 in t/ssl/varlookup.t at line 105 fail #76
> t/ssl/varlookup.t ... Failed 6/81 subtests 

Can you quickly confirm that t/conf/ssl/ca/asf/certs/client_ok.crt (or
any other cert in this directory) is older than
Apache-Test/lib/Apache/TestSSLCA.pm in that test framework installation?
If so, the above failures are a consequence of r1705534 and r1705535,
and TEST -clean should help in getting a fresh collection of certs (if
it doesn't remove the t/conf/ssl/ca directory, it can just be rm'ed
manually).

Kaspar

Re: [VOTE] Release Apache httpd 2.4.17 as GA

[Kaspar Brand]

On 09.10.2015 19:40, Jim Jagielski wrote:
> The pre-release test tarballs for Apache httpd 2.4.17 can be found
> at the usual place:
> 
>   http://httpd.apache.org/dev/dist/
> 
> I'm calling a VOTE on releasing these as Apache httpd 2.4.17 GA.
> 
> [X] +1: Good to go

Tested with mod_ssl compiled against OpenSSL 0.9.8/1.0.0/1.0.1/1.0.2.

Kaspar

Re: SSLUseStapling: ssl handshake fails until httpd restart

[Kaspar Brand]

On 03.10.2015 12:07, Reindl Harald wrote:
> Am 03.10.2015 um 11:16 schrieb Kaspar Brand:
>> What do you have security.OCSP.require set to? If it's "true" (a setting
>> no longer configurable through the UI, BTW, see
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1034360), then Firefox
>> shows a fairly peculiar behavior: even when OCSP checking is disabled
>> (by setting security.OCSP.enabled to "0", through the "Query OCSP
>> responder servers to confirm the current validity of certificates"
>> preference in the UI under Advanced -> Certificates), it still includes
>> a status_request extension in the TLS handshake, and will subsequently
>> fail when it receives a stapled tryLater OCSP response, as long as
>> security.OCSP.require=true
> 
> security.OCSP.require=false is the default

Oh, looks like Firefox does sort of a "hard fail" when receiving a
stapled tryLater response - not what I would expect when
security.OCSP.require=false (and also security.OCSP.enabled=0), but
apparently, the security.ssl.enable_ocsp_stapling pref has precedence
over those.

As far as the mod_ssl side is related, it seems to me that for the
"SSLStaplingReturnResponderErrors off" case, we should make sure
that we only staple responses with status "good" (i.e.
OCSP_RESPONSE_STATUS_SUCCESSFUL and V_OCSP_CERTSTATUS_GOOD for the cert).

> but it's not only my client with random failed connections

This is really due to a very weird effect with ocsp.godaddy.com, as
further examination shows. GoDaddy is making use of Akamai's Global
Traffic Management service for "load balancing", i.e., depending on
where the client is located, you're getting one of the following
addresses back when querying for ocsp.godaddy.com.akadns.net (the CNAME
for ocsp.godaddy.com):

72.167.18.239
50.63.243.230
72.167.239.239
188.121.36.239
(the list might be incomplete, but it illustrates Akamai's GTM mechanism)

For Central Europe, you get back 188.121.36.239 (from GoDaddy's
Amsterdam data center), and from what I can tell, this site has a pretty
quirky behavior when handling new connections on port 80: the first
connection is instantaneously torn down with a TCP reset... but if you
immediately try again, the OCSP request is properly handled (for your
*.thelounge.net cert e.g., try [1]). Then, after some idle timeout, the
same effect kicks in again. I haven't been able to determine how long
the timeout is exactly, but judging from your log extracts, it seems to
be less than 30 minutes). Strangely enough, the other (US-based) sites
don't seem to exhibit this effect.

Kaspar


[1] 
http://188.121.36.239/MEgwRjBEMEIwQDAJBgUrDgMCGgUABBS2CA1fbGt26xPkOKX4ZguoUjM0TgQUQMK9J47MNIMwojPX+2yz8LQsgM4CByr+BC4coss=

Re: SSLUseStapling: ssl handshake fails until httpd restart

[Kaspar Brand]

On 01.10.2015 16:32, Reindl Harald wrote:
> Am 01.10.2015 um 16:29 schrieb Plüm, Rüdiger, Vodafone Group:
>> The question is: What happens on Firefox side. Of course it still tries to 
>> get to the OCSP server, but it should not cause an error on Firefox side if 
>> this does not work.
> 
> no, it does not because "security.OCSP.enabled = 0" and i saw at least 
> two requests to different servers failing with my Firefox with the 
> responder error from the webserver

What do you have security.OCSP.require set to? If it's "true" (a setting
no longer configurable through the UI, BTW, see
https://bugzilla.mozilla.org/show_bug.cgi?id=1034360), then Firefox
shows a fairly peculiar behavior: even when OCSP checking is disabled
(by setting security.OCSP.enabled to "0", through the "Query OCSP
responder servers to confirm the current validity of certificates"
preference in the UI under Advanced -> Certificates), it still includes
a status_request extension in the TLS handshake, and will subsequently
fail when it receives a stapled tryLater OCSP response, as long as
security.OCSP.require=true.

Kaspar

Re: SSLUseStapling: ssl handshake fails until httpd restart

[Kaspar Brand]

On 29.09.2015 18:24, Reindl Harald wrote:
> i just restarted the servers and disabled stapling since all our 
> servcies where unreachable (before i write the second mail 5 different 
> hosts with several sites where affected)
> 
> in fact the error caching does more harm than benefits - IHMO a better 
> "could not reach OCSP server or received a error from it" caching would 
> be just temporary disable stapling for 10 minutes instead lead in 
> connections fail even from clients which have disabled OCSP completly
> 
>>> firefox refused to open our adminpanel with the error below until i
>>> restarted httpd

The default for SSLStaplingReturnResponderErrors is relatively odd.
Not sure why it has always defaulted to "on" (r829619), but setting it
to off should save you further troubles with Firefox clients.

Kaspar

Re: Disable SSLv3 by default

[Kaspar Brand]

On 17.10.2014 19:25, Kaspar Brand wrote:
> On 17.10.2014 12:02, Takashi Sato wrote:
>> SSLv3 is now insecure (CVE-2014-3566, POODLE)
>> Let's disable SSLv3 by default, at least trunk.
>>
>> SSLProtocol default is "all".
>> <http://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslprotocol>
>> "all" means "a shortcut for ``+SSLv3 +TLSv1'' or - when using OpenSSL
>> 1.0.1 and later - ``+SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2, respectively."
>>
>> Should we remove SSLv3 from "all" ?
> 
> From a semantic point of view, I wouldn't do that. As long as we still
> allow SSLv3 to be used, "all" should really mean "all protocols which
> can be enabled in mod_ssl".
> 
> I'm fine with changing the hardcoded default (in ssl_engine_config.c) to
> SSL_PROTOCOL_ALL & ~SSL_PROTOCOL_SSLV3, though.

For the record: this is part of r1703952 which I just committed to trunk
(and will propose for backporting to 2.4 shortly, unless there are
objections).

> The other option would be to drop SSLv3 support completely, like we
> currently do for SSLv2 in ssl_engine_init.c:ssl_init_ctx_protocol(). In
> this case, "all" would no longer include SSLv3, of course.

This is left as a next step, which I consider appropriate for trunk, at
least.

Kaspar

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Kaspar Brand]

On 05.09.2015 13:06, Tim Bannister wrote:
> It's not just conventional browsers. I think automated / embedded
> HTTP clients will also benefit from stapling, either because
> networking filters would block a conversation between the client and
> the CA's OCSP responder, or the extra latency from using conventional
> OCSP is a problem.

That hope is mostly futile: OpenSSL e.g., presumably quite popular
for implementing such clients, does not include any readily available
support for enabling OCSP checking in client mode. And even if a library
has some sort of knob for turning it on (Sun^WOracle's CertPath provider
e.g.), you'll mostly find that they don't handle stapled responses.
Consider yourself happy if a client at least does some sort of hostname
verification (see https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf for
further background, the situation didn't change fundamentally since then).

> For another example of a non-interactive application implementing
> OCSP, look at the Exim mail transfer agent (which can be both client
> and server).

SMTP with STARTTLS isn't a useful example, sorry... it's opportunistic
encryption only in the best case, and for MTA communications, DANE-EE
(https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/) looks
like a more promising approach.

Kaspar

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Kaspar Brand]

On 05.09.2015 12:53, Ben Laurie wrote:
> On Sat, 5 Sep 2015 at 09:32 Kaspar Brand <httpd-dev.2...@velox.ch> wrote:
>> I'm also very sceptical that a higher percentage of handshakes with
>> stapled responses (how much exactly?) will lead browser vendors to
>> switch to hard fail - as the test-sspev.verisign.com example from my
>> previous message shows, they could do this for EV today already (even
>> Chrome tries querying the OCSP responder in this case). But none of them
>> does, often due to the fear of losing market share when being too strict
>> in enforcing TLS security (cf. the case of RC4 banning).
>>
> 
> I don't know why you think your example shows that - the reason browsers
> don't hard fail is because OCSP (or any out of band communication) is
> unreliable.

Unreliable in what sense, or for what reason? Due to OCSP responders
being unreachable, being unable to handle the load, serving flawed
responses (like the recent hiccup mentioned in
https://twitter.com/GSSystemAlerts/status/634418637835669504), or...?
Only the second point can be addressed by stapling, as it simply
switches to another method for transmitting the response to the client.

> So that either means you fail for sites that are actually
> perfectly OK, or you allow an attacker to override revocation (by blocking
> OCSP).
> 
>  This is why browsers are pushing for OCSP stapling, not because of speed.

Taking into account that OCSP responders from the big players are
running on fairly robust infrastructure these days (cf. the sr.symcd.com
example, aka ocsp.verisign.net, aka ocsp.ws.symantec.com.edgekey.net),
I'm not buying the "OCSP is unreliable" statement in this wholesale form.

Even assuming that, say, 90% of all handshakes would include stapled
responses one day, I'm pretty sure that browsers would come up with
other arguments as to why they can't enforce hard-fail. Or perhaps in
one or two years, they want everybody to switch to using short-lived
certs without OCSP (because "revocation doesn't work" anyway), at which
point the "let's get OCSP stapling universally deployed" exercise would
become moot.

> Certificate Transparency faces the same problem, which is why it only
> exists as an in-band mechanism.
> 
> Blocking stapling (and presumably you will also object to CT for similar
> reasons) is hurting security.

CT is a completely separate topic, but for the sake of completeness:
yes, I would object to enabling such a feature in httpd by default, as
long as it triggers outgoing connections on the server. That isn't the
case for being able to serve SCTs, however: all it takes is
httpd/mod_ssl 2.4.8 or later compiled against OpenSSL 1.0.2a or later,
an appropriate "BEGIN SERVERINFO FOR..." file and an "SSLOpenSSLConfCmd
ServerInfoFile ..." directive in the config (no outgoing connectivity on
the server needed, neither permanently nor temporarily).

> You've argued that there's no point switching on stapling because browsers
> won't pay attention to OCSP anyway. That is not true. They don't pay
> attention to OCSP because it is unreliable. If stapling were widely
> deployed, then it would be possible to switch on hard fail.

Again, the "OCSP is unreliable" statement is just your current claim
(unless you can provide real-world measurements showing things like "30%
of all OCSP queries fail due to timeouts", "50% of all OCSP checks take
more than 3 seconds" or similar). Having used Firefox with
security.OCSP.require=true for extended periods of time, I do not agree
with the overall assessment of OCSP being unreliable.

> Leaving it to admins makes no sense to me - most admins are not acquainted
> with the detailed reasons for/against stapling, and are not in a position
> to make an informed decision.

That's what our documentation is for. Just asserting that admins
are too dumb to understand and instead decide on their behalf is an
attitude I strongly dislike. Apache httpd is not the same sort of
software like browsers for the big (and probably often clueless) masses,
where that approach might have its justification.

> Someone has to choose the default, and IMO
> the ASF should always default to "more secure".

Pretty muddy ground - "more secure" in what sense exactly? A server not
being dependent on outgoing connectivity for its day-to-day operations
is typically more secure than one which regularly needs to fetch data
from the outside world.

And if stapling is really making servers "more secure", why are
www.google.com, mail.google.com or drive.google.com still not providing
stapled responses as of today? (same is true for other high-traffic
sites like Twitter or FB, JFTR)

Kaspar

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Kaspar Brand]

On 05.09.2015 14:23, Jeff Trawick wrote:
> On 09/04/2015 10:59 AM, Kaspar Brand wrote:
>>> 1. The default configuration should not trigger unsolicited outgoing
>>> queries to untrusted systems, for both a) and b), that's how I would put it.
> 
> Re: "unsolicited":
> 
> Key words/phrases from the other end of the continuum: "unexpected by 
> many", "responder obtained from explicitly configured certificate"

The other end of the continuum would be "explicitly requested", in my
view. "unsolicited" = "not explicitly requested", that's what I intended
to say (and "explicitly" referring to something like "manually enabling
a directive").

> The unexpected aspect could be helped by a [notice] message at startup 
> indicating that an OCSP responder will be contacted for N certificates 
> due to the directive.  (If there is only one, an alternate message could 
> be displayed with the actual responder URL; we couldn't do that for 
> arbitrary numbers.)

IMO, not a sufficient method for justifying a "default on" setting
(configuring a Base64 encoded certificate blob through
SSLCertificateFile doesn't amount to explicitly configuring a responder
URI).

> Re: "untrusted":
> 
> The certificate and its content are untrusted in general?

Technically speaking, as long as mod_ssl doesn't validate the cert file
against a set of (locally configured) trust anchors, the complete file
is to be considered untrusted. An admin could have received a "fake
reply" for his CSR, where the public key perfectly matches the private
key, but the contents are bogus otherwise. Sure, he would most likely
realize this quite soon after having configured the cert and trying to
connect to his own server, but essentially, I wouldn't consider the
contents pointed to by an SSLCertificateFile directive as trusted.

> The content 
> is trusted but the responder URL is not what/who it seems? (I wasn't 
> sure where you were leading when you alluded to this in prior 
> correspondence.)

X.509v3 certs can have all sorts of "useful" extensions, and I wouldn't
consider all this information automatically trusted just because it's
signed by the CA (take the OU field in the subject DN as an example:
most CAs will have disclaimers stating that these fields are basically
"unverified").

With the OCSP URI in particular, an additional aspect of "untrusted" is
that resolving its IP address(es) relies on the DNS, i.e. a component
which can't be considered trusted when it is queried for records of
third-party domains.

Kaspar

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Kaspar Brand]

On 04.09.2015 17:54, Rob Stradling wrote:
> Today, roughly 25% of HTTPS servers on the Internet have OCSP stapling
> enabled.  Browsers aren't likely to start hard-failing by default until
> that % is a lot higher.
> 
> The vast majority of the servers that have OCSP stapling enabled are
> running IIS.  I claim that this is due to the fact that IIS enables OCSP
> stapling by default.

The relevant metric is the percentage of (initial) TLS handshakes with
stapled responses, not so much the percentage of servers with stapling
enabled. Judging from Mozilla's telemetry data for Firefox 39 and 40,
that percentage is still below 15%, and enabling stapling in an httpd
config file which gets used by a very small number of Apache httpd admins
(as opposed to those settings which go out to the world via [1] or [2])
doesn't look like a very effective way of achieving the goal of making
that percentage "a lot higher".

I'm also very sceptical that a higher percentage of handshakes with
stapled responses (how much exactly?) will lead browser vendors to
switch to hard fail - as the test-sspev.verisign.com example from my
previous message shows, they could do this for EV today already (even
Chrome tries querying the OCSP responder in this case). But none of them
does, often due to the fear of losing market share when being too strict
in enforcing TLS security (cf. the case of RC4 banning).

> I think you've misunderstood the "speed, speed, speed" argument.
> 
> If an OCSP response is delivered via stapling, then there's no need for
> the browser to block the TLS handshake whilst it obtains an OCSP
> response directly from the CA's OCSP responder.

No, I didn't misunderstand. That's very much the essence of the "speed,
speed, speed" argument - "our browser must be able to complete every TLS
handshake in under 100 ms"... even if for a specific server, it's just
one TLS handshake per day where it really matters.

> Stapling provides a noticeable speedup even if the browser never caches
> OCSP responses.

Fairly hypothetical point - I'm not aware of any common browser which
would use a cert validation library without an OCSP cache.

Kaspar


[1] https://git.centos.org/blob/rpms!httpd.git/c7/SOURCES!ssl.conf

[2] 
https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/apache2/trusty/view/head:/debian/config-dir/sites-available/default-ssl

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Kaspar Brand]

On 02.09.2015 01:54, Jeff Trawick wrote:
> On 08/30/2015 02:30 AM, Kaspar Brand wrote:
>> today's situation, because this assessment misses the fact that with the
>> current RFC-6066-based implementation, stapling can't fully achieve the
>> goal of obviating OCSP queries for the clients - all publicly trusted
>> CAs use hierarchies with at least two tiers these days, so effectively
>> RFC 6961 support would be needed.
> I plead ignorance, but I don't see that "can't fully achieve" is a blocker.

It's not a blocker, sure, but on the other hand, the benefit of enabling
stapling by default isn't that big either - as long as browsers don't
hard-fail when OCSP information isn't available. The "speed, speed,
speed" argument (coming mostly from the browser vendors) isn't too
convincing to me neither, as OCSP replies are usually cached for one
or two days, and the typical user doesn't connect to thousands of
new/different SSL sites per day.

> Is there a synopsis of which browsers support it for which types of 
> certificates?

I don't think so, and it's probably also kind of a moving target. Chrome
"supports" it for DV and OV as well - it will include a status_request
extension in the TLS handshake by default -, but what I meant with
"enforces" is that it won't care if there's no stapled response
(Google's ceterum censeo used to be "Revocation doesn't work", which in
2012 lead to their implementation of CRL sets where the code is public,
but "the process by which they are generated is not",
https://dev.chromium.org/Home/chromium-security/crlsets).

For EV certs, the browser behavior is more uniform, though strict hard
fail enforcement still isn't happening - for testing purposes, try
this experiment: block connections to sr.symcb.com:80 and sr.symcd.com:80,
and point the browser to
https://test-sspev.verisign.com:2443/test-SSPEV-revoked-verisign.html.
With strict revocation checking enforced, no browser should ever render
any content of the "Revoked VeriSign Secure Site Pro with EV Certificate
Test Page" (but most do when revocation information is not available,
although some at least show warnings or downgrade the UI to non-EV).

> The motivation for putting it in trunk is so that the next release has 
> stapling enabled in the default configurations, which essentially means 
> that in some number of years (2-3?  I dunno) there will be a 
> faster-growing number of httpd instances that have OCSP stapling enabled.

Ok, if it's about 2.6/3.0, then we're indeed talking of a timeframe of
several years, I assume. What I don't like with this approach in any
case, however, is that we as the devs decide on behalf of the admins,
instead of letting them make an informed decision. I' really arguing
in favor of something like this in httpd-ssl.conf.in:

--- snip ---
#   SSL Engine Switch:
#   Enable/Disable SSL for this virtual host.
SSLEngine on

#  Server Certificate and Private Key:
#  ...
SSLCertificateFile "conf/server.crt"
SSLCertificateKeyFile "conf/server.key"

#  OCSP Stapling:
#  For SSL certificates which include an OCSP responder URI, mod_ssl
#  can include revocation status information for the server's own
#  certificate in the TLS handshake. Enabling this option requires
#  outgoing connectivity to the CA's OCSP responder (usually running
#  running on port 80, use "openssl x509 -in server.crt -text" to
#  determine the exact URI), so this option is not enabled by default.
#  The responder will be queried with the interval configured
#  via SSLStaplingStandardCacheTimeout. For EV SSL certificates
#  in particular, enabling this option is recommended/useful.
#SSLUseStapling On
--- snip ---

(i.e., move the SSLUseStapling directive closer to the cert settings,
and make people aware of the outgoing connections this will trigger)

> Part of what makes the 2.4.x tangent is confusing is that sometimes your 
> objections seem to be qualified on the assumption that 2.4.x would be 
> updated.  Can we please drop 2.4.x from this conversation?

Will do, yes. When trunk becomes 2.6/3.0 one day (and a GA release), the
basic question remains, though: is it acceptable that configuring an SSL
certificate potentially triggers outgoing OCSP requests in mod_ssl,
without having been explicitly instructed to do so by an admin? My view
is still the same as in November 2014: admins should opt in for this
feature, not be forced to opt out.

>>   It's also for this reason that I'm not in favor of a global
>> "SSLUseStapling On", it should really be configured on a per-vhost basis.
> 
> I don't follow.  What does that help?  With which attack vector does 
> that improve the situation?

The point I was trying to make is that stapling is a per-certificate
feature (not a global one like SSLRandomSeed, SSLSessionCache etc.), so
it would be be

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Kaspar Brand]

On 28.08.2015 19:27, Jeff Trawick wrote:
 For one, it is appropriate for the default config is there to enable
 practices which are reasonable in most situations, and OCSP Stapling is
 widely accepted as an appropriate feature for HTTP servers to enable.

I have some doubts whether widely accepted is an accurate summary of
today's situation, because this assessment misses the fact that with the
current RFC-6066-based implementation, stapling can't fully achieve the
goal of obviating OCSP queries for the clients - all publicly trusted
CAs use hierarchies with at least two tiers these days, so effectively
RFC 6961 support would be needed. And given that the most popular
browser only enforces revocation checking for EV certificates (certainly
less than 10% of all SSL certs out there), the benefit of turning on
stapling for DV/OV certs by default is not so apparent either.

What wasn't mentioned in the original RFC [1], and what I'm still
wondering about, is the primary motivation for enabling it on trunk? As
I wrote in my reply at that time, changing the default in trunk will
hardly help in getting broader real-world testing results. If the
plan is to propose a backport to 2.4.x soon afterwards, however, then I
would certainly oppose unless systematic coverage for OCSP stapling is
added to the test framework (enabling a feature by default in a GA
release for which there is not a single test is a no go, IMO).

 Also, strictly speaking, the default config does not have SSL enabled
 anyway, and after manually enabling it OCSP responses won't be fetched
 unless a certificate is configured which references an OCSP responder.

It should be worth mentioning that the OCSP URI in a server cert is to
be considered untrusted, as mod_ssl does not validate its own cert at
startup. It's also for this reason that I'm not in favor of a global
SSLUseStapling On, it should really be configured on a per-vhost basis.

 While I find the not make accidental outgoing connections argument
 compelling (though perhaps with a different word than accidental) the
 server already takes actions that cause outgoing connections to services
 not explicitly configured (DNS), and these occasionally cause problems.

Are you referring to queries when doing PTR lookups for connecting
clients? I think that's one of the very reasons why HostnameLookups
Off was chosen for extra/httpd-default.conf.

 Is there a principle at stake which could be followed consistently across
 disparate features in how the server behaves a) with compiled in defaults
 and minimal config, or b) with default/recommended config?

The default configuration should not trigger unsolicited outgoing
queries to untrusted systems, for both a) and b), that's how I would
put it. Additionally, features enabled by default need to have sufficient
coverage in the test framework.

 If enabling stapling were more closely tied in the configuration language
 to configuring a certificate, which with SSLUseStapling On is the user
 action that makes mod_ssl talk to a responder, would that help the end
 user?  (Controlling stapling parameters on a per-certificate basis is
 valuable anyway since you can have multiple certificates per vhost,
 possibly with different responders.)

It's not very common to configure multiple certs for a single vhost, I
guess - mainly due to the single-chain-only limitation in OpenSSL up to
1.0.1. I wouldn't put too much effort into making it a per-certificate
setting (seems relatively complex to implement, at least at first glance).

Kaspar

[1] 
https://mail-archives.apache.org/mod_mbox/httpd-dev/201410.mbox/%3CCAKUrXK6k01WGqF8z6F3YBNbanbTaOSHbbzwSi2O3H3u03_mvUw%40mail.gmail.com%3E

Re: AW: [RFC] Enable OCSP Stapling by default in httpd trunk

[Kaspar Brand]

On 29.08.2015 17:56, olli hauer wrote:
 On 2015-07-03 12:13, Plüm, Rüdiger, Vodafone Group wrote:
 Thanks for the detailed explanation. So yes OCSP stapling is really
 beneficial if it is possible for the server admin to set it up. But
 it likely requires additional configuration steps outside of httpd
 to make the OCSP responder reachable (like firewall clearances) and
 leads to otherwise strange slow responses if this is not
 prepared. Another obstacle with the current stapling code is that
 the connection to the OCSP responder of the CA needs to happen
 directly and cannot be done via a proxy. Hence I agree with Kaspar
 that it should be off by default.
 
 
 Not tested, but looking at the mod_ssl doc it seems
 SSLStaplingForceURL can be used to proxy requests to the OCSP
 responder(s)
 
 http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslstaplingforceurl

 In case SSLStaplingForceURL can be used to force OCSP requests via
 proxy it would be nice to add something like the following patch
 before enabling OCSP stapling as default.

It can't be used like this, as pointed out in [1]. Its main use is for
certs which do not include an OCSP URI at all, so configuring
SSLStaplingForceURL at the global level doesn't make much sense - you
would have to run a transparent OCSP proxy at that URL (mod_ssl will
just send plain OCSP requests to this address).

Kaspar

[1] 
https://mail-archives.apache.org/mod_mbox/httpd-dev/201411.mbox/%3C5454A1FE.6060204%40velox.ch%3E

Re: svn commit: r1672014 - in /httpd/httpd/trunk: CHANGES server/config.c

[Kaspar Brand]

On 14.8.15 20:01, Eric Covener wrote:
 On Wed, Apr 15, 2015 at 12:02 PM, Kaspar Brand httpd-dev.2...@velox.ch 
 wrote:
 The other option to fix the problem which originally triggered this
 investigation would be to simply replace cmd-server in
 ssl_engine_config.c:836 with NULL, though it would only fix this
 particular case, and not help with other places with the same underlying
 problem.
 
 What are the different scenarios that are bad in 2.4? I stumbled on
 this thread on a search about a related topic.
 
 I think this is the immediate one, but I really don't like the idea of
 using the default loglevel there:
 
 LogLevel crit
 virtualhost *:443
   SSLSomethingThatWouldWarn
   LogLevel warn
 /virtualhost
 
 What are the other variants?

That's basically the pattern I meant. With other places with the same
underlying problem, I was referring to other modules which use
cmd-server for logging during ap_process_config_tree walking (and
before ap_fixup_virtual_hosts is called).

There are a number of ap_log_error(..., cmd-server, ...) occurrences
in mod_env, mod_ldap, mod_proxy, mod_authnz_ldap, mod_auth_digest,
mod_file_cache, mod_rewrite, and mod_alias, and in particular when they
are using APLOG_WARNING, these messages are not logged unless there's a
preceding LogLevel statement in the respective VirtualHost block.

server/core.c on the other hand also has a few places where this problem
occurs, here's an example:

LogLevel warn
VirtualHost *:80
  ServerName example.net
  DefaultType text/plain
/VirtualHost

The Ignoring deprecated use of DefaultType... message is only output
if an additional LogLevel warn statement in the VirtualHost block is
inserted (which must appear before the DefaultType statement).

Kaspar

Re: Using UPN from subjectAltName with SSLUserName

[Kaspar Brand]

On 19.07.2015 17:24, Kaspar Brand wrote:
 But, to be on the safe side, I think we could a) move the OBJ_create()
 call to ssl_hook_pre_config and b) omit OBJ_cleanup(). Do you concur?

For the record: I have now committed this to trunk with r1693792.

Kaspar

Re: Using UPN from subjectAltName with SSLUserName

[Kaspar Brand]

On 13.07.2015 16:03, Joe Orton wrote:
 On Sat, Jul 11, 2015 at 04:40:20PM +0200, Kaspar Brand wrote:
 @@ -1902,5 +1907,7 @@ apr_status_t ssl_init_ModuleKill(void *data)
  
  free_dh_params();
  
 +OBJ_cleanup();
 +
  return APR_SUCCESS;
 
 From being burnt previously three or four times, I get scared by OpenSSL 
 process global stuff.
 
 Have you worked out that it's safe to do that call there?  It looks odd 
 to do that there rather than alongside other global cleanups in 
 ssl_cleanup_pre_config, so it's at least worth a comment if you really 
 want this here.

Thanks for the heads up. After further digging, I believe it's not
really comparable to the cases you're probably referring to (only found
these two):

1) ERR_load_crypto_strings() / ERR_free_strings()

Originally addressed in https://svn.apache.org/r101624, it was
subsequently fixed in OpenSSL (0.9.8e and later, see [1]), and
in late 2014 also adjusted for more recent OpenSSL versions
(PR 53435 / https://bz.apache.org/bugzilla/show_bug.cgi?id=53435).

2) CRYPTO_new_ex_data() / CRYPTO_cleanup_all_ex_data()

Addressed in https://svn.apache.org/r654119 (by dropping the
CRYPTO_cleanup_all_ex_data call), see also PR 44975 /
https://bz.apache.org/bugzilla/show_bug.cgi?id=44975).

OBJ_create() / OBJ_cleanup() doesn't seem to suffer from these problems,
but on the other hand, I'm also fine with dropping the OBJ_cleanup()
call, since we only call OBJ_create() if the table entry doesn't exist
yet (i.e. even repeated calls in ssl_init_Module / reloads
do not cause any leak).

 There is some complicated interaction between EVP_cleanup() and
 OBJ_cleanup() which I haven't tried to decipher, but it looks like
 EVP_cleanup() will actually do the cleanup call?

This was added with 1.0.0, apparently [2]. The code would apply if
OBJ_cleanup were called *before* EVP_cleanup (in all other cases,
EVP_cleanup does not call OBJ_cleanup).

But, to be on the safe side, I think we could a) move the OBJ_create()
call to ssl_hook_pre_config and b) omit OBJ_cleanup(). Do you concur?

Kaspar


[1] 
https://git.openssl.org/?p=openssl.git;a=commitdiff;h=35e59297fca389b68bcad29876927666300ce971

[2] 
https://git.openssl.org/?p=openssl.git;a=commitdiff;h=246e09319c1d2a8140ffe1e5aeb1be26015696f0

Re: Using UPN from subjectAltName with SSLUserName

[Kaspar Brand]

On 29.06.2015 15:14, Jan Pazdziora wrote:
 How about just passing char * and doing all the mapping logic
 including possible OBJ_create in parse_otherName_value? My goal here
 is to have all the hard work of determining the semantics isolated
 in one place.
 
 Please see patch attached.

You're right, an ASN1_OBJECT * as an argument for modssl_X509_getSAN
makes handling of otherName entries relatively awkward. In the attached
patch, I have switched to a string for specifying the requested
otherName form (similar to what you did in your patch).

OBJ_create adds new entries to a process-wide table, so instead of
checking for the presence of a specific entry at each request (in
parse_otherName_value), I consider it more appropriate and efficient to
do this only once, in ssl_init_Module.

Barring feedback against this approach (or the observation of bugs in
the implementation), I intend to commit it to trunk in the next few days
(including mod_ssl.xml changes and a CHANGES item).

Kaspar
Index: modules/ssl/ssl_engine_init.c
===
--- modules/ssl/ssl_engine_init.c   (revision 1690371)
+++ modules/ssl/ssl_engine_init.c   (working copy)
@@ -352,6 +352,11 @@ apr_status_t ssl_init_Module(apr_pool_t *p, apr_po
 
 init_dh_params();
 
+if (OBJ_txt2nid(id-on-dnsSRV) == NID_undef) {
+(void)OBJ_create(1.3.6.1.5.5.7.8.7, id-on-dnsSRV,
+ SRVName otherName form);
+}
+
 return OK;
 }
 
@@ -1902,5 +1907,7 @@ apr_status_t ssl_init_ModuleKill(void *data)
 
 free_dh_params();
 
+OBJ_cleanup();
+
 return APR_SUCCESS;
 }
Index: modules/ssl/ssl_util_ssl.c
===
--- modules/ssl/ssl_util_ssl.c  (revision 1690371)
+++ modules/ssl/ssl_util_ssl.c  (working copy)
@@ -252,19 +252,48 @@ char *modssl_X509_NAME_to_string(apr_pool_t *p, X5
 return result;
 }
 
+static void parse_otherName_value(apr_pool_t *p, ASN1_TYPE *value,
+  const char *onf, apr_array_header_t 
**entries)
+{
+const char *str;
+int nid = onf ? OBJ_txt2nid(onf) : NID_undef;
+
+if (!value || (nid == NID_undef) || !*entries)
+   return;
+
+/* 
+ * Currently supported otherName forms (values for onf):
+ * msUPN (1.3.6.1.4.1.311.20.2.3): Microsoft User Principal Name
+ * id-on-dnsSRV (1.3.6.1.5.5.7.8.7): SRVName, as specified in RFC 4985
+ */
+if ((nid == NID_ms_upn)  (value-type == V_ASN1_UTF8STRING) 
+(str = asn1_string_to_utf8(p, value-value.utf8string))) {
+APR_ARRAY_PUSH(*entries, const char *) = str;
+} else if (strEQ(onf, id-on-dnsSRV) 
+   (value-type == V_ASN1_IA5STRING) 
+   (str = asn1_string_to_utf8(p, value-value.ia5string))) {
+APR_ARRAY_PUSH(*entries, const char *) = str;
+}
+}
+
 /* 
  * Return an array of subjectAltName entries of type type. If idx is -1,
  * return all entries of the given type, otherwise return an array consisting
  * of the n-th occurrence of that type only. Currently supported types:
  * GEN_EMAIL (rfc822Name)
  * GEN_DNS (dNSName)
+ * GEN_OTHERNAME (requires the otherName form [onf] argument to be supplied,
+ *see parse_otherName_value for the currently supported forms)
  */
-BOOL modssl_X509_getSAN(apr_pool_t *p, X509 *x509, int type, int idx,
-apr_array_header_t **entries)
+BOOL modssl_X509_getSAN(apr_pool_t *p, X509 *x509, int type, const char *onf,
+int idx, apr_array_header_t **entries)
 {
 STACK_OF(GENERAL_NAME) *names;
+int nid = onf ? OBJ_txt2nid(onf) : NID_undef;
 
-if (!x509 || (type  GEN_OTHERNAME) || (type  GEN_RID) || (idx  -1) ||
+if (!x509 || (type  GEN_OTHERNAME) ||
+((type == GEN_OTHERNAME)  (nid == NID_undef)) ||
+(type  GEN_RID) || (idx  -1) ||
 !(*entries = apr_array_make(p, 0, sizeof(char * {
 *entries = NULL;
 return FALSE;
@@ -277,33 +306,43 @@ char *modssl_X509_NAME_to_string(apr_pool_t *p, X5
 
 for (i = 0; i  sk_GENERAL_NAME_num(names); i++) {
 name = sk_GENERAL_NAME_value(names, i);
-if (name-type == type) {
-if ((idx == -1) || (n == idx)) {
-switch (type) {
-case GEN_EMAIL:
-case GEN_DNS:
-utf8str = asn1_string_to_utf8(p, name-d.ia5);
-if (utf8str) {
-APR_ARRAY_PUSH(*entries, const char *) = utf8str;
-}
-break;
-default:
-/*
- * Not implemented right now:
- * GEN_OTHERNAME (otherName)
- * GEN_X400 (x400Address)
- * GEN_DIRNAME (directoryName)
- * GEN_EDIPARTY (ediPartyName)
-

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Kaspar Brand]

On 01.07.2015 14:27, Ben Laurie wrote:
 On 1 November 2014 at 09:05, Kaspar Brand httpd-dev.2...@velox.ch wrote:
 The fundamental objection I have to enabling stapling by default in our
 GA releases is that it would enable a phoning home feature (to the
 CA's OCSP responders) as a side effect of configuring a certificate.
 This is a setting I consider unacceptable for software published by the
 Apache HTTP Server project - the default must be opt-in, not opt-out.
 
 I've just become aware of this objection and would like to understand
 the thinking behind it. Firstly, it seems strange to call this
 phoning home, a term that _usually_ means connecting to the vendor
 of the s/w.
 
 But more importantly, what harm is there in a server connecting to the
 OCSP responders for the certificates it is serving? Why is this
 unacceptable?

It's unacceptable for at least two reasons: a) by default, an HTTP
server is supposed to process *incoming* requests, not make accidental
outgoing connections in addition (at least not unless it's explicitly
instructed to do so); b) there's no statement in our license with an
explicit caveat on such a side effect (when relying on our default
settings, configuring a site with an SSL server certificate may result
in unsolicited outgoing HTTP requests - and no, I do not want to see
our license amended by things like that).

I maintain my objection to uncommenting #SSLUseStapling On in our
default config in httpd-ssl.conf.in - and for the record, also to
changing code, be that in ssl_engine_config.c:modssl_ctx_init() or
elsewhere. Those keen on enabling it by default on behalf of the users
(because we know what is good for you) are free to lobby with the OS
vendors to have their package defaults changed.

Kaspar

Re: Using UPN from subjectAltName with SSLUserName

[Kaspar Brand]

On 22.06.2015 10:37, Jan Pazdziora wrote:
 Please find a new patch attached which I hope covers all the
 parts you've outlined, for SSL_CLIENT_SAN_OTHER_msUPN_*.

Thanks. Your implementation assumes that only a single otherName form
(msUPN) needs to be supported, but I would prefer to code it in a
somewhat more extensible way.

Does the attached patch work for you? As a practical way of
demonstrating generic support of otherName forms, I have
added the case of the SRVName otherName form (RFC 4985, for things like
_carddavs._tcp.example.com, exposed via SSL_SERVER_SAN_OTHER_dnsSRV_n).

Kaspar
Index: modules/ssl/ssl_engine_init.c
===
--- modules/ssl/ssl_engine_init.c   (revision 1687983)
+++ modules/ssl/ssl_engine_init.c   (working copy)
@@ -352,6 +352,11 @@ apr_status_t ssl_init_Module(apr_pool_t *p, apr_po
 
 init_dh_params();
 
+if (OBJ_txt2nid(id-on-dnsSRV) == NID_undef) {
+(void)OBJ_create(1.3.6.1.5.5.7.8.7, id-on-dnsSRV,
+ SRVName otherName form);
+}
+
 return OK;
 }
 
@@ -1902,5 +1907,7 @@ apr_status_t ssl_init_ModuleKill(void *data)
 
 free_dh_params();
 
+OBJ_cleanup();
+
 return APR_SUCCESS;
 }
Index: modules/ssl/ssl_util_ssl.c
===
--- modules/ssl/ssl_util_ssl.c  (revision 1687983)
+++ modules/ssl/ssl_util_ssl.c  (working copy)
@@ -252,19 +252,46 @@ char *modssl_X509_NAME_to_string(apr_pool_t *p, X5
 return result;
 }
 
+static void parse_otherName_value(apr_pool_t *p, ASN1_TYPE *value,
+  ASN1_OBJECT *oid,
+  apr_array_header_t **entries)
+{
+const char *str;
+
+if (!value || !oid || !*entries)
+   return;
+
+/* 
+ * Currently supported otherName forms:
+ * - msUPN (1.3.6.1.4.1.311.20.2.3): Microsoft User Principal Name
+ * - dnsSRV (1.3.6.1.5.5.7.8.7): SRVName, as specified in RFC 4985
+ */
+if ((OBJ_obj2nid(oid) == NID_ms_upn) 
+(value-type == V_ASN1_UTF8STRING) 
+(str = asn1_string_to_utf8(p, value-value.utf8string))) {
+APR_ARRAY_PUSH(*entries, const char *) = str;
+} else if ((OBJ_obj2nid(oid) == OBJ_txt2nid(id-on-dnsSRV)) 
+   (value-type == V_ASN1_IA5STRING) 
+   (str = asn1_string_to_utf8(p, value-value.ia5string))) {
+APR_ARRAY_PUSH(*entries, const char *) = str;
+}
+}
+
 /* 
  * Return an array of subjectAltName entries of type type. If idx is -1,
  * return all entries of the given type, otherwise return an array consisting
  * of the n-th occurrence of that type only. Currently supported types:
  * GEN_EMAIL (rfc822Name)
  * GEN_DNS (dNSName)
+ * GEN_OTHERNAME (see parse_otherName_value for currently supported forms)
  */
-BOOL modssl_X509_getSAN(apr_pool_t *p, X509 *x509, int type, int idx,
-apr_array_header_t **entries)
+BOOL modssl_X509_getSAN(apr_pool_t *p, X509 *x509, int type, ASN1_OBJECT *oid,
+int idx, apr_array_header_t **entries)
 {
 STACK_OF(GENERAL_NAME) *names;
 
-if (!x509 || (type  GEN_OTHERNAME) || (type  GEN_RID) || (idx  -1) ||
+if (!x509 || (type  GEN_OTHERNAME) || (type == GEN_OTHERNAME  !oid) ||
+(type  GEN_RID) || (idx  -1) ||
 !(*entries = apr_array_make(p, 0, sizeof(char * {
 *entries = NULL;
 return FALSE;
@@ -277,33 +304,43 @@ char *modssl_X509_NAME_to_string(apr_pool_t *p, X5
 
 for (i = 0; i  sk_GENERAL_NAME_num(names); i++) {
 name = sk_GENERAL_NAME_value(names, i);
-if (name-type == type) {
-if ((idx == -1) || (n == idx)) {
-switch (type) {
-case GEN_EMAIL:
-case GEN_DNS:
-utf8str = asn1_string_to_utf8(p, name-d.ia5);
-if (utf8str) {
-APR_ARRAY_PUSH(*entries, const char *) = utf8str;
-}
-break;
-default:
-/*
- * Not implemented right now:
- * GEN_OTHERNAME (otherName)
- * GEN_X400 (x400Address)
- * GEN_DIRNAME (directoryName)
- * GEN_EDIPARTY (ediPartyName)
- * GEN_URI (uniformResourceIdentifier)
- * GEN_IPADD (iPAddress)
- * GEN_RID (registeredID)
- */
-break;
+
+if (name-type != type)
+continue;
+
+switch (type) {
+case GEN_EMAIL:
+case GEN_DNS:
+if (((idx == -1) || (n == idx)) 
+(utf8str = asn1_string_to_utf8(p, name-d.ia5))) {
+APR_ARRAY_PUSH(*entries, const char *) = utf8str;

Re: mod_ssl static linking, the eternal topic...

[Kaspar Brand]

On 23.06.2015 13:40, Stefan Eissing wrote:
 Sorry for missing that: it is still dynamically linked.
 
 Am 23.06.2015 um 13:39 schrieb Rainer Jung rainer.j...@kippdata.de:

 Am 23.06.2015 um 11:34 schrieb Stefan Eissing:
 Sorry to bother the list, but I am banging my head against the wall trying 
 to build mod_ssl linked statically with openssl on Ubuntu.

 Is there something obvious that I miss in my

 configure --enable-ssl=shared --with-ssl=$(BLD_PREFIX) 
 --enable-ssl-staticlib-deps

 ? It works under OS X, but not on Ubuntu 10.04 LTS. $(BLD_PREFIX)/lib shows
 -rw-r--r-- 1 sei sei 4498826 Jun 22 18:40 libcrypto.a
 lrwxrwxrwx 1 sei sei  18 Jun 22 18:40 libcrypto.so - libcrypto.so.1.0.0
 -r-xr-xr-x 1 sei sei 2682743 Jun 22 18:40 libcrypto.so.1.0.0
 ...
 -rw-r--r-- 1 sei sei  829936 Jun 22 18:40 libssl.a
 lrwxrwxrwx 1 sei sei  15 Jun 22 18:40 libssl.so - libssl.so.1.0.0
 -r-xr-xr-x 1 sei sei  549375 Jun 22 18:40 libssl.so.1.0.0

 What does not work mean? Any errors (which) or is mod_ssl still linked 
 against the shared libs?

I think you might have been mislead by the naming of the
--enable-ssl-staticlib-deps option: it does not have the effect of
forcing mod_ssl.so to be linked statically - it only adds those those
libraries which are suitable for static linking (see the documentation
on --static in pkg-config(1)).

The essential point is that the $(BLD_PREFIX)/lib directory must not
include any shared libraries (see also
https://mail-archives.apache.org/mod_mbox/httpd-dev/201504.mbox/%3C554072B0.40708%40velox.ch%3E).
As long as libtool finds shared libraries in this directory, it will
prefer them over the static ones.

Kaspar

Re: Using UPN from subjectAltName with SSLUserName

[Kaspar Brand]

On 19.06.2015 16:51, Jan Pazdziora wrote:
 On Thu, Jun 18, 2015 at 12:22:21PM +0200, Yann Ylavic wrote:
 I think a more generic way would to have something like
 SSL_CLIENT_OID_oid_n, so that we wouldn't have to add a new field
 each time.
 In this case, that would be: SSL_CLIENT_OID_1.3.6.1.4.1.311.20.2.3_n.

The point with the otherName SAN type is that it's yet another bag of
potentially arbitrary ASN.1 stuff, actually (not just simple strings, as
is the case for rfc822Name or dNSName):

   GeneralName ::= CHOICE {
otherName   [0] OtherName,
rfc822Name  [1] IA5String,
dNSName [2] IA5String,
x400Address [3] ORAddress,
directoryName   [4] Name,
ediPartyName[5] EDIPartyName,
uniformResourceIdentifier   [6] IA5String,
iPAddress   [7] OCTET STRING,
registeredID[8] OBJECT IDENTIFIER }

   OtherName ::= SEQUENCE {
type-idOBJECT IDENTIFIER,
value  [0] EXPLICIT ANY DEFINED BY type-id }
^^

(See RFC 7299 section 3.14 for the otherName forms defined by the PKIX
WG in the past.)

While Microsoft's UPN happens to be a very simple case (the value is
just a bare UTF8String here), this need not be true for other forms
of otherName.

Adding support for msUPN seems useful, but it's really something which
needs special-case coding in ssl_util_ssl.c:modssl_X509_getSAN(). I
suggest using SSL_{CLIENT,SERVER}_SAN_OTHER_msUPN_* for the variable
name(s), to make it clear that it's a subjectAltName entry of type
otherName. Then, in the code for GEN_OTHERNAME, specifically look for
this otherName form via NID_ms_upn - as only in this case, you
can be sure to expect a simple UTF8String in otherName-value
(strongSwan's openssl_x509.c might be a source of inspiration for coding
this).

Note that for exposing the msUPN variables with StdEnvVars, you also
need to adapt ssl_engine_vars.c:modssl_var_extract_san_entries().

Kaspar

Re: mod_ssl: Reading dhparams and ecparams not only from the first certificate file

[Kaspar Brand]

On 26.05.2015 10:33, Rainer Jung wrote:
 I find it questionable. I would find it more natural to embed the params 
 in the cert files they apply to, so e.g. the DH params in the RSA cert 
 file and the EC params in the ECDH cert file and also to not require a 
 special order for the files which at the end we do not check. Since 
 missing the embedded params goes unnoticed (finding them is only a DEBUG 
 log line) it is not very user friendly.

When I added this with r1527295, I didn't expect custom [EC]DH
parameters in a certificate file to be the typical case for a mod_ssl
configuration - and even in the light of Logjam, I don't think that we
would want to recommend creating custom DH parameters for the average
admin. As long as 2048-bit RSA keys are configured (the standard for
certs issued by publicly-trusted CAs these days), there's nothing wrong
with relying on the built-in DH parameters, i.e. those from RFC 3526. [1]

 Can't we simply try to read DH and ECC params from every certificate 
 file and stop in each of the two cases when we have found some? That 
 would tighten the user unfriendlyness to the case of having multiple 
 inconsistent parameters embedded in different cert files. And even that 
 could be checked and logged as a warning.

I don't have strong feelings on this, but am not sure if it's worth
adding more code to address this specific case. My guess is that
multi-cert virtual host configurations with OpenSSL  1.0.2 are
extremely rare, since they are prone to the
one-intermediate-CA-cert-only issue, and with OpenSSL 1.0.2 or later,
SSLOpenSSLConfCmd is definitely preferrable.

As far as your observation to embed the params in the cert files they
apply to is concerned, I think there might be a misunderstanding here:
the [EC]DH parameters are orthogonal to the authentication algorithm -
for an RSA key, both are applicable (cf. openssl ciphers -v aRSA+DHE and
openssl ciphers -v aRSA+ECDHE).

 That means if you start mixing embedded keys and separate key files,

I would definitely discourage from doing so, and wouldn't bother with
adding configuration code to address such cases (would introduce
unneeded complexity). Putting the the private key into the
SSLCertificateFile has been discouraged since the 2.0 release, actually
- see the SSLCertificateKeyFile docs added with r93825. What is probably
missing is a more prominent notice in the section on SSLCertificateFile.

Kaspar


[1] The weakdh.org site needs an update on this, as acknowledged by a
team member meanwhile, see
https://www.ietf.org/mail-archive/web/tls/current/msg16515.html

Re: svn commit: r1677149 - in /httpd/httpd/trunk/modules/ssl: ssl_util_ssl.c ssl_util_ssl.h

[Kaspar Brand]

On 01.05.2015 16:29, s...@apache.org wrote:
 Author: stsp
 Date: Fri May  1 14:28:59 2015
 New Revision: 1677149
 
 URL: http://svn.apache.org/r1677149
 Log:
 mod_ssl namespacing: Make SSL_ASN1_STRING_to_utf8 a static function inside
 ssl_util_ssl.c (no callers outside this file). The new static function name
 chosen is convert_asn1_to_utf8, based on the assumption that neither SSL_
 nor ASN1_ are safe prefixes to use without potential future overlap.

Thanks for pushing ahead with the namespace cleanup, Stefan. I'm fine
with making the function static, but would suggest to rename it to
asn1_string_to_utf8 instead - first, because it's really limited to
ASN.1 strings (doesn't deal with arbitrary ASN.1 data), and second,
because the _to_ already implies a conversion (plus it matches the
naming of the other comparable functions in ssl_util_ssl.c).

Kaspar

Re: mod_ssl: inline SSL_X509_INFO_load_path(); please review

[Kaspar Brand]

On 01.05.2015 17:11, Stefan Sperling wrote:
 I believe SSL_X509_INFO_load_path() should be inlined into
 its only caller.

I'm +1 for this. The Low-Level CA Certificate Loading part in
ssl_util_ssl.c is / was only used by ssl_init_proxy_certs, so I would be
in favor of also moving SSL_X509_INFO_load_file to ssl_engine_init.c
(and making it static).

 Regarding the removed comment about merging the dir-read loop
 with another one: I don't think that's worth it.

If we can get rid of code duplication on this occasion, then I think we
should do so - it makes future maintenance easier if there is common
code for loading CA files from a directory, be that for client
authentication (SSLCACertificatePath) or for proxy connections
(SSLProxyCACertificatePath).

Kaspar

Re: ALPN patch comments

[Kaspar Brand]

On 27.04.2015 17:04, Stefan Eissing wrote:
 Am 25.04.2015 um 11:47 schrieb Kaspar Brand httpd-dev.2...@velox.ch:
 Only tested in terms of compiles both w/ and w/o HAVE_TLS_ALPN, so it
 certainly needs more eyes before a backport proposal could be made.
 There's also a TODO: we should have a mod_ssl configuration parameter
 in ssl_engine_kernel.c which I'm unsure to what it refers.
 
 The „TODO“ is a leftover from before SSLAlpnPreference was introduced.
 It can be removed.

I did some formatting cleanup in r1676709 and put a patch for 2.4.x
online under
https://people.apache.org/~kbrand/mod_ssl-2.4.x-alpn_2015-04-29.diff.
This should hopefully make it easier for people to test and review (it's
an amalgamation of ten revisions from trunk, see the top of the patch file).

Kaspar

Re: OpenSSL 1.02, PCRE 2.10

[Kaspar Brand]

On 28.04.2015 14:04, Tom Browder wrote:
 On Tue, Apr 28, 2015 at 6:45 AM, Eric Covener cove...@gmail.com wrote:
 about openssl 1.02 though -- what exactly do you see?
 
 I see this when attempting to start apache:
 
 /usr/local/apache2/bin/httpd: symbol lookup error:
 /usr/local/apache2/bin/httpd: undefined symbol: SSL_CONF_CTX_new
 
 Maybe I need to play tricks with ld.so.conf and openssl?

Depends on whether you built OpenSSL with or without shared libraries -
what are the contents of the /opt/openssl/lib directory?

 I have no system installed openssl,

Hmm, what platform is this? Are you sure there are no libcrypto/libssl
libraries somewhere under /usr?

 SSLDIR=/opt/openssl
 export LDFLAGS=-L${SSLDIR}/lib

This should not be needed.

 --enable-ssl   \
 --enable-ssl-staticlib-deps\
 --enable-mods-static=ssl   \
 --with-ssl=${SSLDIR}   \

--enable-mods-static=ssl is probably not really what you want - it
includes mod_ssl in the httpd binary itself, but other than that, it
doesn't have an impact on how mod_ssl is linked against libcrypto/libssl
(you might try to see what ldd /usr/local/apache2/bin/httpd says).

The most important thing, though, is making sure that the directory
which appears in the LDFLAGS/MOD_LDFLAGS lines of the ./configure
outputs (after the checking for user-provided OpenSSL base
directory...) in does not include any shared library files - only
static ones.

Kaspar

Re: OpenSSL 1.02, PCRE 2.10

[Kaspar Brand]

On 29.04.2015 15:06, Tom Browder wrote:
 On Wed, Apr 29, 2015 at 12:57 AM, Kaspar Brand httpd-dev.2...@velox.ch 
 wrote:
 On 28.04.2015 14:04, Tom Browder wrote:
 I have no system installed openssl,

 Hmm, what platform is this? Are you sure there are no libcrypto/libssl
 libraries somewhere under /usr?
 
 I used a netinst installation of Debian 7.  But I find I do have those
 libraries:
 
 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
 /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0

Ok. Debian has separate packages for the libraries and the command-line
tool, so no system installed openssl is true as far as the openssl
package is concerned. I'd bet that Debian is barely usable when the
libssl1.0.0 package is missing, though.

 configure: error: Crypto was requested but no crypto library could be
 enabled; specify the location of a crypto library using
 --with-openssl, --with-nss, etc.

This is actually APR-util configure stuff, so does not apply to mod_ssl
itself. Unless you really have a need for mod_session_crypto, just leave
out the --enable-crypto and --enable-session-crypto options, for the
time being (they are not needed for mod_ssl, and are probably just
making things more complicated than necessary right now).

 The question to me is: what exact configuration do I need?  Do I point
 to a path, or library, or a configure script?  I see nothing

For a statically linked mod_ssl, you need --enable-ssl
--with-ssl=/opt/openssl --enable-ssl-staticlib-deps (assuming that you
used --prefix=/opt/openssl for OpenSSL's ./config or ./Configure).

Kaspar

Re: LogLevel inheritance/merging for VirtualHost in 2.4.x (Re: SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS))

[Kaspar Brand]

On 23.02.2014 09:03, Kaspar Brand wrote:
 On 22.02.2014 19:17, Falco Schwarz wrote:
 Kaspar, I switched back to your version and realized, that the directive 
 SSLCertificateChainFile was always used in a VirtualHost.

 If the directive is in server scope, the warning is written correctly.   
   
 
 Yes, that's the underlying issue which changing cmd-server to NULL in
 the ap_log_error actually uncovers: it's a somewhat (at least IMO)
 unfortunate side effect of how the LogLevel for a new VirtualHost is
 inherited/merged from the global LogLevel directive, or more
 specifically, the order in which it happens.

For the record: I have now committed your suggested change (switching
from cmd-server to NULL) in r1676085, as it turned out to be the most
appropriate fix for this specific case - and does not have unwanted side
effects either. Proposed for backport to 2.4.x in r1676086.

Kaspar

Re: ALPN patch comments

[Kaspar Brand]

On 22.04.2015 18:54, Jim Jagielski wrote:
 For me the time seems right to rip NPN out of trunk and only backport
 the ALPN code to 2.4.

 
 I'd be +1 for that.

So, to get one step further, and since there were no explicit objections
to removing NPN support so far (or arguments for keeping it, FWIW), I
went ahead and took a stab at this with r1676004.

Only tested in terms of compiles both w/ and w/o HAVE_TLS_ALPN, so it
certainly needs more eyes before a backport proposal could be made.
There's also a TODO: we should have a mod_ssl configuration parameter
in ssl_engine_kernel.c which I'm unsure to what it refers.

Kaspar

Re: SSLDisableCRLCaching, is it even possible in 2.4.x?

[Kaspar Brand]

On 22.04.2015 10:36, Jan Kaluža wrote:
 On 04/22/2015 09:50 AM, Kaspar Brand wrote:
 Fiddling with OpenSSL internals
 looks rather scary to me, at least at first sight - perhaps there's an
 API for clearing a CRL store in OpenSSL?
 
 Unfortunately there's no such API in OpenSSL. There's caching flag in 
 X509_STORE struct, but it's never used for anything actually.
 
 Maybe it would be better idea to implement that in OpenSSL

+1 for this, indeed. It would be good to not repeat history - i.e., add
code to mod_ssl which actually belongs into OpenSSL (specifically in
this case, where we would operate on low-level OpenSSL structures, which
looks like a fairly brittle approach).

 I was hoping to have this feature in httpd at first.

Understandable from an httpd package maintainer's point of view, I
agree. Could a temporary patch to your vendor OpenSSL package be a
short-term approach, with the long-term goal of getting it added as an
offical API into OpenSSL 1.0.something?

Kaspar

Re: ALPN patch comments

[Kaspar Brand]

On 22.04.2015 10:52, Stefan Eissing wrote:
 I made two small patches based on the feedback from Kaspar. One for
 the code and one for the documentation.

Thanks. In the patch for ssl_private.h, the complete NPN block should
actually be dropped - the same block is are already part of
ssl_private.h, just 10 lines above.

 However there are a lot of openssl 1.0.1 installations out there 
 where httpd 2.4 is deployed which already talk NPN

a lot of... which already talk NPN? I have a bit a hard time in
following this argument: since mod_ssl in 2.4 doesn't have NPN, this
suggests that these installations currently rely on custom patches in
any case - so I wouldn't expect there to be a lot of (or I might be
missing the real point).

 and it might take some time for getting ALPN support from the
 distros. Which would mean more people building and deploying their
 own SSL libraries/patching mod_ssl and having no auto update, if they
 want to use SPDY or HTTP/2.

I don't find this reasoning very convincing... if we look at
distributions with long term support (which is the sort of thing to
consider for running a production HTTP server), then we see that they
are now at 2.4.6 (RHEL), 2.4.7 (Ubuntu), 2.4.10 (SLES) or similar. And
they usually stay with these versions for the whole OS release lifetime,
only security fixes are backported (new features only in exceptional
cases). I.e., it's highly unlikely that admins could rely on the
vendor-supplied httpd package to get NPN in the next, say, 12 months.
auto update typically means security fixes only.

OTOH, if a distributor is really going from 2.4.x to 2.4-latest this or
next year, then I'd say that chances are quite high that he also
upgrades to OpenSSL 1.0.2 at the same time (in particular given the
increased pace for new OpenSSL releases and the faster EOL timelines,
see https://www.openssl.org/about/releasestrat.html).

For me the time seems right to rip NPN out of trunk and only backport
the ALPN code to 2.4.

Kaspar

Re: svn commit: r1674542 - in /httpd/httpd/trunk: acinclude.m4 modules/ssl/ssl_engine_rand.c

[Kaspar Brand]

On 22.04.2015 10:12, Stefan Sperling wrote:
 On Wed, Apr 22, 2015 at 09:29:49AM +0200, Kaspar Brand wrote:
 Sorry for having missed this in my previous review: we should also
 #ifdef the SSL_RSSRC_EGD case in
 ssl_engine_config.c:ssl_cmd_SSLRandomSeed(), to make sure that egd:...
 settings are not silently ignored when mod_ssl is compiled against
 LibreSSL. Either let the failure then be detected by the
 ssl_util_path_check, or (probably better) reject it similar to how it's
 done for SSLCompression, SSLHonorCipherOrder etc.

 Kaspar
 
 Thanks, good catch.
 
 Is this fine?

Looks good to me, yes - thanks.

Kaspar

Re: ALPN patch comments

[Kaspar Brand]

On 22.04.2015 18:45, Stefan Eissing wrote:
 I understand your argument. My pov is of someone trying to bring
 http/2 to the people. While bringing a new httpd on an existing
 system seems easy, installing a new system openssl is more
 challenging with its dependencies and the changes in hiding non
 public parts of their API.

It doesn't necessarily mean replacing the system OpenSSL version. A
separately built version (static libs only, which is OpenSSL's default)
is fine for mod_ssl - just specify via ./configure --with-ssl=. I
believe Ivan Ristic once had something on it in his blog, it's a fairly
straightforward and painless option for an admin, I think.

Kaspar

Re: ALPN patch comments

[Kaspar Brand]

On 22.04.2015 21:30, Rainer Jung wrote:
 Am 22.04.2015 um 17:49 schrieb Kaspar Brand:
 Thanks. In the patch for ssl_private.h, the complete NPN block should
 actually be dropped - the same block is are already part of
 ssl_private.h, just 10 lines above.
 
 I've kept the new one and dropped the old one in r1675459.

It's nitpicking, but... the old one was already correct, actually. All
this stuff is in a larger #if !defined(OPENSSL_NO_TLSEXT) ... block,
so there's no need to repeat NO_TLSEXT.

I'd rather get consensus on completely dropping HAVE_TLS_NPN from trunk
anyway, though, so it's really a very minor point right now ;-)

Kaspar

Re: svn commit: r1674542 - in /httpd/httpd/trunk: acinclude.m4 modules/ssl/ssl_engine_rand.c

[Kaspar Brand]

On 18.04.2015 19:03, s...@apache.org wrote:
 Author: stsp
 Date: Sat Apr 18 17:03:47 2015
 New Revision: 1674542
 
 URL: http://svn.apache.org/r1674542
 Log:
 mod_ssl: Check for RAND_egd() at configure time and only use it if present.
 Fixes the build with LibreSSL which does not provide this function.
 
 Modified:
 httpd/httpd/trunk/acinclude.m4
 httpd/httpd/trunk/modules/ssl/ssl_engine_rand.c

Sorry for having missed this in my previous review: we should also
#ifdef the SSL_RSSRC_EGD case in
ssl_engine_config.c:ssl_cmd_SSLRandomSeed(), to make sure that egd:...
settings are not silently ignored when mod_ssl is compiled against
LibreSSL. Either let the failure then be detected by the
ssl_util_path_check, or (probably better) reject it similar to how it's
done for SSLCompression, SSLHonorCipherOrder etc.

Kaspar

Re: SSLDisableCRLCaching, is it even possible in 2.4.x?

[Kaspar Brand]

On 21.04.2015 12:20, Jan Kaluža wrote:
 we used to have a patch against httpd-2.2.15 to add SSLDisableCRLCaching 
 option to not cache CRLs. I was trying to adapt this patch for 
 httpd-trunk and eventually include it upstream but now I'm in dead end.
 
 The patch removes all the CRLs from the per-server_rec OpenSSL cache 
 created in ssl_init_ctx_crl (OpenSSL caches the CRLs in 
 X509_store.objs). This all works properly, but I'm thinking about 
 thread-safety.

Starting with 2.3.15 (https://svn.apache.org/r1165056), CRL checking was
completely delegated to OpenSSL, so it would be a bit surprising to me
if that patch can be ported to trunk. Fiddling with OpenSSL internals
looks rather scary to me, at least at first sight - perhaps there's an
API for clearing a CRL store in OpenSSL?

Kaspar

Re: check for RAND_egd at configure time

[Kaspar Brand]

On 16.04.2015 22:57, Stefan Sperling wrote:
 On Wed, Apr 15, 2015 at 08:43:04PM +0200, Stefan Sperling wrote:
 LibreSSL does not provide the RAND_egd() function.

 This patch adds a configure check to allow building mod_ssl with LibreSSL.
 
 Updated version following Kaspar Brand's suggestion to move into acinclude.m4.
 
 Index: acinclude.m4
 ===
 --- acinclude.m4  (revision 1673798)
 +++ acinclude.m4  (working copy)
 @@ -598,6 +598,11 @@ AC_DEFUN(APACHE_CHECK_OPENSSL,[
if test x$liberrors != x; then
  AC_MSG_WARN([OpenSSL libraries are unusable])
fi
 +  have_rand_egd=no
 +  AC_CHECK_LIB(crypto, RAND_egd, [have_rand_egd=yes])
 +  if test $have_rand_egd = yes; then
 +AC_DEFINE([HAVE_RAND_EGD], [1], [Define if RAND_egd exists.])
 +  fi
  else
AC_MSG_WARN([OpenSSL version is too old])
  fi

I was actually thinking about

Index: acinclude.m4
===
--- acinclude.m4(revision 1673835)
+++ acinclude.m4(working copy)
@@ -594,7 +594,7 @@
   liberrors=
   AC_CHECK_HEADERS([openssl/engine.h])
   AC_CHECK_FUNCS([SSLeay_version SSL_CTX_new], [], [liberrors=yes])
-  AC_CHECK_FUNCS([ENGINE_init ENGINE_load_builtin_engines])
+  AC_CHECK_FUNCS([ENGINE_init ENGINE_load_builtin_engines RAND_egd])
   if test x$liberrors != x; then
 AC_MSG_WARN([OpenSSL libraries are unusable])
   fi

... or does that not fit in this case?

Kaspar

Re: svn commit: r1672014 - in /httpd/httpd/trunk: CHANGES server/config.c

[Kaspar Brand]

On 14.04.2015 06:54, Kaspar Brand wrote:
 On 13.04.2015 22:05, Ruediger Pluem wrote:
 Shouldn't we only do that in case that vit-log.level is set to 
 main_server-log.level?
 Don't we lose the configuration done by the user for this particular host 
 otherwise?
 
 Yes, you're right - thanks for the review. It also noticed this in the
 meantime, and when I tried to come up with a fix, more special cases
 were turning up (whether main_server-log.level is still at
 DEFAULT_LOGLEVEL might also have to be taken into account).
 
 Hopefully I'll find time for more closely examining this tomorrow.
 Otherwise I will revert r1672014, as it is clearly not a complete
 solution yet.

Reverted r1672014. After more digging, I think there's no practical way
to base the decision whether to reset on the current value of
virt-log.level when reaching ap_fixup_virtual_hosts - too many
conceivable combinations of global LogLevel vs. per-vhost LogLevel (and
the order they appear in the config). Extending the ap_logconf struct
seems unavoidable if the approach with adjustments in
ap_init_virtual_host/ap_fixup_virtual_hosts is the right one.

Another idea would be to apply the default log level in log_error_core()
when we encounter APLOG_UNSET, as illustrated by the attached patch.
Maybe doing this check in each log_error_core() invocation adds too much
overhead, given that it's actually just addressing an issue which occurs
at startup/reload?

The other option to fix the problem which originally triggered this
investigation would be to simply replace cmd-server in
ssl_engine_config.c:836 with NULL, though it would only fix this
particular case, and not help with other places with the same underlying
problem.

Kaspar
Index: include/http_log.h
===
--- include/http_log.h  (revision 1673835)
+++ include/http_log.h  (working copy)
@@ -128,6 +128,8 @@ extern C {
  */
 #define APLOG_NO_MODULE -1
 
+#define APLOG_UNSET (APLOG_NO_MODULE - 1)
+
 #ifdef __cplusplus
 /**
  * C++ modules must invoke ::APLOG_USE_MODULE or ::AP_DECLARE_MODULE in
Index: server/config.c
===
--- server/config.c (revision 1673838)
+++ server/config.c (working copy)
@@ -52,7 +52,6 @@
 #include util_varbuf.h
 #include mpm_common.h
 
-#define APLOG_UNSET   (APLOG_NO_MODULE - 1)
 /* we know core's module_index is 0 */
 #undef APLOG_MODULE_INDEX
 #define APLOG_MODULE_INDEX AP_CORE_MODULE_INDEX
Index: server/log.c
===
--- server/log.c(revision 1673835)
+++ server/log.c(working copy)
@@ -1075,6 +1075,11 @@ static void log_error_core(const char *file, int l
 int configured_level = r ? ap_get_request_module_loglevel(r, 
module_index):
c ? ap_get_conn_server_module_loglevel(c, s, 
module_index) :
ap_get_server_module_loglevel(s, 
module_index);
+
+/* Temporarily adjust to the default if the level hasn't been set yet 
*/
+if (configured_level == APLOG_UNSET)
+configured_level = ap_default_loglevel;
+
 /*
  * If we are doing normal logging, don't log messages that are
  * above the module's log level unless it is a startup/shutdown notice

Re: namespacing in mod_ssl

[Kaspar Brand]

On 15.04.2015 18:36, Stefan Sperling wrote:
 However, the actual issue here is that mod_ssl is squatting the SSL_ 
 namespace.
 Historically this may have made sense (it seems mod_ssl and OpenSSL have
 shared history/authors). Bill Rowe suggested to try moving mod_ssl's
 functions into the ap_ namespace to avoid such clashes in the future.

Agreed that mod_ssl should avoid stepping into the SSL_* yard. As
pointed out by Jeff, ap_* is fairly foreign in the mod_ssl case, though,
and my preference is for s/SSL_/ssl_/ for functions and
s/SSL_/MODSSL_/ for constants (in the latter case, there's actually
quite some more stuff lurking - SSL_OPT_*, SSL_PROTOCOL_* etc.).

 I'm not sure how README.dsov.ps should be regenerated.
 It contains a refence to SSL_get_app_data2().
 For now I've only updated the .dsov.fig file.

With fig2dev probably. Though in this simple case, a direct edit of
README.dsov.ps seems sufficient.

Kaspar

Re: check for RAND_egd at configure time

[Kaspar Brand]

On 15.04.2015 20:43, Stefan Sperling wrote:
 LibreSSL does not provide the RAND_egd() function.
 
 This patch adds a configure check to allow building mod_ssl with LibreSSL.
 
 Index: modules/ssl/config.m4
 ===
 --- modules/ssl/config.m4 (revision 1673798)
 +++ modules/ssl/config.m4 (working copy)
 @@ -44,6 +44,12 @@
 # structure, so ask libtool to hide everything else:
 APR_ADDTO(MOD_SSL_LDADD, [-export-symbols-regex ssl_module])
  fi
 +
 +have_rand_egd=no
 +AC_CHECK_LIB(crypto, RAND_egd, [have_rand_egd=yes])
 +if test $have_rand_egd = yes; then
 +AC_DEFINE([HAVE_RAND_EGD], [1], [Define if RAND_egd exists.])
 +fi
  else
  enable_ssl=no
  fi

We already have a couple of OpenSSL function checks in (the top-level)
acinclude.m4 - can you add it there?

Kaspar

Re: svn commit: r1672014 - in /httpd/httpd/trunk: CHANGES server/config.c

[Kaspar Brand]

On 13.04.2015 22:05, Ruediger Pluem wrote:
 On 04/08/2015 09:33 AM, kbr...@apache.org wrote:
 Modified: httpd/httpd/trunk/server/config.c
 URL: 
 http://svn.apache.org/viewvc/httpd/httpd/trunk/server/config.c?rev=1672014r1=1672013r2=1672014view=diff
 ==
 --- httpd/httpd/trunk/server/config.c (original)
 +++ httpd/httpd/trunk/server/config.c Wed Apr  8 07:33:39 2015
 @@ -2194,7 +2194,7 @@ AP_CORE_DECLARE(const char *) ap_init_vi
  s-keep_alive = -1;
  s-keep_alive_max = -1;
  s-error_log = main_server-error_log;
 -s-log.level = APLOG_UNSET;
 +s-log.level = main_server-log.level;
  s-log.module_levels = NULL;
  /* useful default, otherwise we get a port of 0 on redirects */
  s-port = main_server-port;
 @@ -2286,6 +2286,7 @@ AP_DECLARE(void) ap_fixup_virtual_hosts(
  if (virt-keep_alive_max == -1)
  virt-keep_alive_max = main_server-keep_alive_max;
  
 +virt-log.level = APLOG_UNSET;
 
 Shouldn't we only do that in case that vit-log.level is set to 
 main_server-log.level?
 Don't we lose the configuration done by the user for this particular host 
 otherwise?

Yes, you're right - thanks for the review. It also noticed this in the
meantime, and when I tried to come up with a fix, more special cases
were turning up (whether main_server-log.level is still at
DEFAULT_LOGLEVEL might also have to be taken into account).

Hopefully I'll find time for more closely examining this tomorrow.
Otherwise I will revert r1672014, as it is clearly not a complete
solution yet.

Kaspar

Re: svn commit: r1670397 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c mod_ssl.h ssl_engine_config.c ssl_engine_io.c ssl_private.h

[Kaspar Brand]

On 31.03.2015 19:12, j...@apache.org wrote:
 Author: jim
 Date: Tue Mar 31 17:12:51 2015
 New Revision: 1670397
 
 URL: http://svn.apache.org/r1670397
 Log:
 ALPN support, based on mod_spdy/mod_h2 patch set
 
 Modified:
 httpd/httpd/trunk/modules/ssl/mod_ssl.c
 httpd/httpd/trunk/modules/ssl/mod_ssl.h
 httpd/httpd/trunk/modules/ssl/ssl_engine_config.c
 httpd/httpd/trunk/modules/ssl/ssl_engine_io.c
 httpd/httpd/trunk/modules/ssl/ssl_private.h
 
 Modified: httpd/httpd/trunk/modules/ssl/mod_ssl.c
 URL: 
 http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/mod_ssl.c?rev=1670397r1=1670396r2=1670397view=diff
 ==
 --- httpd/httpd/trunk/modules/ssl/mod_ssl.c (original)
 +++ httpd/httpd/trunk/modules/ssl/mod_ssl.c Tue Mar 31 17:12:51 2015
 @@ -283,6 +283,12 @@ static const command_rec ssl_config_cmds
  OpenSSL configuration command)
  #endif
  
 +#if defined(HAVE_TLS_ALPN) || defined(HAVE_TLS_NPN)
 +SSL_CMD_SRV(AlpnPreference, ITERATE,
 +Preference in Application-Layer Protocol Negotiation 
 (ALPN), 
 +protocols are chosed in the specified order)
 +#endif
 +

s/chosed/chosen/ - and please add docs for this to mod_ssl.xml, too.


 Modified: httpd/httpd/trunk/modules/ssl/ssl_private.h
 URL: 
 http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_private.h?rev=1670397r1=1670396r2=1670397view=diff
 ==
 --- httpd/httpd/trunk/modules/ssl/ssl_private.h (original)
 +++ httpd/httpd/trunk/modules/ssl/ssl_private.h Tue Mar 31 17:12:51 2015
 @@ -181,6 +181,16 @@
  #define HAVE_TLS_NPN
  #endif
  
 +/* ALPN Protocol Negotiation */
 +#if OPENSSL_VERSION_NUMBER = 0x10002000L  !defined(OPENSSL_NO_TLSEXT)
 +#define HAVE_TLS_ALPN
 +#endif
 +
 +/* Next Protocol Negotiation */
 +#if !defined(OPENSSL_NO_NEXTPROTONEG)  !defined(OPENSSL_NO_TLSEXT)  
 defined(OPENSSL_NPN_NEGOTIATED)
 +#define HAVE_TLS_NPN
 +#endif
 +

Instead of hardcoding OpenSSL version numbers, we should rely on
feature-based detection - in this case, we can use

  #if defined(TLSEXT_TYPE_application_layer_protocol_negotiation)

(see
https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=b0d6f3c58fc86756574b410cb6a32589477d3954,
the ALPN backport to 1.0.2)

Also, the two  !defined(OPENSSL_NO_TLSEXT) can be dropped, since
we're already in a larger #if !defined(OPENSSL_NO_TLSEXT) ... block.


And with regard to:

On 01.04.2015 22:33, Jim Jagielski wrote:
 Yeah, I agree. Right now, trunk pretty much uses
 
   #ifdef HAVE_TLS_ALPN
   blah blah
   #endif
   #ifdef HAVE_TLS_NPN
   blah2 blah2
   #endif
 
 Instead of
 
   #if defined(HAVE_TLS_NPN) || defined(HAVE_TLS_ALPN)
 
 so that ripping out NPN would be easier. The question is
 which to use for 2.4...

My vote is clearly for only having ALPN in 2.4 - implementations of
draft protocol versions shouldn't creep into stable httpd
releases, in particular when they have been superseded by a
standards-track RFC meanwhile (RFC 7301 was published in July 2014, and
even Google has announced its plans to drop NPN early next year,
http://blog.chromium.org/2015/02/hello-http2-goodbye-spdy-http-is_9.html).

Kaspar

Re: [Patch] mod_ssl SSL_CLIENT_CERT_SNAI - access to client certificate serialNumber and issuer

[Kaspar Brand]

On 05.02.2015 19:22, Graham Leggett wrote:
 What I’ve done is broken the problem into two sections, the first is
 to give a unique handle on the certificate that can be used in LDAP
 queries. RFC4523 defines a CertificateExactAssertion, which is “{
 serialNumber decimal-serial-number-string, issuer issuer-string
 }”.

It's probably a rarely used format, but if the CertificateExactAssertion
thing is useful for LDAP querying, then fine with me. One caveat
to keep in mind is that GSER (the Generic String Encoding Rules,
on which RFC 4523 relies) do not define a canonical encoding,
as stated in RFC 3641 section 5. The following strings for identifying
the certificate from RFC 5280 appendix C.2 are equivalent according
to RFC 4523 (and RFC 4514), e.g.:

{serialNumber 18,issuer rdnSequence:CN=Example CA,DC=example,DC=com}
{ serialNumber 18, issuer 
rdnSequence:CN=#130A4578616D706C65204341,DC=#16076578616D706C65,DC=#1603636F6D
 }

 The attached patch provides an SSL_CLIENT_CERT_SNAI variable that
 gives the above string, which in turn can be used for LDAP queries
 against the userCertificate attribute (or another attribute for
 directories that don’t support certificateExactMatch).

Implementation-wise, there's some room for improvement:

- ..._SNAI sounds like fairly cryptic naming to me, I would prefer
an explicit RFC reference, e.g. SSL_CLIENT_CERT_RFC4523_CEA (searching
for cea in that RFC will quickly turn up its definition)

- the syntax of the value isn't correct yet: your code does not add
the rdnSequence: before the issuer DN, and it needs to be quoted,

- instead of adding another BIO_* dance to ssl_engine_vars.c,
relying on SSL_X509_NAME_to_string (and apr_pstrcat) allows saving
quite some code

- to also export the variable with SSLOptions StdEnvVars, you need
to add it to ssl_hook_Fixup_vars[] in ssl_engine_kernel.c, too

 The second part of the problem is “is this certificate the one we’re
 looking for”. The formal definition of certificateExactMatch doesn’t
 allow for binary matches of a cert, and some directories allow it,
 and some don’t. What I have in mind for this is to create a mechanism
 that allows mod_ssl to expose binary data like the DER of the cert
 and allow other modules to query that data and check it. In this case
 mod_authnz_ldap can then optionally verify that the cert returned
 from the directory matches the cert returned by mod_ssl.

That's what I meant when suggesting something like SSL_CLIENT_CERT_DER
in my last message in the Re: [Patch] mod_ssl SSL_CLIENT_CERT_SUBJECTS -
access to full client certificate chain thread, yes. I would probably
go for Base64 encoded DER values, to avoid '\0'-byte issues when
shuffling things around (i.e., it would be PEM without headers,
so to say).

Kaspar

Re: AW: svn commit: r1650047 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_ssl.xml modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_engine_vars.c modules/ssl/ssl_private.h modules/ssl/ssl_util_s

[Kaspar Brand]

On 07.01.2015 15:17, Plüm, Rüdiger, Vodafone Group wrote:
 Why checking for FALSE and !*ids? Shouldn't the empty array cause a
 return of FALSE?

 Not necessarily. Early returns in SSL_X509_getSAN (when argument
 checking etc. is taking place) may return a NULL pointer for the array,
 
 But don't they always return FALSE in this case as well? If yes a check for 
 FALSE should be sufficient,
 or if we only want to ensure that the array is available for !*ids. My point 
 is more: Why do we need to do both checks. Wouldn't be one sufficient either?

Ah, my first answer was missing an essential part, I think. Only
checking for

 SSL_X509_getSAN(p, x509, GEN_DNS, -1, ids) == FALSE

would mean that we would stop when we get back an empty array from
SSL_X509_getSAN. For SSL_X509_getIDs, however, we want to continue and
push the CN-IDs to the array (i.e., in the case of a certificate without
a subjectAltName extension, which was relatively common until a few
years ago). That's the reason for the additional  !*ids - to make
sure that we continue when getting back an empty array from SSL_X509_getSAN.

Kaspar

Re: svn commit: r1650047 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_ssl.xml modules/ssl/ssl_engine_kernel.c modules/ssl/ssl_engine_vars.c modules/ssl/ssl_private.h modules/ssl/ssl_util_ssl.c

[Kaspar Brand]

On 07.01.2015 14:03, Ruediger Pluem wrote:
 +/* return an array of (RFC 6125 coined) DNS-IDs and CN-IDs in a certificate 
 */
 +BOOL SSL_X509_getIDs(apr_pool_t *p, X509 *x509, apr_array_header_t **ids)
 +{
 +X509_NAME *subj;
 +int i = -1;
 +
 +/* First, the DNS-IDs (dNSName entries in the subjectAltName extension) 
 */
 +if (!x509 ||
 +(SSL_X509_getSAN(p, x509, GEN_DNS, -1, ids) == FALSE  !*ids)) {
 +*ids = NULL;
 
 Why checking for FALSE and !*ids? Shouldn't the empty array cause a return of 
 FALSE?

Not necessarily. Early returns in SSL_X509_getSAN (when argument
checking etc. is taking place) may return a NULL pointer for the array,
and since we want to add the CN-ID elements further down here in
SSL_X509_getIDs, we have to make sure that we really have an array to
push to.

Kaspar

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

[Kaspar Brand]

On 09.11.2014 14:30, Graham Leggett wrote:
 On 06 Nov 2014, at 8:05 AM, Kaspar Brand httpd-dev.2...@velox.ch wrote:
 
 Is there another way to do this?

 Manually performing what certificateExactMatch is specifying, I would
 say - i.e., use the (SSL_CLIENT_M_SERIAL,SSL_CLIENT_I_DN) tuple as a
 unique identifier for a specific client certificate.
 
 Imagine I trust two roots, A and X, where X has been compromised.
 
 I authorize the certificate chain A-B-C to perform a specific
 action. What stops the root X from issuing an intermediate
 certificate with subject “B” and a leaf certificate with subject “C”
 to produce a chain that goes X-B-C, and the client provides both
 the intermediate cert B and leaf certificate C during the SSL
 handshake?
 
 In other words, if I only consider the serial number and issuer
 during authorization, what stops a compromised-but-still-trusted CA
 from issuing an intermediate cert that replaces another trusted
 issuer?

We seem to talk about two separate issues, I think: (1) to uniquely
identify a certificate and store that identity in an LDAP directory
(from your 1 Nov message), and (2) 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.

For (2), which is about authorization, the certification path can be a
suitable criterion (note that X.509 also defines a CertificationPath
ASN.1 type in this context, though in a more complex/complete way than
what you're proposing). For (1), however, it's not sufficient to pick
the subjectDN from an end-entity certificate - even from a trusted
issuing CA, you may expect multiple certificates with the same issuer
(think of dual-keying e.g.). Or another case to take into account is
that an end-endity certificate may have an empty subject DN (RFC 5280
section 4.1.2.6), in which case the concatenation of the subjectDNs (the
proposed SSL_CLIENT_CERT_SUBJECTS string) wouldn't work at all.

As pointed out by Tim Bannister meanwhile, comparing the complete
certificate against a userCertificate LDAP attribute would be the most
secure way to make sure that the user has indeed authenticated with the
certificate you require. If mod_authnz_ldap's Require ldap-attribute
could be extended to allow value definitions based on SSL_CLIENT_CERT,
then you wouldn't depend on CertificateExactMatch support in the LDAP
server (the PEM headers in SSL_CLIENT_CERT would have to be stripped
before comparing to the LDAP attribute, perhaps an additional var like
SSL_CLIENT_CERT_DER could be introduced if this makes things simpler in
mod_authnz_ldap).

Kaspar

Re: PR 53435, r101624, mod_ssl: error strings can't be loaded again once?

[Kaspar Brand]

On 12.11.2014 03:28, Dr Stephen Henson wrote:
 I just checked the sources and this was fixed in OpenSSL 0.9.7m just over 7
 years ago...

For 0.9.8, it was fixed with 0.9.8e:

https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=900f7a87760d1053127976480efcd71371787d6e

I.e., given that for 2.4.x, we still support 0.9.8a (and for 2.2.x,
even 0.9.6 something), the ERR_free_strings() call should probably be
wrapped by a suitable #if (OPENSSL_VERSION_NUMBER = 

Kaspar

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

[Kaspar Brand]

On 06.11.2014 14:19, Dirk-Willem van Gulik wrote:
 
 On 06 Nov 2014, at 14:14, Andreas B. regis...@progandy.de wrote:

 Am 06.11.2014 um 08:34 schrieb Dirk-Willem van Gulik:
 On 06 Nov 2014, at 07:05, Kaspar Brand httpd-dev.2...@velox.ch 
 mailto:httpd-dev.2...@velox.ch wrote:

 (i.e., we are again back at the point that uniqueness of an X.509
 certificate is achieved by its issuer DN plus serial number)
 And even that is LDAPs take on it

I beg to differ. It's X.509 in its purest sense. From clauses 11.1.1 and
11.2.1 of X.509:

 The PKI user object class is used in defining entries for objects
 that may be the subject of public-key certificates.

   pkiUser OBJECT-CLASS ::= {
   SUBCLASS OF  {top}
   KIND auxiliary
   MAY CONTAIN  {userCertificate}
   ID   id-oc-pkiUser }

 A user may obtain one or more public-key certificates from one or more CAs.
 The userCertificate attribute type contains the public-key certificates
 a user has obtained from one or more CAs.

   userCertificate ATTRIBUTE ::= {
   WITH SYNTAX Certificate
   EQUALITY MATCHING RULE  certificateExactMatch
   ID  id-at-userCertificate}

The matching rules in RFC 4523 (LDAP X.509 Schema) are those from
X.509, or as RFC 4523 says in section 1: As the semantics of these
elements are as defined in X.509 and X.521, knowledge of X.509 and X.521
is necessary to make use of the LDAP schema definitions provided herein.

 - in a lot of practical cases it gets more complex; especially if the
 leave of the  one but last intermediate is cross signed.

Sure, but trying to identify a certificate by its certification path
(and in particular, the other end of it, i.e. the root / trust
anchor), is an unworkable solution, as it ignores fundamental properties
of X.509.

 I would argue that the ‘best’ thing we can do is first on the SSL
 termination side — follow the chain; and if there we *conclude*
 that all is well - and we present the evidence of that conclusion
 ’to what is behind’.

Let me add that follow the chain (and use X509_verify_cert to get at
the trust anchor) may give inconsistent results depending on a) what
chain the client provides in the TLS handshake (RFC 5246 section 7.4.6)
and b) what intermediate CAs and trust anchors are configured
server-side (SSLCACertificate{File,Path}), and also on what OpenSSL
version is used - see e.g.
https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=d65b8b2162f33ac0d53dace588a0847ed827626c#patch1.

 And ideally make that as hard to mis-interpret. So Graham his
 idea of providing a single ‘unique' string which gives the DN’s
 in order (along with the usual SSL_CLIENT.. env vars; including
 the full ANS.1 if you are so inclined) is quite pragmatic. As
 that string is ‘unique’ within the promise the web frontend with
 its current settings is making.

It's pragmatic but incorrect, and is definitely not a promise which
mod_ssl can make. To repeat: I'm fine with adding support for
SSL_CLIENT_S_DN_n to mod_ssl, but am opposed to inventing custom schemes
for uniquely identifying a certificate and hardcode this into mod_ssl
(in the end, it would convey the message that SSL_CLIENT_CERT_SUBJECTS
is a sound solution for that problem, which it isn't).

 The issue is that in some systems (e.g. a medical one I am
 currently trying to come to terms with) the certs ar renewed very
 often; and the fingerprint does not stay stable. This is also an
 issue with using the serial and the issuer DN.

It seems that you're trying to solve an authorization issue with some
sort of certificate-to-identity mapping (strictly speaking, client
certificate authentication is about authenticating with a key, not with
an X.509 DN). Coming back to Graham's statement 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, the fallacy is
trying to rely on the path to the trust anchor. The proper thing is to
require the client certificate(s) to be issued by one or more specific
issuing CAs (which can be configured by means of an SSLRequire directive
which checks for specific SSL_CLIENT_I_DN or SSL_CLIENT_I_DN_x509
values, and optionally SSL_CLIENT_S_* things).

Kaspar

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

[Kaspar Brand]

On 02.11.2014 15:44, Graham Leggett wrote:
 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.

Given that ssl_var_lookup() is available for use in other modules, and
provided that in addition SSL_CLIENT_S_DN_n, we would export an
additional variable with the chain length (SSL_CLIENT_CERT_CHAIN_LENGTH
or similar), wouldn't it be possible to do the manipulations required by
mod_authnz_ldap in that module? mod_ssl really seems the wrong place to
me for implementing application-specific requirements (such as these
matryoshka doll-style subject DNs).

Kaspar

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

[Kaspar Brand]

On 05.11.2014 14:26, Graham Leggett wrote:
 The problem I am trying to solve is to find a practical way to
 integrate an SSL client cert identity with LDAP, in such a way where
 I can say “we recognise this certificate is mapped to that
 capability”. I am struggling to find an accurate indicator of “this
 certificate” (as opposed to “this similar looking certificate with a
 different chain”). Annoyingly the simplest solution - a simple binary
 match on the cert - isn’t supported by certificateExactMatch in most
 LDAP servers.

certificateExactMatch isn't really a binary match (i.e., a binary
comparison of the certificate's DER encoding or such). As its
description in RFC 4523 section 3.1 says:

The certificateExactMatch matching rule compares the presented
certificate exact assertion value with an attribute value of the
certificate syntax as described in clause 11.3.1 of [X.509].

And said clause from X.509 reads:

 11.3.1 Certificate exact match

 The certificate exact match rule compares for equality a presented
 value with an attribute value of type Certificate. It uniquely selects
 a single certificate.

   certificateExactMatch MATCHING-RULE ::= {
   SYNTAX  CertificateExactAssertion
   ID  id-mr-certificateExactMatch }

   CertificateExactAssertion ::= SEQUENCE {
   serialNumber  CertificateSerialNumber,
   issuerName }

 This matching rule returns TRUE if the components in the attribute
 value match those in the presented value.

(i.e., we are again back at the point that uniqueness of an X.509
certificate is achieved by its issuer DN plus serial number)

 Is there another way to do this?

Manually performing what certificateExactMatch is specifying, I would
say - i.e., use the (SSL_CLIENT_M_SERIAL,SSL_CLIENT_I_DN) tuple as a
unique identifier for a specific client certificate.

Kaspar

Re: Older clients stopped working after server disabled SSLv3

[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

[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: Older clients stopped working after server disabled SSLv3

[Kaspar Brand]

On 29.10.2014 16:42, Yann Ylavic wrote:
 On Wed, Oct 29, 2014 at 2:52 PM, Mikhail T. mi+t...@aldan.algebra.com wrote:
 That would solve our problem, though some may wonder about the subtle
 differences between any and all :-) More seriously, it would also make
 the config-files incompatible with earlier httpd-releases -- whereas the
 patch I linked to does not have this problem.

Definitely agreeing with Mikhail. Adding Any as another option is just
likely to cause even more confusion (and I'm also not in support of adding
things like safe, just for the records).

Without clear steps on how to reproduce the problem (what httpd version,
what OpenSSL version, what client, what SSLProtocol settings), I'm fairly
doubtful that there really is a problem here. From a quick glance at
OpenSSL's s23_srvr.c:ssl23_get_client_hello(), I fail to see any reason
why the current mod_ssl code in
ssl_engine_init.c:ssl_init_ctx_protocol() would disable the acceptance
of an SSLv2 compatible ClientHello when a single protocol setting (cases
like protocol == SSL_PROTOCOL_TLSV1) is active.

Reading further down on the serverfault entry referenced earlier [1],
the real OP (Matt Hughes, i.e. the one who posted to httpd-users, in
the thread mentioned by Jeff) meanwhile came to the conclusion that his
problem was a non-issue all along. Apache will accept SSLv2 handshake
with either of the configurations I posted above. In fact, I have no
problem to connect to httpd/mod_ssl with SSLProtocol TLSv1, when
using openssl s_client -cipher RC4-MD5 -connect ..., (provided that
RC4-MD5 is still enabled server-side). In that case, I'm seeing an
SSLv2 compatible hello, with TLS 1.0 getting negotiated in the end.

Kaspar

[1] 
http://serverfault.com/questions/637880/disabling-sslv3-but-still-supporting-sslv2hello-in-apache/

Re: [RFC] Enable OCSP Stapling by default in httpd trunk

[Kaspar Brand]

On 30.10.2014 15:51, Jeff Trawick wrote:
 IMO the present concerns with OCSP Stapling are:
 
 * not so clear that it has seen enough real-world testing; commented out
 sample configs and better documentation will help, as will enabling by
 default in trunk (just a little?)
 * related bugs 57121 and 57131
 
 A simple way to help with the broader issue raised in 57131, as well as fix
 57121, is to not hold the global mutex while communicating with a
 responder, with other handshakes completing with the existing response in
 the cache as long as it is valid, or with the appropriate
 communication-error response otherwise (some details omitted ;) ).
 
 There are a few other bugs currently open for less severe issues.
 
 TIA for your comments!

I'm -1 on this, under the assumption that 2.4.x would eventually also
turn it on by default (yes, I'm aware of PR 50740, and CABF trying to
push this).

While enabling it by default on trunk probably doesn't change much (in
my experience, very, very few people really compile and run trunk, I
would even claim that this applies to http devs, too), I feel that the
approach of let's turn it on by default and see how many people run
into problems (and bring them up on httpd-users etc.) isn't right.
Those interested in achieving a more widespread use should specifically
test OCSP stapling with mod_ssl, report their findings, file PRs on
Bugzilla (and if possible, also submit suitable patches).

The fundamental objection I have to enabling stapling by default in our
GA releases is that it would enable a phoning home feature (to the
CA's OCSP responders) as a side effect of configuring a certificate.
This is a setting I consider unacceptable for software published by the
Apache HTTP Server project - the default must be opt-in, not opt-out.

Kaspar

Re: svn commit: r1633730 - /httpd/httpd/trunk/docs/conf/extra/httpd-ssl.conf.in

[Kaspar Brand]

On 27.10.2014 12:55, Jeff Trawick wrote:
 Putting SSLUseStapling at global scope makes it easier for the admin, who
 may have had trouble getting SSL working in the first place.

I don't see yet how it makes it easier - my point is more that an
admin should consciously enable OCSP stapling when he is configuring a
certificate for a virtual host, i.e., SSLUseStapling should appear after
the SSLCertificateFile in the VirtualHost _default_:443 block. (This
applies even more to cases where people put their VirtualHost configs
into separate files - having a global setting inadvertently apply to
all VirtualHosts is something I would want to avoid.)

 I'm not aware
 of any real drawbacks.  Messages will be logged if stapling can't be
 performed for a particular certificate (missing certificate chain, no
 responder URL in certificate or in configuration), but that may be a good
 thing.  And the server will start up normally.

If the primary concern is that configuring mod_ssl (getting SSL
working as you put it) is too complex for the typical admin, then
streamlining our current httpd-ssl.conf would probably make more sense -
there's stuff in there which standard https sites almost never need
(SSLCACertificate{Path,File}, SSLCARevocation* etc., making it pretty
hard for an inexperienced admin to identify those directives which
really matter).

 (Without disagreeing with your per-certificate comment, it is worth
 noting that we have no per-certificate stapling configuration -- only
 per-vhost.  I have no idea how many configurations that affects, but I
 guess that the number is increasing based on effort put into mod_ssl in the
 last year or so.)

It is mostly hindered by the release of OpenSSL 1.0.2 anyway, because
currently, there's the issue of not being able to configure
per-certificate chains in OpenSSL up to 1.0.1.

Generally speaking, I consider SSLStaplingForceURL sort of a kludge - it
might be justified for those (very few) high-traffic sites where the
OCSP URI is deliberately omitted from the certificate (and which are
unlikely to deploy httpd/mod_ssl, BTW), but doesn't really help with the
configure a proxy for retrieving to-be-stapled OCSP responses (you
would need an OCSP-aware proxy under the URL pointed to by
SSLStaplingForceURL, a simple HTTP proxy is not sufficient).

 Factoring in 50% management overhead/fragmentation, I could fit responses
 for 28+ certificates in 32768 bytes if they were like the ones I have
 already.  The current number seems very conservative for the sort of
 configuration for which we can't expect enough configuration skills to
 review the comments in the sample before putting in production.

As mentioned by Hanno elsewhere, more than a few certificates sounds
rather fuzzy, and it would be more helpful for the reader of this
comment to have some data for typical response sizes. They basically
depend on what option is used for response signing according to section
2.2 of RFC 6960:

All definitive response messages SHALL be digitally signed.  The key
used to sign the response MUST belong to one of the following:
 
- the CA who issued the certificate in question
 
- a Trusted Responder whose public key is trusted by the requestor
 
- a CA Designated Responder (Authorized Responder, defined in
  Section 4.2.2.2) who holds a specially marked certificate issued
  directly by the CA, indicating that the responder may issue OCSP
  responses for that CA

For publicly-trusted certificates (in the sense of the CA/Browser
Forum's Baseline Requirements), it's options 1 and 3 which are of
relevance. Examples can be seen at [1] and [2], respectively, i.e. we
are in the range of 500 to 1600 bytes for the DER encoding, and I would
hardly expect responses with more than 2000 bytes (unless large signing
keys/algorithms are used). I didn't look at how these numbers translate
to our stapling cache, though.

Kaspar


[1] 
http://ocsp.usertrust.com/MFEwTzBNMEswSTAJBgUrDgMCGgUABBR8sWZUnKvbRO5iJhat9GV793rVlAQUrb2YejS0Jvf6xCZU7wO94CTLVBoCEEt1V4JpOQyb4y8S7F9tlF4%3D
(Content-Length: 471)

[2] 
http://sr.symcd.com/MFEwTzBNMEswSTAJBgUrDgMCGgUABBR0JBRnBp%2F14Jg%2FXj4aa6BlKlQVdQQUAVmr5906C1mmZGPWzyAHV9WR52oCEBrIXreuw1E82A2FOF7P0gg%3D
(Content-Length: 1595)

Re: Server(_rec) unique identifier

[Kaspar Brand]

On 29.10.2014 11:41, Yann Ylavic wrote:
 I chose to use (MD5 digest) all the IP:port from the s-addrs list
 (ie. VitualHost IP|*|_default_:port ...), plus s-server_hostname
 and s-port (ie. ServerName, be it configured or not, knowing that in
 the latter case, apr_gethostname() is used fot the main server, and
 the main server's one is used for the vhosts).

Just an observation on the digest you're proposing: while it doesn't
seem necessary to proactively kill MD5 in httpd when it is used for
non-crypto purposes (see also RFC 6151), I would prefer another digest
algorithm being picked for new things (apr_sha1_* perhaps, considering
that APR doesn't currently have SHA-2 support?).

Kaspar

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

[Kaspar Brand]

On 29.10.2014 16:40, Graham Leggett wrote:
 The attached patch makes the variable SSL_CLIENT_CERT_SUBJECTS
 available, which contains a list of subject DNs in each certificate
 in the chain. It is designed to be able to match against a full
 certificate chain where the subject and issuer of the certificate
 alone is not good enough to identify a certificate uniquely.

Does this relate to your post from January [1]?

 The subject DNs are themselves escaped and used to create a new DN as
 follows: name=subject1,name=subject2,name=subject3 (and so on).

Feels like a fairly idiosyncratic solution to me (essentially sticking
multiple things together into a single environment variable, with the
[known] problems of how to separate them again / do proper matching in
the application). I would prefer these DNs being exported to the
environment in the same way as it is currently done with the
SSL_CLIENT_CERT_CHAIN_n variables.

Kaspar


[1] 
https://mail-archives.apache.org/mod_mbox/httpd-dev/201401.mbox/%3C1A61F988-F33B-4E65-A141-E4516F8424CC%40sharp.fm%3E

Re: Older clients stopped working after server disabled SSLv3

[Kaspar Brand]

On 01.11.2014 11:23, Yann Ylavic wrote:
 How about SSLv2Hello keyword (à la JDK), should we agree on a real
 issue caused by ALL -SSLv3 (see below)?

This keyword wouldn't fit into the current set of options, so I'm not in
favor of it (the SSL2 compatible hello is like a flag which is
orthogonal to the protocol version).

 The real questions IMO is:
 Is SSLv2Hello replied with TLSv1.x server hello really safe against
 MITM/poodle/other attacks?

Well, no one can answer this question with yes as long as you do not
define other attacks. From what is known today, however, accepting
SSLv2 client hellos does not lead to additional vulnerabilities compared
to a TLS client hello. See also RFC 6176 section 3:

o  TLS servers MAY continue to accept ClientHello messages in the
   version 2 CLIENT-HELLO format as specified in RFC 5246 [TLS1.2],
   Appendix E.2.  Note that this does not contradict the prohibition
   against actually negotiating the use of SSL 2.0.

And this is what RFC 5246 says about its interpretation:

For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same
way as a ClientHello with a null compression method and no
extensions.

(Less options and extensions usually mean less potential for getting
things wrong - just a general observation, not specific to the issue at
hand.)

 The problem is that with OpenSSL 0.9.8, ALL -SSLv3 leaves only
 SSL_PROTOCOL_TLSV1, and TLSv1_server_method() won't accept SSLv2Hello
 (according to my own tests with openssl s_client).

Ok, I see - so it's actually not about Older clients (as the subject
of this thread refers to), but about mod_ssl compiled against OpenSSL
0.9.8 and not allowing TLS 1.0 connections with an SSLv2 compatible
hello, is that correct? Given that 1.0.0 has been around for more than 4
years already and 0.9.8 will be EOL'ed by the end of 2015, I don't think
we should spend too much effort into addressing such legacy-version
issues. I would again point to RFC 6176 section 3, and specifically:

o  TLS clients MUST NOT send the SSL version 2.0 compatible CLIENT-
   HELLO message format.  Clients MUST NOT send any ClientHello
   message that specifies a protocol version less than
   { 0x03, 0x00 }.  As previously stated by the definitions of all
   previous versions of TLS, the client SHOULD specify the highest
   protocol version it supports.

(i.e., there's no good reason for a TLS-capable client to use an SSLv2
compatible hello.)

 openssl s_client (with no protocol option, eg. -tls1/-ssl3/...) uses 
 SSLv2Hello.

It's not just determined by the use of these protocol switches,
actually. It also depends on the OpenSSL version and whether SSLv2
ciphers are still enabled. With OpenSSL 1.0.0 and later, SSLv2
compatible client hellos are essentially gone:

https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=9ae5743515f88f481c0e1075c21404e67d9cc197

Kaspar

Re: svn commit: r1633730 - /httpd/httpd/trunk/docs/conf/extra/httpd-ssl.conf.in

[Kaspar Brand]

On 23.10.2014 02:59, traw...@apache.org wrote:
 Author: trawick
 Date: Thu Oct 23 00:59:40 2014
 New Revision: 1633730
 
 URL: http://svn.apache.org/r1633730
 Log:
 add OCSP Stapling configuration, disabled by default
 
 Modified:
 httpd/httpd/trunk/docs/conf/extra/httpd-ssl.conf.in
 
 Modified: httpd/httpd/trunk/docs/conf/extra/httpd-ssl.conf.in
 URL: 
 http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/conf/extra/httpd-ssl.conf.in?rev=1633730r1=1633729r2=1633730view=diff
 ==
 --- httpd/httpd/trunk/docs/conf/extra/httpd-ssl.conf.in (original)
 +++ httpd/httpd/trunk/docs/conf/extra/httpd-ssl.conf.in Thu Oct 23 00:59:40 
 2014
 @@ -73,6 +73,31 @@ SSLPassPhraseDialog  builtin
  SSLSessionCacheshmcb:ssl_scache(512000)
  SSLSessionCacheTimeout  300
  
 +#   OCSP Stapling (requires OpenSSL 0.9.8h or later)
 +#
 +#   This feature is disabled by default and requires at least
 +#   the two directives SSLUseStapling and SSLStaplingCache.
 +#   Refer to the documentation on OCSP Stapling in the SSL/TLS
 +#   How-To for more information.
 +#
 +#   Enable stapling for all SSL-enabled servers:
 +#SSLUseStapling On

OCSP stapling is primarily a per-certificate feature - so my suggestion
would be to only have the cache related directives (SSLStaplingCache,
SSLStaplingStandardCacheTimeout, SSLStaplingErrorCacheTimeout) at the
global level, and put the other ones into the default VirtualHost block.

 +
 +#   Define a relatively small cache for OCSP Stapling using
 +#   the same mechanism that is used for the SSL session cache
 +#   above.  If stapling is used with more than a few certificates,
 +#   the size may need to be increased.  (AH01929 will be logged.)
 +#SSLStaplingCache shmcb:ssl_stapling(32768)

Shouldn't we make it a bit larger by default? Memory is so cheap these
days that I'm not sure it's worth to keep it that small.

 +
 +#   Override the OCSP responder URL specified in the certificate
 +#SSLStaplingForceURL http://ocsp.example.com/

I suggest to omit this in the sample configuration, as certificates
issued by publicly-trusted CAs which lack an OCSP URI (based on section
13.2.1 in the CA/Browser Forum's Baseline Requirements [1] that the URI
may be omitted for a high-traffic FQDN when stapling is contractually
or technically enforced) do 1) not exist as of today and 2) are
definitely not what a typical deployment with mod_ssl entails. Having
SSLStaplingForceURL in the sample configuration (especially as a global
directive) does more harm than good, IMO.

Kaspar


[1] https://cabforum.org/documents/#Baseline-Requirements

Re: Disable SSLv3 by default

[Kaspar Brand]

On 17.10.2014 12:02, Takashi Sato wrote:
 SSLv3 is now insecure (CVE-2014-3566, POODLE)
 Let's disable SSLv3 by default, at least trunk.
 
 SSLProtocol default is all.
 http://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslprotocol
 all means a shortcut for ``+SSLv3 +TLSv1'' or - when using OpenSSL
 1.0.1 and later - ``+SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2, respectively.
 
 Should we remove SSLv3 from all ?

From a semantic point of view, I wouldn't do that. As long as we still
allow SSLv3 to be used, all should really mean all protocols which
can be enabled in mod_ssl.

I'm fine with changing the hardcoded default (in ssl_engine_config.c) to
SSL_PROTOCOL_ALL  ~SSL_PROTOCOL_SSLV3, though.

The other option would be to drop SSLv3 support completely, like we
currently do for SSLv2 in ssl_engine_init.c:ssl_init_ctx_protocol(). In
this case, all would no longer include SSLv3, of course.

Kaspar

Re: svn commit: r1629372 - in /httpd/httpd/trunk: CHANGES docs/log-message-tags/next-number modules/ssl/ssl_engine_init.c modules/ssl/ssl_private.h modules/ssl/ssl_util_stapling.c

[Kaspar Brand]

On 05.10.2014 13:55, Yann Ylavic wrote:
 sk_OPENSSL_STRING_value() is undefined in openssl-0.9.8x, I commited a
 follow up in r1629485.
 Can you please check this is the right thing to do?

Thanks. It would make more sense to change ssl_private.h, actually - you
can just s/sk_OPENSSL_STRING_pop/sk_OPENSSL_STRING_value/ (as r1629372
dropped the sk_OPENSSL_STRING_pop call, i.e. it's no longer used in
anywhere in mod_ssl).

Kaspar

Re: svn commit: r1599531 - in /httpd/httpd/trunk: CHANGES include/ap_listen.h server/listen.c server/mpm/event/event.c server/mpm/prefork/prefork.c server/mpm/worker/worker.c server/mpm_unix.c

[Kaspar Brand]

 Author: jim
 Date: Tue Jun  3 13:07:29 2014
 New Revision: 1599531
 
 URL: http://svn.apache.org/r1599531
 Log:
 Optimize w/ duplicated listeners and use of SO_REUSEPORT
 where available.
 
 Modified:
 httpd/httpd/trunk/CHANGES
 httpd/httpd/trunk/include/ap_listen.h
 httpd/httpd/trunk/server/listen.c
 httpd/httpd/trunk/server/mpm/event/event.c
 httpd/httpd/trunk/server/mpm/prefork/prefork.c
 httpd/httpd/trunk/server/mpm/worker/worker.c
 httpd/httpd/trunk/server/mpm_unix.c


With these changes, I'm getting segfaults with the worker MPM from 
current trunk (r1629257) when trying to gracefully restart, i.e. with
SIGUSR1. Standard restarts (SIGHUP) seem to work better, though
I'm getting server seems busy and scoreboard is full log entries
and other errors in this case. A sample stack (CentOS 6 / x86_64)
is shown below, in case it helps in tracking down the issue.

Kaspar


(gdb) bt f
#0  make_child (s=0x7f8b447c26f8, slot=0) at worker.c:1410
pid = value optimized out
#1  0x7f8b43342037 in server_main_loop (_pconf=value optimized out, 
plog=value optimized out,
s=value optimized out) at worker.c:1742
status = 0
pid = {pid = 2188, in = 0x7f8b447c26f8, out = 0x7f8b44791138, err = 
0x7f8b42811993}
i = value optimized out
old_gen = 0
child_slot = 0
exitwhy = APR_PROC_EXIT
processed_status = 0
#2  worker_run (_pconf=value optimized out, plog=value optimized out, 
s=value optimized out) at worker.c:1872
remaining_children_to_start = 3
rv = value optimized out
i = value optimized out
#3  0x7f8b432ffe7e in ap_run_mpm (pconf=0x7f8b44791138, 
plog=0x7f8b447be498, s=0x7f8b447c26f8)
at mpm_common.c:100
pHook = value optimized out
n = value optimized out
rv = -1
#4  0x7f8b432f940e in main (argc=1, argv=0x7bee4618) at main.c:799
c = 0 '\000'
showcompile = 0
showdirectives = 1148776984
confname = 0x7f8b433442ea conf/httpd.conf
def_server_root = 0x7f8b433442d1 /home/apache-httpd/trunk
temp_error_log = 0x0
error = value optimized out
process = 0x7f8b4478f218
pconf = 0x7f8b44791138
plog = 0x7f8b447be498
ptemp = 0x7f8b447bc348
pcommands = 0x7f8b447b3248
opt = 0x7f8b447b3338
rv = value optimized out
mod = value optimized out
opt_arg = 0x0
signal_server = value optimized out

Re: svn commit: r1599531 - in /httpd/httpd/trunk: CHANGES include/ap_listen.h server/listen.c server/mpm/event/event.c server/mpm/prefork/prefork.c server/mpm/worker/worker.c server/mpm_unix.c

[Kaspar Brand]

On 05.10.2014 02:27, Lu, Yingqi wrote:
 Kaspar, can you please test the patch and let us know if that
 resolves your issue?

Yes, makes the restart issues disappear for me (only tested with the
worker MPM, and not very extensively). Thanks.

 At the meantime, can some please review the patch and help add it
 into trunk?

I'll defer to Jeff or Jim (I'm definitely not familiar enough with
anything below server/mpm/...).

Kaspar

Re: yet another mod_ssl temp DH handling tweak

[Kaspar Brand]

On 19.06.2014 23:17, Joe Orton wrote:
 I was reminded that there was a request to use the larger key sizes as 
 well.

Using ephemeral DH keys with sizes  4096 bits in TLS seems way overkill
for the next decade or so (3072 bits are already considered to have a
128-bit symmetric-key strength), but if it makes people happy to use
unreasonably large keys, then so be it... the docs for
SSLCertificateFile should also be updated in this case.

 +/* Storage and initialization for DH parameters. */
 +static struct dhparam {
 +BIGNUM *(*const prime)(BIGNUM *); /* function to generate... */
 +DH *dh;   /* ...this, used for keys */
 +const unsigned int min;   /* ...of length = this. */
 +} dhparams[] = {
 +{ get_rfc3526_prime_8192, NULL, 6145 },
 +{ get_rfc3526_prime_6144, NULL, 4097 },
 +{ get_rfc3526_prime_4096, NULL, 3073 },
 +{ get_rfc3526_prime_3072, NULL, 2049 },
 +{ get_rfc3526_prime_2048, NULL, 1025 },
 +{ get_rfc2409_prime_1024, NULL, 0 }
 +};

Perhaps the min values could increased somewhat -
7168/5120/3584/2560/1536 (i.e. half way between two steps)?

Kaspar

Re: mod_ssl SSL session timeout

[Kaspar Brand]

On 14.06.2014 12:53, Rainer Jung wrote:
 SSL_CTX_set_timeout() seems to work pretty well.

Indeed. I missed the fact that after the ticket has been decrypted/processed,
there's a timeout check in ssl_sess.c:ssl_get_prev_session(), based on the
SSL_SESSION's time value, which is the timestamp of its creation.

SSL_CTX_set_timeout() adjusts the default value for SSL sessions created by
ssl_sess.c:ssl_get_new_session(). Right now, mod_ssl relies on the builtin
OpenSSL defaults, which are somewhat inconsistent:

- if SSLProtocol specifies multiple protocols, the default timeout
  for TLS session tickets is 300 seconds

- if SSLProtocol only specifies one of TLSv1, TLSv1.1, or TLSv1.2,
  the default timeout for session tickets is 7200 seconds

 In addition to the usual directive management lines, the patch should be
 as simple as
 
 Index: modules/ssl/ssl_engine_init.c
 ===
 --- modules/ssl/ssl_engine_init.c   (revision 1593916)
 +++ modules/ssl/ssl_engine_init.c   (working copy)
 @@ -1365,6 +1365,8 @@
  }
  #endif
 
 +SSL_CTX_set_timeout(sc-server-ssl_ctx, sc-server-session_timeout);
 +
  return APR_SUCCESS;
  }
 
 where sc-server-session_timeout is the new configuration item (if we
 do not stick to the existing cache timeout).

I'm slightly in favor of the latter, i.e. something like

SSL_CTX_set_timeout(sc-server-ssl_ctx,
sc-session_cache_timeout == UNSET ?
SSL_SESSION_CACHE_TIMEOUT : sc-session_cache_timeout);

(As a side effect, this would also make sure that the timeout for
TLS session tickets is 300 seconds for all SSLProtocol settings,
if SSLSessionCacheTimeout is not explicitly configured.)

Kaspar

Re: mod_ssl SSL session timeout

[Kaspar Brand]

On 13.06.2014 16:55, Rainer Jung wrote:
 Now since a long time most clients do no longer rely on the server
 caching the sessions. Instead they use TLS session resumption (RFC
 5077).

without server-side state/stateless is actually the important term
from this RFC (session resumption is a standard protocol feature).

 Currently mod_ssl does not provide a way to control the time how long
 such a ticket may be used by the client. As far as I can see, there is
 no specific API in OpenSSL for that, but there is a general API allowing
 to set a session timeout that is checked whenever a session is
 reconstructed.

What OpenSSL function do you have in mind? SSL_SESSION_set_timeout?
AFAICT, t1_lib.c:tls_decrypt_ticket simply restores the (relative)
timeout for the SSL_SESSION, which is set to 5 minutes by default... but
if I'm understanding correctly, you are concerned about clients reusing
old tickets, is that correct? (If so, then I guess there's currently
no other way than switching to a new ticket encryption key, see also [1]).

Kaspar

[1]
https://mail-archives.apache.org/mod_mbox/httpd-dev/201308.mbox/%3C2013082727.GA7331%40redhat.com%3E
or
https://mail-archives.apache.org/mod_mbox/httpd-dev/201309.mbox/%3C52248C40.7070206%40opensslfoundation.com%3E

Re: Memory leak in mod_ssl ssl_callback_TmpDH

[Kaspar Brand]

On 02.06.2014 20:49, Ruediger Pluem wrote:
 Joe Orton wrote:
 On Wed, May 28, 2014 at 10:10:16PM +0200, Ruediger Pluem wrote:
 Thanks, but I missed some stuff during review:

 1. We don't need to have two DH pointers in make_dh_params

 Doh! 

 2. There possible frees on NULL pointers in free_dh_params:

 This is unnecessary because DH_free() does that already, but that 
 deserves a comment too.  I'll fix this with your patch for (1) shortly, 
 thanks!

 
 Are you waiting for any action from my side? Just want to avoid that we wait 
 for each other and deadlock :-)

Just a quick reminder... I think it's important to backport
r1597349/r1598107 + the additional adjustment for 2.4.10 (happy to vote
once it's settled on trunk).

Kaspar

Re: Memory leak in mod_ssl ssl_callback_TmpDH

[Kaspar Brand]

On 27.05.2014 22:33, Ruediger Pluem wrote:
 Joe Orton wrote:
 We have a potential race here between threads doing the param 
 generation, right?

 +static DH *dh = NULL; \
 +DH *dh_tmp; \
 ...
 +dh = dh_tmp; \

 though it would not matter who wins the race *if* we could rely on 
 pointer assignment being atomic - which is a fairly dubious assumption, 
 
 That was my assumption. If we cannot assume that the pointer assignment is 
 atomic,
 then we have a race problem.
 
 Would the following patch address your concern?

I would be in favor of fixing the potential race condition in this (or a
similar) way... otherwise we would 1) again have to hardcode
algorithm-dependent things into one of our structs and 2) generate DH
parameters at startup even though they might never get be needed (if
someone turns off DHE with !kEDH in SSLCipherSuite, none of these DH
parameters would ever be used).

 it might be better to do it once at startup to save CPU time anyway?
 
 I am not that worried about CPU because I guess we fairly quickly get dh set 
 to a valid value

Agree, CPU time is not a concern, get_dh_XXX() is only about populating
DH with builtin constants (DH_generate_key happens at connection time,
and is fast anyway).

Kaspar

Re: Memory leak in mod_ssl ssl_callback_TmpDH

[Kaspar Brand]

On 19.05.2014 10:15, Plüm, Rüdiger, Vodafone Group wrote:
 Maybe stupid idea, but can't we do that once and hand it out over
 and over again?

Not a stupid idea at all - I think it's actually the most sensible
solution to this problem. This is what OpenSSL does with the
DH parameters provided by the callback in 
s3_srvr.c:ssl3_send_server_key_exchange():

if (type  SSL_kEDH)
{
dhp=cert-dh_tmp;
if ((dhp == NULL)  (s-cert-dh_tmp_cb != NULL))
dhp=s-cert-dh_tmp_cb(s,
  SSL_C_IS_EXPORT(s-s3-tmp.new_cipher),
  
SSL_C_EXPORT_PKEYLENGTH(s-s3-tmp.new_cipher));
if (dhp == NULL)
{
al=SSL_AD_HANDSHAKE_FAILURE;

SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,SSL_R_MISSING_TMP_DH_KEY);
goto f_err;
}

if (s-s3-tmp.dh != NULL)
{
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, 
ERR_R_INTERNAL_ERROR);
goto err;
}

if ((dh=DHparams_dup(dhp)) == NULL)
{

SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,ERR_R_DH_LIB);
goto err;
}

s-s3-tmp.dh=dh;
if ((dhp-pub_key == NULL ||
 dhp-priv_key == NULL ||
 (s-options  SSL_OP_SINGLE_DH_USE)))
{
if(!DH_generate_key(dh))
{
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
   ERR_R_DH_LIB);
goto err;
}
}
else
{
dh-pub_key=BN_dup(dhp-pub_key);
dh-priv_key=BN_dup(dhp-priv_key);
if ((dh-pub_key == NULL) ||
(dh-priv_key == NULL))
{

SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,ERR_R_DH_LIB);
goto err;
}
}
r[0]=dh-p;
r[1]=dh-g;
r[2]=dh-pub_key;
}

I.e., the dhp parameters provided by the callback (dh_tmp_cb) are
duplicated, and as Rainer mentioned, we would have to keep track
of dhp ourselves in order to be able to free it ourselves later on.
(In 2.2.x or before 2.4.7, these parameters/keys are part of mod_ssl's
global SSLModConfigRec, that's how the leak is avoided there.)

 It looks like to me that we only generate the parameters, not
 the keys. And reusing the same parameters should be save.

Correct as well, yes. DH_new sets pub_key and priv_key both to NULL,
so DH_generate_key is always called by ssl3_send_server_key_exchange().

 So something like:

Looks good to me. I suggest adding a short comment which explains
the rationale for using dh and dh_tmp (the SSL_CTX_set_tmp_dh_callback(3)
man page e.g. doesn't make it clear that reusing the parameters
within the lifetime of a process is actually a must to prevent memory
from leaking).

Kaspar

Re: SSL_CLIENT_S_DN_x509 and subjectAltName

[Kaspar Brand]

On 19.05.2014 16:58, Graham Leggett wrote:
 In httpd v2.4's mod_ssl I can access the various components of the
 subject and the issuer DN using SSL_CLIENT_S_DN_x509 and
 SSL_CLIENT_I_DN_x509.
 
 Is there a corresponding set of variables that can pull the same
 information out of the subjectAltName?

No, this would imply extending ssl_engine_vars.c to also process
information from the subjectAltName extension. What types of
subjectAltName entries are you most interested in? These are the
subjectAltName types defined by RFC 5280:

   GeneralName ::= CHOICE {
otherName   [0] OtherName,
rfc822Name  [1] IA5String,
dNSName [2] IA5String,
x400Address [3] ORAddress,
directoryName   [4] Name,
ediPartyName[5] EDIPartyName,
uniformResourceIdentifier   [6] IA5String,
iPAddress   [7] OCTET STRING,
registeredID[8] OBJECT IDENTIFIER }

I.e., it would probably be best to focus on common ones like
rfc822Name or dNSName, otherwise we might get lost in adding a plethora
of additional environment variables. Is client cert authentication your
use case, or in what context are you interested in this information?

Kaspar

Re: LogLevel inheritance/merging for VirtualHost in 2.4.x

[Kaspar Brand]

On 23.02.2014 09:03, Kaspar Brand wrote:
 Yes, that's the underlying issue which changing cmd-server to NULL in
 the ap_log_error actually uncovers: it's a somewhat (at least IMO)
 unfortunate side effect of how the LogLevel for a new VirtualHost is
 inherited/merged from the global LogLevel directive, or more
 specifically, the order in which it happens.
 
 If you insert LogLevel warn (or higher) in the VirtualHost block
 *before* any SSLCertificateChainFile directive, then you'll see the
 vhost-scope warnings on stderr (or in the log on reloads) as well.
 
 One potential fix could consist of the attached patch for
 server/config.c, though I'm not sure if it doesn't have unwanted side
 effects, either (cf. r1024427 as to why it was last changed into the
 opposite direction).

After another look at this, an better solution might be the attached
patch - any opinions/insights from people who are more familiar with the
logging stuff than me?

Kaspar
Index: server/config.c
===
--- server/config.c (revision 1590359)
+++ server/config.c (working copy)
@@ -2192,7 +2192,7 @@ AP_CORE_DECLARE(const char *) ap_init_virtual_host
 s-keep_alive = -1;
 s-keep_alive_max = -1;
 s-error_log = main_server-error_log;
-s-log.level = APLOG_UNSET;
+s-log.level = main_server-log.level;
 s-log.module_levels = NULL;
 /* useful default, otherwise we get a port of 0 on redirects */
 s-port = main_server-port;
@@ -2284,6 +2284,7 @@ AP_DECLARE(void) ap_fixup_virtual_hosts(apr_pool_t
 if (virt-keep_alive_max == -1)
 virt-keep_alive_max = main_server-keep_alive_max;
 
+virt-log.level = APLOG_UNSET;
 ap_merge_log_config(main_server-log, virt-log);
 
 dconf = ap_get_core_module_config(virt-lookup_defaults);

Re: svn commit: 1573360 - SSLPassPhraseDialog arguments changed in 2.4.x

[Kaspar Brand]

On 16.04.2014 10:17, Kaspar Brand wrote:
 There's another backwards-compatibility fix I consider necessary for
 2.4.x (see https://issues.apache.org/bugzilla/show_bug.cgi?id=56306#c8),
 so I think I'll wait a few days for feedback on that one before
 combining them into a single proposal for 2.4.x (trunk shouldn't need them).

Backport proposal added to STATUS with r1590359 (patch at
https://people.apache.org/~kbrand/mod_ssl-2.4.x-pphrase-certkeyfile-compat.diff),
reviews/votes appreciated.

Kaspar

Re: svn commit: r1588851 - /httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c

[Kaspar Brand]

On 22.04.2014 12:55, Yann Ylavic wrote:
 On Mon, Apr 21, 2014 at 8:39 AM,  kbr...@apache.org wrote:
 +#ifdef SSL_CERT_SET_SERVER
 +/*
 + * When multiple certs/keys are configured for the SSL_CTX: make sure
 + * that we get the private key which is indeed used for the current
 + * SSL connection (available in OpenSSL 1.0.2 or later only)
 + */
 +SSL_set_current_cert(ssl, SSL_CERT_SET_SERVER);
 +#endif
 
 Shouldn't this be fixed in OpenSSL (1.0.2)?

That's probably a question for Steve, but the way I understood his
comment in February was that he would rather not want it to do by
default, hence the new SSL_CERT_SET_SERVER control.

 When SSL_CTX_set_current_cert(ctx, SSL_CERT_SET_FIRST|NEXT) is used to
 scan the certs, should one use a final SSL_CTX_set_current_cert(ctx,
 SSL_CERT_SET_SERVER) so that the one inherited by SSL_new(ctx) (if
 any) gets set accordingly?

That's not possible - for SSL_get_privatekey, we do not know which cert
is picked at connection time (the client can influence this by the
cipher suites he offers in the ClientHello).

 Or every callback ought to take care of this?

Unless OpenSSL does it by default (or the SSL_CTX only uses a single
cert), we have to set it with SSL_set_current_cert, yes.

 How about TmpDH used by client (proxy) handshake, is still
 SSL_CERT_SET_SERVER the right cert?

SSL_CTX_set_tmp_dh_callback() - which we use for setting
ssl_callback_TmpDH - applies to a server-mode SSL_CTX only.

 It looks like a regression to me (which may affect several software),
 the callbacks should not care about the loading order of (or previous
 walking though) the certs, and the callback's given SSL current cert
 be the one of the underlying authentication.

I think it boils down to my question from February, in the end ([1],
Could ssl_lib.c:ssl_get_server_send_pkey be adapted to ensure this?)

Kaspar

[1] 
https://mail-archives.apache.org/mod_mbox/httpd-dev/201402.mbox/%3c53059d82.3070...@velox.ch%3E

Re: apache hintlist

[Kaspar Brand]

On 22.04.2014 14:57, Ligade, Shailesh [USA] wrote:
 I think by default, the certificate hint list asks for client
 authentication certificates. Is there any configuration option to ask
 for different types of certificates? e.g.  signing or encryption
 certificates?

This would be a question for the users list, in the first place
(http://httpd.apache.org/userslist.html)... but to cut it short: only to
a small extent, since a TLS server can only include the following things
in a CertificateRequest message: lists of certificate_types,
supported_signature_algorithms (TLS 1.2) and certificate_authorities
(RFC 5246, section 7.4.4). The onus is mostly on the client to make sure
that it doesn't pick a cert with an unsuitable keyUsage/EKU extension.

Kaspar

Re: DH params and multiple certificates in one VHost

[Kaspar Brand]

On 19.04.2014 09:37, Falco Schwarz wrote:
 I successfully tested your attached patch with the latest 1.0.2
 branch. The DH temp key now has the bit length of the used RSA key,
 regardless of SSLCertificate[Key]File order.

Thanks for testing. Committed to trunk with r1588851 and proposed for
backport to 2.4.x.

Kaspar

Re: SSL_CTX_get_{first,next}_certificate

[Kaspar Brand]

On 05.02.2014 14:05, Kaspar Brand wrote:
 On 03.02.2014 12:21, Dr Stephen Henson wrote:
 On 02/02/2014 13:45, Kaspar Brand wrote:
 Yes, this sounds like a useful extension - not only for the issue at
 hand (i.e. SSL_CONF and stapling initialisation), but as a general
 mechanism for retrieving all certificates of an SSL_CTX.


 Added now. The API is slightly different, but easy enough to use.
 
 I have adapted the stapling init code in trunk to switch to this
 mechanism with r1564760 (just committed). Reviews appreciated, would
 afterwards propose for backport.

Steve, I just noticed that using SSL_CTX_set_current_cert became
broken with [1] and [2], respectively - SSL_CTX_get0_certificate
may now return bogus pointers (and we segfault when trying to
dereference them, worst case). Patch for ssl_cert.c attached.

Kaspar


[1] 
https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=358d352aa244b4f2ef655bccff6658d92d5ce03c

[2] 
https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=c3f5d3d93ac81c2866a739f1981d948e6aba1fde
diff --git a/ssl/ssl_cert.c b/ssl/ssl_cert.c
index 830490e..aaa6e0a 100644
--- a/ssl/ssl_cert.c
+++ b/ssl/ssl_cert.c
@@ -664,7 +664,7 @@ int ssl_cert_set_current(CERT *c, long op)
return 0;
for (i = idx; i  SSL_PKEY_NUM; i++)
{
-   CERT_PKEY *cpk = c-key + i;
+   CERT_PKEY *cpk = c-pkeys + i;
if (cpk-x509  cpk-privatekey)
{
c-key = cpk;

Re: svn commit: r1587607 - in /httpd/httpd/trunk: ./ include/ modules/ssl/

[Kaspar Brand]

On 15.04.2014 17:25, traw...@apache.org wrote:
 Author: trawick
 Date: Tue Apr 15 15:25:03 2014
 New Revision: 1587607
 
 URL: http://svn.apache.org/r1587607
 Log:
 mod_ssl: Add hooks to allow other modules to perform processing at
 several stages of initialization and connection handling.  See
 mod_ssl_openssl.h.
 
 This is enough to allow implementation of Certificate Transparency
 outside of mod_ssl.
 

[...]

 Modified: httpd/httpd/trunk/modules/ssl/ssl_engine_io.c
 URL: 
 http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_io.c?rev=1587607r1=1587606r2=1587607view=diff
 ==
 --- httpd/httpd/trunk/modules/ssl/ssl_engine_io.c (original)
 +++ httpd/httpd/trunk/modules/ssl/ssl_engine_io.c Tue Apr 15 15:25:03 2014
 @@ -29,8 +29,13 @@
  -- Unknown*/
  #include ssl_private.h
  #include mod_ssl.h
 +#include mod_ssl_openssl.h
  #include apr_date.h
  
 +APR_IMPLEMENT_OPTIONAL_HOOK_RUN_ALL(ssl, SSL, int, proxy_post_handshake,
 +(conn_rec *c,SSL *ssl),
 +(c,ssl),OK,DECLINED);
 +
  /*  _
  **
  **  I/O Hooks
 @@ -1119,6 +1124,8 @@ static apr_status_t ssl_io_filter_handsh
  const char *hostname_note = apr_table_get(c-notes,
proxy-request-hostname);
  BOOL proxy_ssl_check_peer_ok = TRUE;
 +int post_handshake_rc;
 +
  sc = mySrvConfig(server);
  
  #ifdef HAVE_TLSEXT
 @@ -1208,11 +1215,17 @@ static apr_status_t ssl_io_filter_handsh
  }
  }
  
 +if (proxy_ssl_check_peer_ok == TRUE) {
 +/* another chance to fail */
 +post_handshake_rc = ssl_run_proxy_post_handshake(c, 
 filter_ctx-pssl);
 +}
 +
  if (cert) {
  X509_free(cert);
  }
  
 -if (proxy_ssl_check_peer_ok != TRUE) {
 +if (proxy_ssl_check_peer_ok != TRUE
 +|| (post_handshake_rc != OK  post_handshake_rc != DECLINED)) {
  /* ensure that the SSL structures etc are freed, etc: */
  ssl_filter_io_shutdown(filter_ctx, c, 1);
  apr_table_setn(c-notes, SSL_connect_rv, err);

GCC warns about 'post_handshake_rc' may be used uninitialized in this
function... which would be true for the proxy_ssl_check_peer_ok !=
TRUE case (line 1228), I think.

Kaspar

Re: DH params and multiple certificates in one VHost

[Kaspar Brand]

On 18.04.2014 23:19, Falco Schwarz wrote:
 On Fri, Apr 18, 2014 at 4:04 PM, Daniel Kahn Gillmor
 d...@fifthhorseman.netwrote:

 Looking at the code, it appears that ssl_callback_TmpDH() in
 modules/ssl/ssl_engine_kernel.c doesn't try to match ECC keys at all --
 this probably needs to be updated.

 
 That was also my conclusion. It kinda makes sense that ECC keys are not
 matched, because there is no ECDSA+DH cipher.

Right, there are no cipher suites which use ECDSA for authentication and
ephemeral Diffie-Hellman keys (cf. openssl ciphers -v aECDSA).

ssl_callback_TmpDH() is therefore irrelevant for the ECC case (it is
only called for DHE-* cipher suites, not for ECDHE-* ones). For
ephemeral ECDH, mod_ssl is relying on automatic curve selection, if
available (OpenSSL 1.0.2 or later), see also [1].

 However ssl_callback_TmpDH()
 would either have to iterate through all private keys or just read the
 first key in order to be consistent with DH / ECDH params.

The problem is the one pointed out by Steve in [2] already, I think: in
the callback, SSL_get_privatekey() doesn't get us the private key which
is actually used for the current connection, it only returns the
current key i.e. the last one we configured.

 Reindl, that is quite a good guide on how to setup certificates as of
 2.4.9.

With one noteworthy exception: putting the private key into its own
SSLCertificateKeyFile is preferred over having it in SSLCertificateFile
(BTW, Harald would be the first name, I assume you didn't intend to
call him by his last name).

Kaspar


[1] 
https://mail-archives.apache.org/mod_mbox/httpd-dev/201401.mbox/%3c52cc3c0d.1030...@velox.ch%3E

[2] 
https://mail-archives.apache.org/mod_mbox/httpd-dev/201402.mbox/%3c53057121.70...@opensslfoundation.com%3E

Re: DH params and multiple certificates in one VHost

[Kaspar Brand]

On 19.04.2014 09:00, Falco Schwarz wrote:
 that OpenSSL actually returns the private key used by the connection.

I just noticed [1], so you might want to try the attached (but untested)
patch with 1.0.2-beta1 at least (beware of CVE-2014-0160 though, later
versions preferred).

Kaspar

[1] 
https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=58b86e4235cd420f607819727d372af9f7a80224
Index: modules/ssl/ssl_engine_kernel.c
===
--- modules/ssl/ssl_engine_kernel.c (revision 1588426)
+++ modules/ssl/ssl_engine_kernel.c (working copy)
@@ -1344,9 +1344,15 @@ make_get_dh(rfc3526, 4096, 2)
 DH *ssl_callback_TmpDH(SSL *ssl, int export, int keylen)
 {
 conn_rec *c = (conn_rec *)SSL_get_app_data(ssl);
-EVP_PKEY *pkey = SSL_get_privatekey(ssl);
-int type = pkey ? EVP_PKEY_type(pkey-type) : EVP_PKEY_NONE;
+EVP_PKEY *pkey;
+int type;
 
+#ifdef SSL_CERT_SET_SERVER
+SSL_set_current_cert(ssl, SSL_CERT_SET_SERVER);
+#endif
+pkey = SSL_get_privatekey(ssl);
+type = pkey ? EVP_PKEY_type(pkey-type) : EVP_PKEY_NONE;
+
 /*
  * OpenSSL will call us with either keylen == 512 or keylen == 1024
  * (see the definition of SSL_EXPORT_PKEYLENGTH in ssl_locl.h).

Re: svn commit: r1585090 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c

[Kaspar Brand]

On 18.04.2014 11:11, Yann Ylavic wrote:
 Agreed, still it may be useful (for some potential client) to get the
 real error when it handshakes with an SNI which is not acceptable on
 this server, and for the server the sooner the better IMHO.

mod_ssl will send a Certificate TLS message either way (whether we
return SSL_TLSEXT_ERR_ALERT_WARNING or SSL_TLSEXT_ERR_NOACK). From a
client perspective, if you really want to avoid processing/validating
the cert (and abort early based on the server's hint that he found no
matching certificate), then you can check the ServerHello for the
presence of an (empty) SNI extension. With r1585090 / r1588424, we're
omitting the warning-level alert, but there's no change for the ServerHello.

 Well, if one want to be really strict about SNI, and don't have a
 wildcard cert (say the poor man, still with multiple name-based
 vhost), is the default SSL vhost relevant?

Yes, as it simply the one and only SSL host for a given TCP port, in
this case, and completely denying access to non-SNI clients that early
in the handshake already isn't a very useful thing to go for, I think.

 to deny at handshake time, with the relevant message for the client to
 know why (instead of 400, 503 or even bad cert which just leaks
 another service).

Browsers are pretty bad with handling failures at the TLS level (fatal
alerts in particular). Handling them with a decent ErrorDocument etc. on
the HTTP layer is much better, IMO.

Kaspar

Re: svn commit: r1585090 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c

[Kaspar Brand]

Sorry for being late with my reply.

On 16.04.2014 16:00, Yann Ylavic wrote:
 Before this commit, the client knew it was not reaching any vhost by
 receiving an SSL alert (warning), and could stop.

In practice, most SNI-capable clients have ignored these warning-level
alerts (which is completely in line with RFC 5246, which states If an
alert with a level of warning is sent and received, generally the
connection can continue normally).

Whether or not the server acknowledges to have a suitable cert for the
name requested by the client in the SNI extension isn't that relevant,
IMO. The most important (and absolutely essential) thing the client has
to do is to check the expected name against those included in the
certificate (RFC 6125, acceptable reference identifiers vs. presented
identifiers), irrespective of any potential TLS warning-level alert he
might have received on the connection.

 The new option would prevent the default vhost to be used (when SNI is
 available), and let the client know (still).

As pointed out by Rüdiger in his latest message, there is no point in
disallowing access to the default vhost based on whether an SNI
extension was sent by the client or not: the default vhost is
effectively the global one for SSL connections - SSLEngine on should
only be configured within vhosts, see also [1]. Ever since mod_ssl was
added to 2.0.x [2], a _default_:443 vhost was used to handle all SSL
requests.

Thanks for your vote with r1588257, Yann, in any case - now merged to
2.4.x with r1588424.

Kaspar

[1] 
https://mail-archives.apache.org/mod_mbox/httpd-dev/201011.mbox/%3c7bf538e6-dafb-4638-b845-09bedf673...@rcbowen.com%3E

[2] https://svn.apache.org/viewvc?view=revisionrevision=91707

Re: svn commit: 1573360 - SSLPassPhraseDialog arguments changed in 2.4.x

[Kaspar Brand]

On 14.04.2014 10:47, Jan Kaluža wrote:
 On 04/12/2014 12:37 PM, Kaspar Brand wrote:
 We can partly restore the argument structure for exec-type programs,
 but effectively, lifting the limit of 2 (or 3) certs per SSL host means
 that there's no longer a reliable way of determining if we are actually
 loading an RSA, DSA, or ECC key when calling the
 SSLPassPhraseDialog program.
 
 It would be useful to have the same arguments as before, but if that's 
 not possible to do in all cases now, I would say just increasing the 
 arguments count won't help anything.

I'm attaching a cleaned up patch, which does it in a somewhat more
systematic way. If we apply this to 2.4.x, then we have at least
compatibility with existing configs and exec-type SSLPassPhraseDialog
programs.

 I have already asked the original reporter of this incompatibility, but 
 I have not received the answer yet. I will try to ask him again and will 
 write an email if I get the response this time.
 
 My guess is that they are just using that second argument in the script 
 and since the argument is not here, the script is failing now. I don't 
 think it's used for anything more important than that, but I have no 
 clue right now.

For the sake of transparency/completeness, this is the bug report for
Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1084230

 Anyway, would you merge your documentation patch with httpd-2.4 with the 
 mention it changed in 2.4.9?

I already did that with r1585902 (cf.
http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslpassphrasedialog).

Kaspar
Index: modules/ssl/ssl_engine_pphrase.c
===
--- modules/ssl/ssl_engine_pphrase.c(revision 1587799)
+++ modules/ssl/ssl_engine_pphrase.c(working copy)
@@ -43,6 +43,14 @@ typedef struct {
 const char *pkey_file;
 } pphrase_cb_arg_t;
 
+#ifdef HAVE_ECC
+static const char *key_types[] = {RSA, DSA, ECC};
+#define CERTKEYS_IDX_MAX 2
+#else
+static const char *key_types[] = {RSA, DSA};
+#define CERTKEYS_IDX_MAX 1
+#endif
+
 /*
  * Return true if the named file exists and is readable
  */
@@ -574,16 +582,29 @@ int ssl_pphrase_Handle_CB(char *buf, int bufsize,
  */
 else if (sc-server-pphrase_dialog_type == SSL_PPTYPE_FILTER) {
 const char *cmd = sc-server-pphrase_dialog_path;
-const char **argv = apr_palloc(ppcb_arg-p, sizeof(char *) * 3);
+const char **argv = apr_palloc(ppcb_arg-p, sizeof(char *) * 4);
+const char *idx = ap_strrchr_c(ppcb_arg-key_id, ':') + 1;
 char *result;
+int i;
 
 ap_log_error(APLOG_MARK, APLOG_INFO, 0, ppcb_arg-s, APLOGNO(01969)
  Init: Requesting pass phrase from dialog filter 
  program (%s), cmd);
 
 argv[0] = cmd;
-argv[1] = ppcb_arg-key_id;
-argv[2] = NULL;
+argv[1] = apr_pstrndup(ppcb_arg-p, ppcb_arg-key_id,
+   idx-1 - ppcb_arg-key_id);
+if ((i = atoi(idx))  CERTKEYS_IDX_MAX+1) {
+/*
+ * For compatibility with existing 2.4.x configurations, use
+ * RSA, DSA and ECC strings for the first two/three keys
+ */
+argv[2] = key_types[i];
+} else {
+/* Four and above: use the integer index */
+argv[2] = apr_pstrdup(ppcb_arg-p, idx);
+}
+argv[3] = NULL;
 
 result = ssl_util_readfilter(ppcb_arg-s, ppcb_arg-p, cmd, argv);
 apr_cpystrn(buf, result, bufsize);

Re: svn commit: 1573360 - SSLPassPhraseDialog arguments changed in 2.4.x

[Kaspar Brand]

On 16.04.2014 09:45, Jan Kaluža wrote:
 On 04/16/2014 09:35 AM, Plüm, Rüdiger, Vodafone Group wrote:
 Are we sure that ppcb_arg-key_id always contains a ':'?
 
 I've checked that part of patch and if I'm right, the key_id is only 
 created by asn1_table_vhost_key(...) like this:
 
 char *key = apr_psprintf(p, %s:%d, id, i);

Yes, exactly. It is then assigned to ppcb_arg.key_id in
ssl_load_encrypted_pkey(), which is the only place which configures
ssl_pphrase_Handle_CB as a callback.

There's another backwards-compatibility fix I consider necessary for
2.4.x (see https://issues.apache.org/bugzilla/show_bug.cgi?id=56306#c8),
so I think I'll wait a few days for feedback on that one before
combining them into a single proposal for 2.4.x (trunk shouldn't need them).

Kaspar

Re: http://httpd.apache.org/ mini-advisory needed on 2.4.9 breakage IMO...

[Kaspar Brand]

On 12.04.2014 12:41, Kaspar Brand wrote:
 The Expecting: DH PARAMETERS error is probably a red herring - it's
 most likely a leftover in the OpenSSL error stack after the
 configuration of another certificate (we try to load DH parameters at
 the end of ssl_init_server_certs, which in turn is called from
 ssl_init_server_ctx).

Turns out that it's an issue with OpenSSL versions before 0.9.8h, in the
first place, see
https://issues.apache.org/bugzilla/show_bug.cgi?id=56410 for more details.

Jesse, would appreciate if you can find the time to also try the patch I
attached to the bug report from Kurt - thanks.

Kaspar

Re: svn commit: 1573360 - SSLPassPhraseDialog arguments changed in 2.4.x

[Kaspar Brand]

[picking this up from the comment in Re: svn commit: r1585902 - ...]

On 09.04.2014 21:56, Jeff Trawick wrote:
 IMO this needs to be reworked to restore compatibility for 2.x up 
 through 2.4.7, with the new interface used if some new keyword is
 added on the directive. Yeah, some people who reworked their scripts
 will have to add that new keyboard, but this will unblock others
 (vendors, distros, individuals) from upgrading without surprise.

We can partly restore the argument structure for exec-type programs,
but effectively, lifting the limit of 2 (or 3) certs per SSL host means
that there's no longer a reliable way of determining if we are actually
loading an RSA, DSA, or ECC key when calling the
SSLPassPhraseDialog program.

One option for improving backward compatibility with existing
SSLPassPhraseDialog programs could consist of keeping the two-argument
structure (servername:portnumber and index), and to replace the indexes
0 through 2 with the RSA, DSA, and ECC strings, respectively, as
illustrated by the attached patch (quickly hacked up PoC).

The primary question is on what arguments existing passphrase handling
programs are specifically relying - i.e. if it's mostly about only
having servername:portnumber in the first argument, or whether the
accuracy of RSA/DSA/ECC is equally important.

Kaspar
Index: modules/ssl/ssl_engine_pphrase.c
===
--- modules/ssl/ssl_engine_pphrase.c(revision 1586845)
+++ modules/ssl/ssl_engine_pphrase.c(working copy)
@@ -43,6 +43,8 @@ typedef struct {
 const char *pkey_file;
 } pphrase_cb_arg_t;
 
+static const char *key_types[] = {RSA, DSA, ECC};
+
 /*
  * Return true if the named file exists and is readable
  */
@@ -574,16 +576,24 @@ int ssl_pphrase_Handle_CB(char *buf, int bufsize,
  */
 else if (sc-server-pphrase_dialog_type == SSL_PPTYPE_FILTER) {
 const char *cmd = sc-server-pphrase_dialog_path;
-const char **argv = apr_palloc(ppcb_arg-p, sizeof(char *) * 3);
+const char **argv = apr_palloc(ppcb_arg-p, sizeof(char *) * 4);
+const char *idx = ap_strrchr_c(ppcb_arg-key_id, ':') + 1;
 char *result;
+int i;
 
 ap_log_error(APLOG_MARK, APLOG_INFO, 0, ppcb_arg-s, APLOGNO(01969)
  Init: Requesting pass phrase from dialog filter 
  program (%s), cmd);
 
 argv[0] = cmd;
-argv[1] = ppcb_arg-key_id;
-argv[2] = NULL;
+argv[1] = apr_pstrndup(ppcb_arg-p, ppcb_arg-key_id,
+   idx - ppcb_arg-key_id - 1);
+if ((i = atoi(idx))  3) {
+argv[2] = key_types[i];
+} else {
+argv[2] = apr_pstrdup(ppcb_arg-p, idx);
+}
+argv[3] = NULL;
 
 result = ssl_util_readfilter(ppcb_arg-s, ppcb_arg-p, cmd, argv);
 apr_cpystrn(buf, result, bufsize);

Re: http://httpd.apache.org/ mini-advisory needed on 2.4.9 breakage IMO...

[Kaspar Brand]

On 11.04.2014 14:27, Jeff Trawick wrote:
 Is it just this and the SSLPassPhraseDialog exec command-line parameter
 change?  I dunno.
 
 
 
 -- Forwarded message --
 From: Jesse Defer jesse.de...@asu.edu
 Date: Thu, Apr 10, 2014 at 4:34 PM
 Subject: [users@httpd] 2.4.9 expecting DH PARAMETERS
 To: us...@httpd.apache.org us...@httpd.apache.org
 
 
 When upgrading from 2.4.7 to 2.4.9 we found that the server complained
 about missing DH PARAMETERS in our certificate and would not start.  Adding
 dhparams to it fixed it.  After some troubleshooting we found that only
 systems that did not have SSLCertificateChainFile directives with the
 intermediate certificate exhibited this problem.  Combining the server and
 intermediate certificates into the SSLCertificateFile also required adding
 dhparams.
 
 Errors:
 
 [Thu Apr 10 13:03:32.999467 2014] [ssl:emerg] [pid 27709] AH02562: Failed
 to configure certificate xxx:443:0 (with chain), check
 /usr/local/apache2/conf/xxx.crt
 [Thu Apr 10 13:03:32.999486 2014] [ssl:emerg] [pid 27709] SSL Library
 Error: error:0906D06C:PEM routines:PEM_read_bio:no start line (Expecting:
 DH PARAMETERS) -- Bad file contents or format - or even just a forgotten
 SSLCertificateKeyFile?
 AH00016: Configuration Failed

The Expecting: DH PARAMETERS error is probably a red herring - it's
most likely a leftover in the OpenSSL error stack after the
configuration of another certificate (we try to load DH parameters at
the end of ssl_init_server_certs, which in turn is called from
ssl_init_server_ctx).

Jesse, do you have multiple SSLCertificateFile directives, perhaps
on both the global and VirtualHost level? And looking at
/usr/local/apache2/conf/xxx.crt file, what are its contents when running
into the above error? Can you provide the output from egrep 'BEGIN|END'
/usr/local/apache2/conf/xxx.crt?

Kaspar

Re: svn commit: 1573360 - SSLPassPhraseDialog arguments changed in 2.4.x

[Kaspar Brand]

On 04.04.2014 12:22, Jan Kaluža wrote:
 commit 1553824 (1573360 in 2.4.x) breaks the compatibility in arguments 
 passed to exec:/path/to/program pass phrase program. This should be 
 clear from the following part of mentioned commit(s):
 
 -argv[1] = cpVHostID;
 -argv[2] = cpAlgoType;
 -argv[3] = NULL;
 +argv[1] = ppcb_arg-key_id;
 +argv[2] = NULL;
 
 Was this change intentional in trunk?

Yes, it's a consequence of no longer using a keys array which was
indexed by ssl_algo_t (see e.g. [1] for the overall motivation for
r1553824).

 If yes, I will document this, 
 because the change of mod_ssl documentation was not part of this patch.

My bad, I missed this in the docs for SSLPassPhraseDialog. I just
updated it in trunk with r1585045.

 However, I think this should not be accepted in 2.4.x branch, because it 
 breaks compatibility with external pass phrase programs in the stable 
 branch without any reason.

In 2.4.8 and later, the limit with the three named algorithms
(RSA/DSA/ECC) is gone, so there isn't a useful replacement for the
second argument (we could split off the index from the
servername:port:index, though that doesn't make it more backwards
compatible with existing SSLPassPhraseDialog programs, most likely).

Can you provide more information about the specific script/program (and
what is causing the incompatibility)? This would help in getting a
better understanding of the problem, I think.

Kaspar

[1] 
https://mail-archives.apache.org/mod_mbox/httpd-dev/201310.mbox/%3c524aa0cb.5000...@opensslfoundation.com%3E

Re: svn commit: r1583191 - in /httpd/httpd/trunk/modules/ssl: mod_ssl.c ssl_engine_config.c ssl_engine_ocsp.c ssl_private.h

[Kaspar Brand]

On 30.03.2014 21:25, yla...@apache.org wrote:
 Author: ylavic
 Date: Sun Mar 30 19:25:20 2014
 New Revision: 1583191
 
 URL: http://svn.apache.org/r1583191
 Log:
 mod_ssl: send OCSP request's nonce according to SSLOCSPUseRequestNonce 
 on/off. PR 56233.

 @@ -171,7 +174,8 @@ static int verify_ocsp_status(X509 *cert
  }
  }
  
 -if (rc == V_OCSP_CERTSTATUS_GOOD) {
 +if (rc == V_OCSP_CERTSTATUS_GOOD 
 +sc-server-ocsp_use_request_nonce != FALSE) {
  if (OCSP_check_nonce(request, basicResponse) != 1) {
  ap_log_error(APLOG_MARK, APLOG_ERR, 0, s, APLOGNO(01924)
  Bad OCSP responder answer (bad nonce));

Perhaps rewrite this as

if (rc == V_OCSP_CERTSTATUS_GOOD 
sc-server-ocsp_use_request_nonce != FALSE 
OCSP_check_nonce(request, basicResponse) != 1) {
ap_log_error(APLOG_MARK, APLOG_ERR, 0, s, APLOGNO(01924)
Bad OCSP responder answer (bad nonce));
rc = V_OCSP_CERTSTATUS_UNKNOWN;
}
}

?

 Modified: httpd/httpd/trunk/modules/ssl/ssl_private.h
 URL: 
 http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_private.h?rev=1583191r1=1583190r2=1583191view=diff
 ==
 --- httpd/httpd/trunk/modules/ssl/ssl_private.h (original)
 +++ httpd/httpd/trunk/modules/ssl/ssl_private.h Sun Mar 30 19:25:20 2014
 @@ -614,6 +614,7 @@ typedef struct {
  SSL_CONF_CTX *ssl_ctx_config; /* Configuration context */
  apr_array_header_t *ssl_ctx_param; /* parameters to pass to SSL_CTX */
  #endif
 +int ocsp_use_request_nonce;
  } modssl_ctx_t;

modssl_ctx_t isn't a public struct, so I think it's preferrable to
insert this definition four lines earlier (after ocsp_responder_timeout,
see r1059917 for a similar case).

And last but not least, can you add docs for this new directive (and an
entry in CHANGES)?

Kaspar

Re: mod_ssl patch: use new OpenSSL features to autofix cert chains

[Kaspar Brand]

On 27.03.2014 20:44, Ruediger Pluem wrote:
 Daniel Kahn Gillmor wrote:
 Do we have a robust, free tool that, given a single X.509 EE cert, can do 
 automagic fetching and trying of all
 combinations of these things and produce a reasonable PEM-encoded 
 SSLCertificateChainFile on stdout?

s/Chain// for 2.4.9 and later (see
http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertificatefile)

 If we had such a tool, then the detection code in mod_ssl could just 
 encourage people to run that tool.
 
 How about not fixing stuff in mod_ssl but only create a patch for a support 
 tool
 for httpd (like rotatelogs, etc.) that does check a cert chain and tries to 
 create
 a correct one like outlined above such that the admin can take it after 
 crosschecking
 and configure it just like today.

I would like to second that. Some adjustments in mod_ssl wrt chain
fixing (reordering, dropping self-signed root) is probably fine, but
let's not blow up the mod_ssl code unnecessarily. AIA chasing doesn't
belong there, IMO.

Kaspar

Re: [VOTE] Release Apache httpd 2.4.9 as GA

[Kaspar Brand]

On 13.03.2014 17:49, Jim Jagielski wrote:
 I'm calling a VOTE on releasing these as Apache httpd 2.4.9 GA.
 
 [ ] +1: Good to go
 [ ] +0: meh
 [ ] -1: Danger Will Robinson. And why.

+1. Perl framework tests run with mod_ssl compiled against OpenSSL
0.9.8y, 1.0.0k, 1.0.1c, 1.0.1e, 1.0.1f and (today's state of)
1.0.2-beta2-dev, no unexpected failures/regressions.

Kaspar

Re: Re: 2.4.8 This Month

[Kaspar Brand]

On 19.02.2014 14:08, Jim Jagielski wrote:
 I'd like to shoot for a TR sometime next week...
 
 On Feb 4, 2014, at 8:58 AM, Jim Jagielski j...@jagunet.com wrote:
 
 I'd like to TR and release 2.4.8 this month... Let's all take
 some time to:

  1. See what in trunk should really be backported
  2. Test and vote in STATUS backports

Small plug for a third vote for the mod_ssl backport to Remove the
hardcoded algorithm-type dependency for the SSLCertificateFile and
SSLCertificateKeyFile directives: considering that OpenSSL 1.0.2 is now
in beta (Beta 1 was released last Monday), I think it would be a nice
opportunity to have proper support for per-certificate chains with
mod_ssl in 2.4.8.

Kaspar

LogLevel inheritance/merging for VirtualHost in 2.4.x (Re: SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS))

[Kaspar Brand]

On 22.02.2014 19:17, Falco Schwarz wrote:
 Kaspar, I switched back to your version and realized, that the directive 
 SSLCertificateChainFile was always used in a VirtualHost.
 
 If the directive is in server scope, the warning is written correctly.
   

Yes, that's the underlying issue which changing cmd-server to NULL in
the ap_log_error actually uncovers: it's a somewhat (at least IMO)
unfortunate side effect of how the LogLevel for a new VirtualHost is
inherited/merged from the global LogLevel directive, or more
specifically, the order in which it happens.

If you insert LogLevel warn (or higher) in the VirtualHost block
*before* any SSLCertificateChainFile directive, then you'll see the
vhost-scope warnings on stderr (or in the log on reloads) as well.

One potential fix could consist of the attached patch for
server/config.c, though I'm not sure if it doesn't have unwanted side
effects, either (cf. r1024427 as to why it was last changed into the
opposite direction). I guess sf is the expert on this, so I'm hoping for
his views on this. Note that config.c:ap_merge_log_config() is only part
of 2.4.x, i.e. with 2.2.x, the situation is different.

Kaspar
Index: server/config.c
===
--- server/config.c (revision 1570984)
+++ server/config.c (working copy)
@@ -2195,7 +2195,7 @@ AP_CORE_DECLARE(const char *) ap_init_virtual_host
 s-keep_alive = -1;
 s-keep_alive_max = -1;
 s-error_log = main_server-error_log;
-s-log.level = APLOG_UNSET;
+s-log.level = main_server-log.level;
 s-log.module_levels = NULL;
 /* useful default, otherwise we get a port of 0 on redirects */
 s-port = main_server-port;
@@ -2237,7 +2237,7 @@ AP_DECLARE(struct ap_logconf *) ap_new_log_config(
 AP_DECLARE(void) ap_merge_log_config(const struct ap_logconf *old_conf,
  struct ap_logconf *new_conf)
 {
-if (new_conf-level != APLOG_UNSET) {
+if (new_conf-level != APLOG_UNSET  new_conf-level != DEFAULT_LOGLEVEL) 
{
 /* Setting the main loglevel resets all per-module log levels.
  * I.e. if new-level has been set, we must ignore old-module_levels.
  */

Re: mod_ssl openssl ./configure particularity

[Kaspar Brand]

On 22.02.2014 18:56, William A. Rowe Jr. wrote:
 Understood and this would explain assigning them to MOD_SSL_LIBS etc.  But
 added to MOD_LIBS?  That struck me as very odd.

Putting a module prefix into the variable name would make assembling the
commands in build/rules.mk more complex, and it seemed unnecessary at
the time. The MOD_* variables end up in modules.mk in the module's
subdir, so they don't interfere with each other.

Kaspar

Re: SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS)

[Kaspar Brand]

On 20.02.2014 21:37, Falco Schwarz wrote:
 As I read through the changed code I found a smaller issue with the 
 deprecation warning of SSLCertificateChainFile:
 
 + ap_log_error(APLOG_MARK, APLOG_WARNING|APLOG_STARTUP, 0, cmd-server,
 + APLOGNO(02559)
 + The SSLCertificateChainFile directive (%s:%d) is deprecated, 
 + SSLCertificateFile should be used instead,
 + cmd-directive-filename, cmd-directive-line_num);
 
 There seems to be an error related to this change, I guess in cmd-server?
 This warning is never logged.   

It's printed to stderr, as ssl_cmd_SSLCertificateChainFile is executed
before any ErrorLog files have been opened (when reloading with SIGHUP
or SIGUSR1, you'll see them in the error log). My primary goal was that
these warnings would be shown on the console when the config is checked
with -t, that's why I put them into ssl_engine_config.c.

Kaspar

Re: SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS)

[Kaspar Brand]

On 22.02.2014 11:06, Falco Schwarz wrote:
 Perhaps I am missing something here, but if it is printed to stderr I should 
 see it in the console when starting, right? Because I am unable to see it 
 anywhere.
 
 Even when reloading or restarting it is not written to the error log.
 It does not show up with -t either. Any clues?

Does your current config still include an SSLCertificateChainFile directive?

Kaspar

Re: SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS)

[Kaspar Brand]

On 22.02.2014 11:27, Falco Schwarz wrote:
 Yes, for testing I am currently using these directives (without comment):
 
 SSLCertificateFile  conf/ssl/foo.bar.cer# leaf only
 SSLCertificateKeyFile   conf/ssl/foo.bar.key# key only
 SSLCertificateChainFile conf/ssl/foo.bar.ca # chain only  
   

The only explanation I can imagine then is that your mod_ssl.so / httpd
binary does not include the complete mod_ssl-2.4.x-certkeyfile-v3.diff
patch. Does strings mod_ssl.so | grep AH02559 show any output?

Kaspar

Re: Segmentation faults when SSLProxyCheckPeerName On

[Kaspar Brand]

On 18.02.2014 15:53, Pavel Matěja wrote:
 Hi,
 since we've enabled SSLProxyCheckPeerName our reverserse proxy I can see
 AH00052: child pid 5711 exit signal Segmentation fault (11)
 in our logs during Nessus scans.
 
 Backend server has several X509v3 Subject Alternative Names and Nessus sends 
 just IP as Host header.
 
 We are running: Apache/2.4.7 (Unix) OpenSSL/1.0.1f
 
 Mod_backtrace says:

Are you able to grab a complete stack trace? (I'm not familiar with
reading mod_backtracke output, and the mod_ssl.so lines lack function
names, so it's hard to tell if something went wrong when checking cert
names.)

Is it limited to SSLProxyCheckPeerName on, or does it also occur with
SSLProxyCheckPeerCN on? If the former is true, then it seems that
something in ssl_util_ssl.c:SSL_X509_match_name goes wrong (that's
basically the new code path for this option).

Kaspar

Re: mod_ssl openssl ./configure particularity

[Kaspar Brand]

On 20.02.2014 04:18, William A. Rowe Jr. wrote:
 Can anyone offer background as to why httpd 2.4 branch ./configure likes
 
 checking for OpenSSL... checking for user-provided OpenSSL base
 directory... /usr/local/ssl adding -I/usr/local/ssl/include to
 CPPFLAGS setting MOD_CFLAGS to -I/usr/local/ssl/include 
   setting ab_CFLAGS to -I/usr/local/ssl/include 
   setting MOD_LDFLAGS to -L/usr/local/ssl/lib 
 checking for OpenSSL version = 0.9.8a... OK
   adding -lssl to MOD_LDFLAGS
   adding -lcrypto to MOD_LDFLAGS
   adding -luuid to MOD_LDFLAGS
   adding -lrt to MOD_LDFLAGS
   adding -lcrypt to MOD_LDFLAGS
   adding -lpthread to MOD_LDFLAGS
   adding -ldl to MOD_LDFLAGS
   setting LIBS to -lssl -lcrypto   -luuid -lrt -lcrypt  -lpthread -ldl
   forcing ab_LDFLAGS to -L/usr/local/ssl/lib  -lssl -lcrypto -luuid
 -lrt -lcrypt -lpthread -ldl
 
 instead of MOD_SSL_CFLAGS, MOD_SSL_LDFLAGS, and MOD_SSL_LIBS?

This was added with r1385216, to support per-subdir MOD_* variables,
see the discussion starting at [1]. Previously, there was no way for a
module to make sure that its specific {C,LD}FLAGS were inserted first.

Kaspar

[1]
https://mail-archives.apache.org/mod_mbox/httpd-dev/201208.mbox/%3C502D3DAF.2010402%40velox.ch%3E