Re: ocsp stapling improvements
On Tue, 20 Jun 2017 13:39:56 +0200 Stefan Eissing <stefan.eiss...@greenbytes.de> wrote: > Can we push the burden of getting a OCSP response to the client, even > for must-staple certificates? No, you can't. The whole point is that must staple enforces stapling. This has a bit to do with the history of certificate revocation and why it's broken. All browsers do OCSP checks in a soft-fail mode (or not at all). This basically makes it pointless, as an attacker can just block OCSP requests. OCSP stapling was invented to move away from that unreliable mechanism. Must-staple enforces that mechanism. There is no way to fall back to the old unreliable mechanism if you want to have it secure. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
Re: ocsp stapling improvements
Hi, On Mon, 12 Jun 2017 17:25:39 +0200 Stefan Eissing <stefan.eiss...@greenbytes.de> wrote: > 1. Hand out existing responses until expired > 2. Persist responses (is this just a config/default issue?) > 3. Start update responses at server start/regular intervals > 4. Use something better than HTTP/1.0 requests 1-3 covers the important issues, I'm not sure http/1.0 is a major problem. Are there any problems with that / CAs that serve OCSP only over HTTP/1.1? (to be clear: certainly desirable to have a better solution here, but I feel that isn't the most important issue.) What I think needs also be handled: * There's https://bz.apache.org/bugzilla/show_bug.cgi?id=59049 which indicates that faulty responses from the OCSP server may bring the server into a faulty state from which it doesn't recover. I haven't tried to reproduce this, but it certianly should be fixed as well, probably just some missing error check tough. * Some of the existing options imho don't make any sense and should default to off and maybe even be forced off (so that setting them to "on" doesn't do anything). That includes SSLStaplingFakeTryLater and SSLStaplingReturnResponderErrors. Unless I'm missing something I don't see any situation in which stapling OCSP errors is desirable. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
Re: Broken OCSP Stapling
On Tue, 6 Jun 2017 10:48:44 +0200 Stefan Eissing <stefan.eiss...@greenbytes.de> wrote: > did you receive any reply on this from a httpd dev? Unfortunately I haven't received any reply. > If not, who would be a good contact at Linux Foundation / Core Infra > to talk to? I'll answer that in a private mail, don't want to give contact info on a public mailing list. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
Re: Broken OCSP Stapling
Hi, On Wed, 31 May 2017 07:45:23 -0500 Jim Riggs <apache-li...@riggs.me> wrote: > This was mentioned in today's Bulletproof TLS newsletter > (https://www.feistyduck.com/bulletproof-tls-newsletter/issue_28_lets_encrypt_downtime.html): > > https://blog.hboeck.de/archives/886-The-Problem-with-OCSP-Stapling-and-Must-Staple-and-why-Certificate-Revocation-is-still-broken.html I'm the author of that post, thanks for bringing that up. In the meantime I found that there are even more bugs in the apache bz that are unhandled that sound quite concerning. This one https://bz.apache.org/bugzilla/show_bug.cgi?id=59049 is imho a security vulnerability, yet it's been ignored for over a year. Please note also that I had some conversations with the Linux Foundation / Core Infrastructure Initiative about OCSP stapling and hey indicated that they would consider to provide funding if there's an effort to improve the situation. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
Re: FYI brotli
On Mon, 16 Jan 2017 18:06:40 -0600 William A Rowe Jr <wr...@rowe-clan.net> wrote: > If so, maybe we teach both to step out of the way when SSL encryption > filters are in place? This would make no sense. Brotli is only supported over HTTPS by browsers. Compression-based attacks are a tricky problem, however someone has yet to show that they are abused in practice. But preventing deployment of a new compression algorithm doesn't help. You'd have to disable compression altogether to avoid them. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
[patch] limiting bcrypt running time in apr / apr-util
Hi,
The bcrypt hash in htpasswd files can be abused for denial of service,
for a background see [1].
I had discussed this in a couple of mails with the apache security
team, but they asked me to move further discussions here on the public
mailing list. (I don't want to further discuss whether or not this is a
security vuln, I think we won't come to an agreement here.)
Anyway: In apr there was a commit to limit the running time of bcrypt
to 17 (which is a couple of seconds on a modern system and much saner
than the previous maximum of 31):
https://svn.apache.org/viewvc?view=revisionrevision=1772803
However that's only half of it. This limits the creation of hashes, but
not the verification. This was patched in a wrong way here (sorry for
that, patch came from me):
https://svn.apache.org/viewvc?view=revisionrevision=1773929
and subsequently reverted here:
https://svn.apache.org/viewvc?view=revisionrevision=1774976
A check in BF_crypt needs to happen, but a few lines above (one could
argue that this if clause itself is very ugly and should be replaced
with some atoi-stuff, but I've not done that for now):
--- crypto/crypt_blowfish.c (revision 1778111)
+++ crypto/crypt_blowfish.c (working copy)
@@ -675,9 +675,9 @@
setting[2] < 'a' || setting[2] > 'z' ||
!flags_by_subtype[(unsigned int)(unsigned char)setting[2]
- 'a'] || setting[3] != '$' ||
- setting[4] < '0' || setting[4] > '3' ||
+ setting[4] < '0' || setting[4] > '1' ||
setting[5] < '0' || setting[5] > '9' ||
- (setting[4] == '3' && setting[5] > '1') ||
+ (setting[4] == '1' && setting[5] > '7') ||
setting[6] != '$') {
__set_errno(EINVAL);
return NULL;
Attached a patch for apr trunk with this change and a patch for the 1.5
branch with both changes.
Please apply.
[1]
https://blog.fuzzing-project.org/56-htpasswDoS-Local-Denial-of-Service-via-Apache-httpd-password-hashes.html
--
Hanno Böck
https://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
Index: crypto/crypt_blowfish.c
===
--- crypto/crypt_blowfish.c (revision 1778111)
+++ crypto/crypt_blowfish.c (working copy)
@@ -675,9 +675,9 @@
setting[2] < 'a' || setting[2] > 'z' ||
!flags_by_subtype[(unsigned int)(unsigned char)setting[2] - 'a'] ||
setting[3] != '$' ||
- setting[4] < '0' || setting[4] > '3' ||
+ setting[4] < '0' || setting[4] > '1' ||
setting[5] < '0' || setting[5] > '9' ||
- (setting[4] == '3' && setting[5] > '1') ||
+ (setting[4] == '1' && setting[5] > '7') ||
setting[6] != '$') {
__set_errno(EINVAL);
return NULL;
--- a/crypto/crypt_blowfish.c 2012-07-06 13:41:24.0 +0200
+++ apr-util-1.5.4/crypto/crypt_blowfish.c 2017-01-10 12:05:56.449895464 +0100
@@ -675,9 +675,9 @@
setting[2] < 'a' || setting[2] > 'z' ||
!flags_by_subtype[(unsigned int)(unsigned char)setting[2] - 'a'] ||
setting[3] != '$' ||
- setting[4] < '0' || setting[4] > '3' ||
+ setting[4] < '0' || setting[4] > '1' ||
setting[5] < '0' || setting[5] > '9' ||
- (setting[4] == '3' && setting[5] > '1') ||
+ (setting[4] == '1' && setting[5] > '7') ||
setting[6] != '$') {
__set_errno(EINVAL);
return NULL;
@@ -877,7 +877,7 @@
const char *input, int size, char *output, int output_size)
{
if (size < 16 || output_size < 7 + 22 + 1 ||
- (count && (count < 4 || count > 31)) ||
+ (count && (count < 4 || count > 17)) ||
prefix[0] != '$' || prefix[1] != '2' ||
(prefix[2] != 'a' && prefix[2] != 'y')) {
if (output_size > 0) output[0] = '\0';
Re: Possible mod_ssl's backports to 2.2.x? (was: Looking ahead to 2.4.13 / 2.2.30)
I haven't used apache 2.2, but isn't OCSP stapling support still missing there? I think if you're already working on backporting important TLS features that should certainly go with them. -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgpNXAgtjh1Er.pgp Description: OpenPGP digital signature
Re: [RFC] Enable OCSP Stapling by default in httpd trunk
Am Thu, 30 Oct 2014 10:51:15 -0400 schrieb Jeff Trawick traw...@gmail.com: # 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.) Could this be made a bit more precise? What's more than a few certificates? Preferrably there should be some rough calculation (certs*Xkb) that gives a safe margin for the space. -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 signature.asc Description: PGP signature
state of mod_spdy ?
Hello, I wanted to try spdy on my webservers. It seems currently the situation is a bit confusing. There's the original google location of mod_spdy but it says its basically deprecated and the code has been moved to apache's svn. https://code.google.com/p/mod-spdy/ Here's apache's repo: https://svn.apache.org/viewvc/httpd/mod_spdy/trunk/ It seems its not very active. And it doesn't even have any build instructions. I tried applying the google-code-build-instructions to it, but failed. There seems to be no straightforward way to use this. Then there seems to be an inofficial git repo: https://github.com/eousphoros/mod-spdy It builds and I can load and enable it, but it doesn't work (can't connect any more to https sites when I enable it). So what's the reference place of spdy support for apache? Is there any active development happening right now? cu, -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 signature.asc Description: PGP signature
Re: SSL and NPN
On Tue, 29 Apr 2014 07:05:29 +0200 Falco Schwarz hid...@falco.me wrote: AFAIK OpenSSL does not support NPN out of the box either and obe would have to apply patches to the openssl-src in order to get NPN support. In OpenSSL 1.0.2 ALPN support has been added, though. OpenSSL 1.0.1 supports NPN out of the box. -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 signature.asc Description: PGP signature
Re: Streamlining/improving ephemeral key handling in mod_ssl?
On Mon, 30 Sep 2013 18:40:28 +0200 Kaspar Brand httpd-dev.2...@velox.ch wrote: Testing patches and reporting on its results e.g. (as previously solicited in this thread). I have put a backport of the relevant trunk commits under https://people.apache.org/~kbrand/mod_ssl-2.4.x-ekh.diff I found that this doesn't apply cleanly on released apache, but it's mostly due to doc rejects. https://svn.schokokeks.org/repos/overlay/trunk/www-servers/apache/files/apache-2.4.6-modssl-dhparams.diff is the patch minus some documentation parts re-diffed against 2.4.6 release. I'm running this now on some test servers (I previously had other preliminaty dh patches from the bugtracker). I like the auto-selection due to rsa key size. Works for me now, I have tested different RSA key sizes on one server and I get different DH moduli: https://www.ssllabs.com/ssltest/analyze.html?d=2048.dosdriver.de https://www.ssllabs.com/ssltest/analyze.html?d=backup1.schokokeks.org No issues so far, so from me: Tested and works. and I'm glad this finally gets some attention. and will soon add it as a proposal to 2.4.x/STATUS (if my remaining tests with 2.4.6-dev are successful). The backport proposal then needs consensus approval, as explained under http://httpd.apache.org/dev/guidelines.html, so at least two +1 from other devs are needed as well. I'm not an apache dev, but you get +1 from me for backporting :-) Hanno -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 signature.asc Description: PGP signature
Re: Streamlining/improving ephemeral key handling in mod_ssl?
On Wed, 25 Sep 2013 07:35:10 +0200 Kaspar Brand httpd-dev.2...@velox.ch wrote: Thanks Joe and Rüdiger for your feedback. I'm going to finish and commit part1 of the patch next (which seems uncontroversial), and wait a few more days for opinions re: OpenSSL 0.9.8a, see also the separate thread. Thanks a lot that there's finally some movement here. What needs to happen so this can be backported to 2.4? Regarding the discussion on ietf-tls happening right now, it'd be a good signal if apache would support larger DH parameters soon. -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 signature.asc Description: PGP signature
Re: Diffie-Hellman group parameters 1024 bit and Perfect Forward Secrecy
Hi, As far as I can see, this got no reply yet from an apache dev. Why the silence? Could at least someone comment? On Fri, 28 Jun 2013 09:46:27 +0200 Hanno Böck ha...@hboeck.de wrote: There's been a patch in bugzilla for a while to allow user-defined DH parameters, however it hasn't gotten any attention by apache developers yet: https://issues.apache.org/bugzilla/show_bug.cgi?id=49559 To be more precise: - Has anyone with commit permissions reviewed the patch yet? - What needs to happen that it can be committed? I really think this is a relevant security issue that should be worked on. cu, -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 signature.asc Description: PGP signature
Diffie-Hellman group parameters 1024 bit and Perfect Forward Secrecy
Hi, There has been lately some attention to perfect forward secrecy in TLS, mainly due to an article on netcraft: http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html What worries me is that apache still fixes the DH group size to 1024 bit. If one uses an RSA key with, e.g., 2048 bit, then using a DHE TLS cipher will actually downgrade the security of the connection. DLP or factoring-based public key cryptography with 1024 bit has been known to be potentially week for quite some time now. NIST recommended to phase out 1024 bit keys by 2010. (we don't have a key here, but the security of a DHE group with 1024 bit is equivalent to a 1024 bit DSA key) There's been a patch in bugzilla for a while to allow user-defined DH parameters, however it hasn't gotten any attention by apache developers yet: https://issues.apache.org/bugzilla/show_bug.cgi?id=49559 I'd like to ask apache devs to raise some attention to this issue. I think user-defined dh groups would be a good thing, but probably the default should also be raised to e.g. 2048 bit. cu, -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 signature.asc Description: PGP signature
mod_fcgid 2.3.5 release ?
Hi, Today I stepped over the upload corruption bug affecting the current 2.3.4 version of mod_fcgid: http://drupal.org/node/635270 http://www.mail-archive.com/dev@httpd.apache.org/msg46230.html As this is a rather serious issue, I wanted to ask if you can push a new release of mod_fcgid. I think this really deserves a fast new release. -- Hanno Böck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber/Mail:ha...@hboeck.de http://schokokeks.org - professional webhosting signature.asc Description: This is a digitally signed message part.
