About PR56925's fix (was: svn commit: r1682872 - /httpd/httpd/branches/2.4.x/STATUS)
Hi Rainer, On Mon, Jun 1, 2015 at 1:06 PM, rj...@apache.org wrote: @@ -232,14 +238,14 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: trunk patch: http://svn.apache.org/r1681694 2.4.x patch: trunk works (modulo CHANGES) +1: ylavic + rjung: Would it makes sense to handle 500/503 for the other proxy +protocols similar? I see error_override at least also in the +AJP and FCGI case. I'll have a look at these, looks consitent to do it there too. + rjung: What about setting the note proxy-error-override in general +if an error override happens so it might get more uses in +the future. Would that make sense? I'm not sure to understand here, what would be a general way to set the note? It seems to me that each (proxy) module only can tell whether the error comes from itself or the backend.
Re: ALPN patch comments
Am 29.04.2015 um 13:05 schrieb Kaspar Brand: 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). Question on that ALPN backport patch and the one in the STATUS file: is it clear that the registration setting up the propose and nego callback function arrays should be per connection? Wouldn't that be more a global or per vhost thing? Just asking because of performance reasons. Regards, Rainer
Re: ALPN patch comments
It sounds like it could be a vhost thing. SSL_CTX is most likely not global, but maybe unique for a vhost? I am not certain myself, maybe someone else with more knowledge of mod_ssl could pitch in? //Stefan Am 01.06.2015 um 13:04 schrieb Rainer Jung rainer.j...@kippdata.de: Am 29.04.2015 um 13:05 schrieb Kaspar Brand: 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). Question on that ALPN backport patch and the one in the STATUS file: is it clear that the registration setting up the propose and nego callback function arrays should be per connection? Wouldn't that be more a global or per vhost thing? Just asking because of performance reasons. Regards, Rainer green/bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: About PR56925's fix (was: svn commit: r1682872 - /httpd/httpd/branches/2.4.x/STATUS)
Am 01.06.2015 um 13:36 schrieb Yann Ylavic: Hi Rainer, On Mon, Jun 1, 2015 at 1:06 PM, rj...@apache.org wrote: @@ -232,14 +238,14 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: trunk patch: http://svn.apache.org/r1681694 2.4.x patch: trunk works (modulo CHANGES) +1: ylavic + rjung: Would it makes sense to handle 500/503 for the other proxy +protocols similar? I see error_override at least also in the +AJP and FCGI case. I'll have a look at these, looks consitent to do it there too. + rjung: What about setting the note proxy-error-override in general +if an error override happens so it might get more uses in +the future. Would that make sense? I'm not sure to understand here, what would be a general way to set the note? It seems to me that each (proxy) module only can tell whether the error comes from itself or the backend. I meant set it always if a ProxyErrorOverride happens, not set it if we need it for the 500/503 check later. Maybe this is (for http) already the case, not sure about possible code paths for ProxyErrorOverride. Rainer
Re: httpd and OpenSSL 1.0.2
On Wed, May 27, 2015 at 11:33 AM, Mario Brandt jbl...@gmail.com wrote:
Hi Tom,
I tried on Debian 7 and 8 both x64
To see your configure options would help a lot.
Okay, here's what I had to do to my Linux Deb 7, 64-bit system:
1. Remove any deb packages of httpd, apr, apr-util, openssl.
2. Source packages used (in order of installation):
openssl-1.0.2a.tar.gz
apr-1.5.1.tar.bz2
apr-util-1.5.4.tar.bz2
pcre2-10.00.tar.bz2
httpd-2.4.12.tar.bz2
3. Build and install:
$ sudo aptitude install zlib1g-dev
openssl
---
export SSLDIR=/opt/openssl
./config \
no-ec2m \
no-rc5 \
no-idea \
threads \
zlib-dynamic\
shared \
--prefix=${SSLDIR} \
--openssldir=${SSLDIR} \
enable-ec_nistp_64_gcc_128 \
make depend
make
make test
sudo make install
apr
./configure --with-crypto
make
make check
sudo make install
apr-util
--
./configure --with-apr=/usr/local/apr
make
make check
sudo make install
pcre
--
./configure
make
make check
sudo make install
httpd
---
\# we build all modules for now (all shared except mod_ssl)
# Note that 'session_module' needs to be activated (loaded).
export LDFLAGS=-Wl,-rpath,${SSLDIR}/lib
$SRCDIR/configure \
--prefix=/usr/local/apache2\
--with-included-apr\
\
--enable-ssl \
--enable-ssl-staticlib-deps\
--enable-mods-static=ssl \
--with-ssl=${SSLDIR} \
\
--enable-mods-shared=reallyall \
--with-perl\
--with-python \
--enable-layout=Apache \
--with-pcre=/usr/local/bin/pcre-config \
--without-ldap \
--enable-session-crypto\
--with-crypto \
--with-openssl=${SSLDIR}
make
sudo make install
Notes:
1. I used both local install of apr/apr-util AND source inside httpd.
2. Note --with-crypto option for apr in local build
3. Note I have not modified my LD_LIBRARY_PATH for any of the above programs.
It all works for me.
Hope that helps.
Best regards,
-Tom
Re: mod_ssl: Reading dhparams and ecparams not only from the first certificate file
Am 27.05.2015 um 09:33 schrieb Rainer Jung: Am 27.05.2015 um 08:40 schrieb 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. OK 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). Thanks for the correction. 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. OK I'll have a look at the docs an see whether I can improve them. [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 I edited the mod_ssl docs and faq in r1682923 and r1682937 (trunk), r1682929 and r1682939 (2.4) and r1682942 (2.2). I hope things are at least as clear as before my editing. Regards, Rainer
Re: httpd and OpenSSL 1.0.2
On Mon, Jun 1, 2015 at 10:22 AM, Tom Browder tom.brow...@gmail.com wrote: Okay, here's what I had to do to my Linux Deb 7, 64-bit system: ... 2. Source packages used (in order of installation): ... pcre2-10.00.tar.bz2 Oops, my error: I had to use pcre-8.36 (httpd cannot yet use pcre2). Best, -Tom
Re: httpd and OpenSSL 1.0.2
Hi Tom, since I'm mostly a windows user and sure how to debug that and wasn't successful, it would be nice if you could give me the working script. Thanks Mario
Re: Good at assembler ? (Was:httpd - side channel attack - timing of digest comparisons)
On Fri, May 29, 2015 at 12:11 PM, Dirk-Willem van Gulik
di...@webweaving.org wrote:
So if you have the time can read assembler well - can you compile this at
a reasonable optimizer setting and look at the assembler to confirm that key
elements are not somehow optimized away; i.e. the innner loop is running in
constant time. I am fairly sure about what happens on ARM and x386 — but
modern x86 is largely voodoo to me.
Does the !! pattern really avoid conditional branches on any compiler?
It does compile to test %src,%src; setne %dst on all the gcc I
tested (4.4 = 4.8), but I'm not sure older ones (or other
compilers/archs) would not use a conditional jump instead.
Maybe we could use libressl's pattern instead, something like:
int ap_timingsafe_strcmp_mod(const char * hostile, const char * toProtect)
{
const unsigned char *p1 = (const unsigned char *)hostile;
const unsigned char *p2 = (const unsigned char *)toProtect;
int res = 0, done = 0;
size_t i = 0, i1 = 1, i2 = 1;
int d1 = 1, d2 = 1;
do {
/* lt is -1 if p1[i] p2[i]; else 0. */
int lt = (p1[i % i1] - p2[i % i2]) 8;
/* gt is -1 if p1[i] p2[i]; else 0. */
int gt = (p2[i % i2] - p1[i % i1]) 8;
/* cmp is 1 if p1[i] p2[i]; -1 if p1[i] p2[i]; else 0. */
int cmp = lt - gt;
/* set res = cmp if !done. */
res |= cmp ~done;
/* set done if p1[i] != p2[i]. */
done |= lt | gt;
d1 = ~((p1[i % i1] - 1) 8);
d2 = ~((p2[i % i2] - 1) 8);
i++;
i1 += d1;
i2 += d2;
} while (d1); // we reveal the length of the hostile string.
return res;
}
(note that the difference in lengths is handled by comparing the
shortest string's NUL with the char at the same position in the other
string, and that the choosen types avoid casting issues) .
Secondly - when we get to the end of the shorter string; we can either keep
comparing to the last char or \0; or we go ‘modulo’ to the start of the
string. Now modulo is perhaps not ideal; and seems to affect the pipeline on
the XEON cpu (something I confess not to quite understand; and I cannot
see/replicate on ARM).
Either way, we may leak timing differences because if the protected
string would have been longer, we possibly would have loaded a new
page and/or not reused cached data, and that's probably measurable.
IMHO we can't really have a satisfactory timing safe strcmp, and we
should use a different strategy to protect NUL terminated strings.
For example, we could always allocate a fixed (maximum) size for these
strings (eg. 256 bytes for a password), and compare the hostile
strings up to the minimum of this size and strlen(hostile), using
timing safe memcmp().
Re: PMC Reporting [Was: Re: 2.2 and 2.4 and 2.6/3.0]
On 5/30/2015 9:03 PM, William A Rowe Jr wrote: So I'll let Eric share what he submitted for May on our behalf, but here is the submitted/accepted/recorded report of Feb '15 - it's awfully high level, so I'm not sure that updating dev@ regularly with the contents offers a whole lot of benefit. Thoughts? Yeah - The information seems great to share with the community behind httpd, IMO, so I think it would make sense to have on the dev@ list... and it's not like this is a particularly low volume mailing list that such emails would be considered inbox pollution. I guess it's just as easy to pull up the minutes each month by hand, too. -- Daniel Ruggeri
Re: PMC Reporting [Was: Re: 2.2 and 2.4 and 2.6/3.0]
There's usually just not much to it. Here's what was last submitted: Report from the Apache HTTP Server project [Eric Covener] ## Description: The Apache HTTP Server Project develops and maintains an open-source HTTP server for modern operating systems. ## Activity: Overall project activity is low, with various fixes being made on maintenance releases but very little forward development. Third-party work on an HTTP/2 module was discussed more this reporting period, with some enablement work for ALPN revived in mod_ssl. No security issues have required new releases, so patches have collected a little longer than normal in the stable releases. ## Issues: There are no issues requiring board attention at this time. ## PMC/Committership changes: - Currently 112 committers and 43 PMC members in the project. - Christophe Jaillet was added to the PMC on Mon Mar 09 2015 - Stefan Sperling was added as a committer on Fri Apr 17 2015 ## Releases: - Last 2.4.x release was 2.4.12 on Jan 26 2015 - Last 2.2.x release was 2.2.29 on September 3 2014 On Mon, Jun 1, 2015 at 8:14 PM Daniel Ruggeri drugg...@primary.net wrote: On 5/30/2015 9:03 PM, William A Rowe Jr wrote: So I'll let Eric share what he submitted for May on our behalf, but here is the submitted/accepted/recorded report of Feb '15 - it's awfully high level, so I'm not sure that updating dev@ regularly with the contents offers a whole lot of benefit. Thoughts? Yeah - The information seems great to share with the community behind httpd, IMO, so I think it would make sense to have on the dev@ list... and it's not like this is a particularly low volume mailing list that such emails would be considered inbox pollution. I guess it's just as easy to pull up the minutes each month by hand, too. -- Daniel Ruggeri
