Re: http2 tests

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

Re: H2 compatible ciphers

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

Re: this expected?

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

Re: [VOTE] Release Apache httpd 2.4.17 as GA

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

Re: SSLUseStapling: ssl handshake fails until httpd restart

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=

Re: SSLUseStapling: ssl handshake fails until httpd restart

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,

Re: SSLUseStapling: ssl handshake fails until httpd restart

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

Re: Disable SSLv3 by default

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/do

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

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

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

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

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

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: "unsolicit

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

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

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

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

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

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

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

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

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

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

Re: Using UPN from subjectAltName with SSLUserName

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

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

Re: Using UPN from subjectAltName with SSLUserName

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

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

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

Re: Using UPN from subjectAltName with SSLUserName

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

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

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

Re: Using UPN from subjectAltName with SSLUserName

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:

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

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

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

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

Re: mod_ssl: inline SSL_X509_INFO_load_path(); please review

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

Re: ALPN patch comments

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

Re: OpenSSL 1.02, PCRE 2.10

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:

Re: OpenSSL 1.02, PCRE 2.10

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

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))

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

Re: ALPN patch comments

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,

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

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

Re: ALPN patch comments

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,

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

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

Re: ALPN patch comments

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

Re: ALPN patch comments

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

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

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

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

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

Re: check for RAND_egd at configure time

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

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

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

Re: namespacing in mod_ssl

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_

Re: check for RAND_egd at configure time

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 === ---

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

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

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

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

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

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,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: Older clients stopped working after server disabled SSLv3

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

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

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

Re: Older clients stopped working after server disabled SSLv3

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

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

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

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

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

Re: Server(_rec) unique identifier

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

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

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

Re: Older clients stopped working after server disabled SSLv3

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

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

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

Re: Disable SSLv3 by default

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

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

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

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

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

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

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

Re: yet another mod_ssl temp DH handling tweak

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

Re: mod_ssl SSL session timeout

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

Re: mod_ssl SSL session timeout

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

Re: Memory leak in mod_ssl ssl_callback_TmpDH

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

Re: Memory leak in mod_ssl ssl_callback_TmpDH

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

Re: Memory leak in mod_ssl ssl_callback_TmpDH

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

Re: SSL_CLIENT_S_DN_x509 and subjectAltName

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

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

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

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

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

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

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 + *

Re: apache hintlist

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

Re: DH params and multiple certificates in one VHost

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

Re: SSL_CTX_get_{first,next}_certificate

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

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

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

Re: DH params and multiple certificates in one VHost

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.

Re: DH params and multiple certificates in one VHost

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]

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

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

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

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

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

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

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

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 =

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

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

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

[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

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

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

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

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] =

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

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

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

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?

Re: [VOTE] Release Apache httpd 2.4.9 as GA

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

Re: Re: 2.4.8 This Month

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.

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))

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.

Re: mod_ssl openssl ./configure particularity

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

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

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

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

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

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

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

Re: Segmentation faults when SSLProxyCheckPeerName On

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

Re: mod_ssl openssl ./configure particularity

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

  1   2   3   4   >