Plüm, Rüdiger, VF-Group wrote:
Committed v10 with some smaller tweaks as r768499.
Thanks - I'm fine with them!
Also, I'm glad to see that the proposed default for
SSLStrictSNIVHostCheck is off (and hope that it will stay like this :-).
A default of On would imply that users have to explicitly
Mind to sent a version v9 of your patch such that I can review the
complete one again? Thanks for your efforts.
Sorry, please disregard v9 - it makes SSL_VERIFY_CLIENT report GENEROUS
even in cases where it could/should be SUCCESS, actually (if the CA list
stays the same; i.e., v9 doesn't
-Ursprüngliche Nachricht-
Von: Kaspar Brand
Gesendet: Samstag, 25. April 2009 09:37
An: dev@httpd.apache.org
Betreff: Re: SNI in 2.2.x (Re: Time for 2.2.10?)
Mind to sent a version v9 of your patch such that I can review the
complete one again? Thanks for your efforts
Betreff: Re: SNI in 2.2.x (Re: Time for 2.2.10?)
Mind to sent a version v9 of your patch such that I can review the
complete one again? Thanks for your efforts.
Sorry, please disregard v9 - it makes SSL_VERIFY_CLIENT
report GENEROUS
even in cases where it could/should be SUCCESS, actually
On 04/25/2009 11:20 AM, Plüm, Rüdiger, VF-Group wrote:
Committed v10 with some smaller tweaks as r768499. Especially I removed
@@ -186,16 +186,6 @@ int ssl_hook_ReadReq(request_rec *r)
return HTTP_BAD_REQUEST;
}
}
-else if (r-connection-vhost_lookup_data)
-Ursprüngliche Nachricht-
Von: Kaspar Brand
Gesendet: Freitag, 24. April 2009 07:15
An: dev@httpd.apache.org
Betreff: Re: SNI in 2.2.x (Re: Time for 2.2.10?)
Plüm, Rüdiger, VF-Group wrote:
As I said further down below I see also good and valid use
cases
Plüm, Rüdiger, VF-Group wrote:
Comparing against anything else but 'SUCCESS' is IMHO a flaw in the
configuration. 'GENEROUS' IMHO only says that some kind of
certificate was sent at all.
That's also my interpretation. Depending on what the exact meaning of
'GENEROUS' should be in our
-Ursprüngliche Nachricht-
Von: Kaspar Brand
Gesendet: Mittwoch, 22. April 2009 09:12
An: dev@httpd.apache.org
Betreff: Re: SNI in 2.2.x (Re: Time for 2.2.10?)
Ruediger Pluem wrote:
the next configuration *can* do security harm:
VirtualHost foo.example.com:443
Plüm, Rüdiger, VF-Group wrote:
As I said further down below I see also good and valid use cases for the
combination
SSLVerifyClient optional
and
%{SSL_CLIENT_VERIFY}
And this combination should be safe even if this comes at the price that
some configuration are not possible without SNI. But
Ruediger Pluem wrote:
the next configuration *can* do security harm:
VirtualHost foo.example.com:443
SSLVerifyClient optional
SSLCACertificateFile foo-clientauth-bundle.pem
/VirtualHost
VirtualHost bar.example.com:443
SSLVerifyClient optional
SSLCACertificateFile
On 04/21/2009 07:10 AM, Kaspar Brand wrote:
Ruediger Pluem wrote:
Looks good. Some minor nitpicks:
Furthermore I think that we need to check for CA list change in any case
that we need to renegotiate as even if we do not fail on SSL level due
to SSL_VERIFY_FAIL_IF_NO_PEER_CERT there
Ruediger Pluem wrote:
Looks good. Some minor nitpicks:
Reviewing the code again I don't think we need to have
+#ifndef OPENSSL_NO_TLSEXT
+ !(SSL_get_servername(ssl, TLSEXT_NAMETYPE_host_name))
+#endif
this condition at all.
Agreed. I have removed this part from the if
On 04/15/2009 10:31 AM, Kaspar Brand wrote:
Correct, again. Changed accordingly in v7 of the patch, which I'm
attaching (together with an interdiff from v6). I have tested this
version with quite many different vhosts, per-vhost and per-dir
settings, and with both SNI and non-SNI
Thanks for your time and review - much appreciated.
+n = sslconn-verify_depth;
+sslconn-verify_depth = (dc-nVerifyDepth != UNSET) ?
+dc-nVerifyDepth : sc-server-auth.verify_depth;
+if ((sslconn-verify_depth n) ||
+((n == 0)
On 04/08/2009 10:17 AM, Kaspar Brand wrote:
Plüm, Rüdiger, VF-Group wrote:
I reviewed your patch and found some issues with it.
Thanks for your review and testing, Rüdiger. I assume you used and
adapted version of the sni_sslverifyclient-v5.diff patch, is that correct?
(All cases below
Plüm, Rüdiger, VF-Group wrote:
I reviewed your patch and found some issues with it.
Thanks for your review and testing, Rüdiger. I assume you used and
adapted version of the sni_sslverifyclient-v5.diff patch, is that correct?
(All cases below use Name based virtual hosting and a non SNI
-Ursprüngliche Nachricht-
Von: Kaspar Brand
Gesendet: Montag, 30. März 2009 18:15
An: dev@httpd.apache.org
Betreff: Re: SNI in 2.2.x (Re: Time for 2.2.10?)
Ruediger Pluem wrote:
Going through the archive I noticed several attachments
with the same
basename
Gesendet: Montag, 30. März 2009 18:15
An: dev@httpd.apache.org
Betreff: Re: SNI in 2.2.x (Re: Time for 2.2.10?)
Ruediger Pluem wrote:
Going through the archive I noticed several attachments
with the same
basename and and a version string attached. Are these patches
cumulative so that I only
-Ursprüngliche Nachricht-
Von: Kaspar Brand
Gesendet: Donnerstag, 2. April 2009 18:21
An: dev@httpd.apache.org
Betreff: Re: SNI in 2.2.x (Re: Time for 2.2.10?)
Plüm, Rüdiger, VF-Group wrote:
Going through the follow ups the following question remains for me:
Where did you
-Ursprüngliche Nachricht-
Von: Kaspar Brand
Gesendet: Donnerstag, 2. April 2009 07:15
An: dev@httpd.apache.org
Betreff: Re: SNI in 2.2.x (Re: Time for 2.2.10?)
Plüm, Rüdiger, VF-Group wrote:
A question regarding your patch:
@@ -427,29 +435,26 @@ int ssl_hook_Access
Plüm, Rüdiger, VF-Group wrote:
Going through the follow ups the following question remains for me:
Where did you address to adjust the
SSLCARevocation{File,Path} and
SSLOCSP{Enable,DefaultResponder,OverrideResponder}
settings in the case of an non SNI client connecting to the non
-Ursprüngliche Nachricht-
Von: Kaspar Brand
Gesendet: Montag, 30. März 2009 18:15
An: dev@httpd.apache.org
Betreff: Re: SNI in 2.2.x (Re: Time for 2.2.10?)
Ruediger Pluem wrote:
Going through the archive I noticed several attachments
with the same
basename
Plüm, Rüdiger, VF-Group wrote:
A question regarding your patch:
@@ -427,29 +435,26 @@ int ssl_hook_Access(request_rec *r)
* function and not by OpenSSL internally (and our function is aware of
* both the per-server and per-directory contexts). So we cannot ask
* OpenSSL
Ruediger Pluem wrote:
Name based virtual hosting with SSL does *only* work with SNI *enabled*
clients. Not SNI enabled clients receive a 403 when contacting any of
the name based virtual hosts (which enables you to set a nice error
page to explain to the user what happened and which browser to
Ruediger Pluem wrote:
Going through the archive I noticed several attachments with the same
basename and and a version string attached. Are these patches
cumulative so that I only need to review the latest one?
sni_sslverifyclient-v5.diff includes all improvements to
On 08/29/2008 07:09 AM, Kaspar Brand wrote:
Making SNI support configurable at runtime also seems a more attractive
solution to me - it would basically mean that in ssl_init_ctx(), the SNI
callback is not registered unless it's explicitly configured. I would
suggest using something like
On 08/19/2008 08:16 AM, Kaspar Brand wrote:
Ruediger Pluem wrote:
At the moment we have 9 entries in the CHANGES file for 2.2.10 and
there are 5 more proposals in the STATUS file that are missing only
one vote. I think if get these done we also have enough stuff from
pure httpd point of
Just 2 cents.
I do like the toggle switch in this patch.
Now that OpenSSL defaults to SNI enabled, I like it even more!
One less thing to remember at compile, one build instead of two separate
being best of both worlds,
and the user (me) having to knowingly switch it on, not just on cause it
On Mar 28, 2009, at 1:13 PM, Ruediger Pluem wrote:
IP based virtual hosting with SSL works as before. This means with SNI
enabled clients as well as with not SNI enabled clients.
Name based virtual hosting with SSL does *only* work with SNI
*enabled*
clients. Not SNI enabled clients
Hi Devs and fellow list lurkers,
I finally took the time to give this SNI business a try.
I compiled the latest branch for the SVN with Kasper's patch on Windoze.
After a hurdle
with OpenSSL 098i that Tom Donovan was kind enough to help me jump over,
I've got
2.2.11-dev with SNI working on
On Thu, Oct 9, 2008 at 5:59 AM, Ian G [EMAIL PROTECTED] wrote:
As we all know, this will not be in 2.2.10... Please recall that
things must be in -trunk before being viable for backport to 2.2.x.
It's impossible to even express how disappointing this is ;(
There are only two changes in TLS
As we all know, this will not be in 2.2.10... Please recall that
things must be in -trunk before being viable for backport to 2.2.x.
It's impossible to even express how disappointing this is ;(
There are only two changes in TLS on the server side that have been
identified to have any effect
On Sep 23, 2008, at 5:37 AM, David Shane Holden wrote:
Kaspar Brand wrote:
Making SNI support configurable at runtime also seems a more
attractive
solution to me - it would basically mean that in ssl_init_ctx(),
the SNI
callback is not registered unless it's explicitly configured. I
On 10/08/2008 09:56 PM, Jim Jagielski wrote:
On Sep 23, 2008, at 5:37 AM, David Shane Holden wrote:
Kaspar Brand wrote:
Making SNI support configurable at runtime also seems a more attractive
solution to me - it would basically mean that in ssl_init_ctx(), the
SNI
callback is not
I managed to find some time to experiment with this patch against
2.2.9, and so far so good. It works as advertised. I'm eager to see
SNI included in Apache!
+1,000,000 votes from LAMPs people.
-1,000 votes from phishers ... they don't want TLS to get easier to
use, because more
Den Thursday 28 August 2008 19:45:10 skrev Kaspar Brand:
I wrote:
When I added the second condition to the first if statement, I was
assuming that the default for auth.verify_depth is UNSET as well.
However, it's initialized to 1 (i.e. SSL_CVERIFY_OPTIONAL)
Den Wednesday 20 August 2008 12:06:33 skrev Oden Eriksson:
[...]
FYI: This patch is applied in Mandriva Linux.
However, the perl-framework tests barfs at:
t/ssl/v2# Failed test 1 in t/ssl/v2.t at line 16
--
Regards // Oden Eriksson
Oden Eriksson wrote:
However, the perl-framework tests barfs at:
t/ssl/v2# Failed test 1 in t/ssl/v2.t at line 16
The root cause for this failure could actually be the same as for a
different issue which was reported to me by private e-mail just
yesterday - in
I wrote:
When I added the second condition to the first if statement, I was
assuming that the default for auth.verify_depth is UNSET as well.
However, it's initialized to 1 (i.e. SSL_CVERIFY_OPTIONAL)
Wrong, of course - this macro
Making SNI support configurable at runtime also seems a more attractive
solution to me - it would basically mean that in ssl_init_ctx(), the SNI
callback is not registered unless it's explicitly configured. I would
suggest using something like
SSLEnableSNI port [port] ...
which would
Ian G wrote:
Nick Kew [EMAIL PROTECTED]wrote:
...
It might be worth a --with-SNI configuration option, which
would label it as an experimental feature.
I imagine the use of SNI would need to be configured in
httpd.conf anyway, in the virtual host parts.
Making SNI support configurable
Den Wednesday 20 August 2008 13:10:52 skrev Nick Kew:
On Wed, 20 Aug 2008 12:06:33 +0200
Oden Eriksson [EMAIL PROTECTED] wrote:
FYI: This patch is applied in Mandriva Linux.
Any feedback? Bug reports coming from their users?
No reports so far. It was requested by our users though.
If
Nick Kew [EMAIL PROTECTED]wrote:
...
It might be worth a --with-SNI configuration option, which
would label it as an experimental feature.
I imagine the use of SNI would need to be configured in
httpd.conf anyway, in the virtual host parts.
Would an overall directive like:
[EMAIL PROTECTED] wrote:
May I use this occasion to ask if there's still a chance of getting a
backport of SNI accepted for 2.2.x?
For me, +1. For the LAMPs guys, +1m. For the phishing
victims, +10m.
Ok, the
Den Tuesday 19 August 2008 08:16:08 skrev Kaspar Brand:
Ruediger Pluem wrote:
At the moment we have 9 entries in the CHANGES file for 2.2.10 and
there are 5 more proposals in the STATUS file that are missing only
one vote. I think if get these done we also have enough stuff from
pure
On Wed, 20 Aug 2008 12:06:33 +0200
Oden Eriksson [EMAIL PROTECTED] wrote:
FYI: This patch is applied in Mandriva Linux.
Any feedback? Bug reports coming from their users?
If you'd said Debuntu or Deadrat+family, we might infer a user
community big enough to rely on (FSreasonableVO rely).
Not
I like the idea of using --with-SNI and labeling it as experimental.
Maybe leave it of by default though?
~ Jorge
On Wed, Aug 20, 2008 at 1:10 PM, Nick Kew [EMAIL PROTECTED] wrote:
On Wed, 20 Aug 2008 12:06:33 +0200
Oden Eriksson [EMAIL PROTECTED] wrote:
FYI: This patch is applied in
On Wed, Aug 20, 2008 at 02:08:02PM +0200, Jorge Schrauwen wrote:
I like the idea of using --with-SNI and labeling it as experimental.
Yeah, good way to move forward.
Maybe leave it of by default though?
absolutely. It would seem rather odd to turn on experimental by default.
vh
Mads Toftum
On Aug 20, 2008, at 7:10 AM, Nick Kew wrote:
It might be worth a --with-SNI configuration option, which
would label it as an experimental feature.
+1, given that it'd be off by default. Anyone care to craft some
autofoo?
S.
--
Sander Temme
[EMAIL PROTECTED]
PGP FP: 51B4 8727 466A 0BC3
Ruediger Pluem wrote:
At the moment we have 9 entries in the CHANGES file for 2.2.10 and
there are 5 more proposals in the STATUS file that are missing only
one vote. I think if get these done we also have enough stuff from
pure httpd point of view that warrants a release. WDYT?
May I use
Kaspar Brand wrote:
Ruediger Pluem wrote:
At the moment we have 9 entries in the CHANGES file for 2.2.10 and
there are 5 more proposals in the STATUS file that are missing only
one vote. I think if get these done we also have enough stuff from
pure httpd point of view that warrants a release.
51 matches
Mail list logo
