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 explicitl
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_looku
iche 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 fo
> -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
> >>
>> 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 we
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 particu
> -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
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 SN
> -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:
>
Ruediger Pluem wrote:
> the next configuration *can* do security harm:
>
>
>SSLVerifyClient optional
>SSLCACertificateFile foo-clientauth-bundle.pem
>
>
>
>SSLVerifyClient optional
>SSLCACertificateFile bar-clientauth-bundle.pem
>
>
> This would cause client certificates sign
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 t
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 i
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 clie
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) && (sc-
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 case
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 clien
par 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
>> > basen
> -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
>
> -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 follow
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: 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:
> &g
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
> * OpenS
> -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
>
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
ssl_hook_Access/ssl_call
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 us
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 receive
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
ha
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 li
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 poin
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 Win
On Oct 9, 2008, at 5:59 AM, Ian G 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 on the server side t
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 cha
> 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 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
c
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
would
>> 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 certi
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
SSLEnableSNI port [port] ...
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)
>
>
> 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
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 macr
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 ssl_engine
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
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
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:
PermitVh
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.
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 6
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 Toft
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
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).
N
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
> > p
[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 numb
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. WD
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
53 matches
Mail list logo