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. 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
On Sat, Apr 19, 2014 at 8:19 AM, Kaspar Brand httpd-dev.2...@velox.ch wrote: 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. [2] https://mail-archives.apache.org/mod_mbox/httpd-dev/201402.mbox/%3c53057121.70...@opensslfoundation.com%3E Oh my, I must have completely forgotten about [2]. I am sorry, I didn't intend to reopen the same issue again. Like Steve said, the right thing would probably be that OpenSSL actually returns the private key used by the connection. (and apologies Harald, I got confused by the displayed name.)
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]
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: DH params and multiple certificates in one VHost
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. Thank you, Kaspar. On Sat, Apr 19, 2014 at 9:11 AM, Kaspar Brand httpd-dev.2...@velox.ch wrote: 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
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 (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: Any reason why building with OpenSSL shouldn't add its lib dir to rpath?
On Apr 14, 2014, at 13:30, Yann Ylavic ylavic@gmail.com wrote: I usually force it with ./configure LDFLAGS=-Wl,-rpath -Wl,/path/to/my/openssl. +1 to have this automagically done according to --with-ssl So that should solve the problem I have on Debian where I can't get my version of Apache to use my version of openssl! I tried to remove my system version of OpenSSL but ran into too many dependency issues that I wasn't willing to deal with. Kind regards, -Tom
Re: Any reason why building with OpenSSL shouldn't add its lib dir to rpath?
On 2014-04-19 10:47, Tom Browder wrote: On Apr 14, 2014, at 13:30, Yann Ylavic ylavic@gmail.com wrote: I usually force it with ./configure LDFLAGS=-Wl,-rpath -Wl,/path/to/my/openssl. +1 to have this automagically done according to --with-ssl So that should solve the problem I have on Debian where I can't get my version of Apache to use my version of openssl! I tried to remove my system version of OpenSSL but ran into too many dependency issues that I wasn't willing to deal with. Hi Tom, with apache 2.2.x or 2.4.x ? On FreeBSD 10 (with openssl-1.0.x) in the base system and the same version in the ports we saw a similar issue. LDFLAGS= -L/path/to/ports/openssl/lib was not honored by apache 2.2, but by apache 2.4 and by apr/apr-util The following hack solved this: sed -e s|(ALL_CFLAGS)|(ALL_CFLAGS) -L/path/to/ports/openssl/lib| build/rules.mk.in -- olli
Re: Any reason why building with OpenSSL shouldn't add its lib dir to rpath?
On Fri, Apr 18, 2014 at 2:39 PM, Rainer Jung rainer.j...@kippdata.dewrote: Hi Jeff, On 14.04.2014 13:08, Jeff Trawick wrote: (not to say there aren't complications, like trying to keep system directories out of rpath) See a related discussion from 2011 RUNPATH for module dependencies on Unix/Linux e.g. here: http://markmail.org/message/guastewy5uvn36s7 Joe had some interesting remarks in that discussion. Regards, Rainer Good technical stuff. There are always scary reasons that are bona fide :) People with modest Linux/Unix skills (generally on Linux) often don't know what to do (especially if it seems to work but picks up the wrong library), as the recent go-update-OpenSSL fun demonstrated. It is hard to see that documentation is going to fix this unless we have much more user guide material and somehow draw attention to that. (FWLIW, one can borrow a bit about what libtool knows: libtool --config | grep sys_lib_dlsearch_path_spec) -- Born in Roswell... married an alien... http://emptyhammock.com/ http://edjective.org/
Re: mod_cache thundering herd bug
On Tue, Apr 8, 2014 at 4:11 PM, Jim Riggs apache-li...@riggs.me wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=50317 While we are at ApacheCon, I would love to address this nasty bug with someone familiar with 2.2's mod_cache. Our sites were brought down a few times last year before we finally tracked it down to being this particular bug. I am using a crude backport of the 2.3 patch (r1023398) in 2.2. It works, but I don't know if it is correct. Can someone look at this one with me? We really need to get this fixed in 2.2, because there is NO thundering herd protection at all as things stand right now. Graham -- related subject brought up either in Denver or in the bug. It seems that when we serve a stale file while the cache is locked, the age headers are small instead of large. I got totally lost trying to track down the issue, maybe it makes sense to you? It's almost as if they time of the revalidation is somehow updated early and the delta in the stale cache hits is based off of that. -- Eric Covener cove...@gmail.com
Re: Any reason why building with OpenSSL shouldn't add its lib dir to rpath?
On Apr 19, 2014, at 12:06, olli hauer oha...@gmx.de wrote: Hi Tom, with apache 2.2.x or 2.4.x ? 2.4.7 at the moment but moving to latest release where I'll try forcing the local OpenSSL use. I raised this issue earlier but it got no traction-- probably because I didn't articulate the problem well enough. IMHO the '--with-OpenSSL=' option could benefit from the RPATH nudge suggested by Yann (or at least suggest that move for users unwilling or unable to remove the current system OpenSSL). Regards, -Tom
Re: Any reason why building with OpenSSL shouldn't add its lib dir to rpath?
2.2 2014-04-20 5:13 GMT+08:00, Tom Browder tom.brow...@gmail.com: On Apr 19, 2014, at 12:06, olli hauer oha...@gmx.de wrote: Hi Tom, with apache 2.2.x or 2.4.x ? 2.4.7 at the moment but moving to latest release where I'll try forcing the local OpenSSL use. I raised this issue earlier but it got no traction-- probably because I didn't articulate the problem well enough. IMHO the '--with-OpenSSL=' option could benefit from the RPATH nudge suggested by Yann (or at least suggest that move for users unwilling or unable to remove the current system OpenSSL). Regards, -Tom
