directive to reject non-configured hostnames w/o needing catch-all virtual hosts?

[Eric Covener]

At $dayjob I am seeing a lot of users running scans that flag any HTTP
response that incorporates the Host header into the response as
"vulnerable", even if the host is syntactically valid.

AIUI the standard solution is to create a default NVH for each
host:port combo to trap unknowns and use it to return an error.  But
this is a lot of work.  Rewrite has its own baggage (add it global,
add it to each VH, add it before other rewrites)

(things like proxy and CGI/PHP mean UseCanonicalName is insufficient)

Nothing currently crawls all ServerName/ServerAlias, becuase we always
select the best IP-based match firs then compare strings from the
result.

Is anyone else interested in another way to configure this? Would you
want to crawl all servername/serveralias when enabled or pass in a
separate whitelist to a new directive?  With the latter, you could at
least make sure the e.g. *.example.com showed up without checking the
gory details.


-- 
Eric Covener
cove...@gmail.com

Re: mod_ssl and SSLPolicy

[Yann Ylavic]

On Wed, Nov 29, 2017 at 12:17 PM, Gillis J. de Nijs  wrote:
> Could it be as simple as changing  to  and
> leaving SSLPolicy as it is?

This would work for me, I'll be quite consensual anyway (e.g. I'm fine
with SSLPolicy for both too).

 / ManagedDomain could also work (re other thread).


Regards,
Yann.

Re: mod_ssl and SSLPolicy

[Gillis J. de Nijs]

Could it be as simple as changing  to  and
leaving SSLPolicy as it is?

Cheers,
Gillis

On Wed, Nov 29, 2017 at 10:23 AM, Stefan Eissing <
stefan.eiss...@greenbytes.de> wrote:

> Having slept a night over this and the mod_md config change request, I say
> this leaves me somewhat sour. A request for an unspecified change by
> someone important in this project is basically blocking any progress for
> me.
>
> I am sure that was not your intention, but I feel the current choice of
> naming good, because that is why they are there, and I am not convinced
> that any alternative I come up with falls on fertile ground. That could
> lead to a groundhog day experience with me doing the work and others
> saying 'nah!' afterwards.
>
> This change is obviously important to you, so please lead a consensus on
> how it should be changed. The code change I will then do afterwards if
> no one else feels like it.
>
> Cheers,
>
> Stefan
>
> > Am 28.11.2017 um 16:51 schrieb Rich Bowen :
> >
> > As one of the folks that answers questions on IRC, I would like to
> object to the existence of SSLPolicy and . I think it's unwise
> to have two directives with the same name, for reasons of end-user support.
> >
> > As long as it's still only in trunk, we still have an opportunity to
> avert user confusion.
> >
> > I request that one of these be renamed. (No, I'm not suggesting specific
> names. I suck at naming things.)
> >
> > Thanks.
> >
> > --Rich
>
>

Re: mod_ssl and SSLPolicy

[Stefan Eissing]

Having slept a night over this and the mod_md config change request, I say
this leaves me somewhat sour. A request for an unspecified change by 
someone important in this project is basically blocking any progress for me.

I am sure that was not your intention, but I feel the current choice of
naming good, because that is why they are there, and I am not convinced 
that any alternative I come up with falls on fertile ground. That could
lead to a groundhog day experience with me doing the work and others
saying 'nah!' afterwards.

This change is obviously important to you, so please lead a consensus on
how it should be changed. The code change I will then do afterwards if
no one else feels like it.

Cheers,

Stefan 

> Am 28.11.2017 um 16:51 schrieb Rich Bowen :
> 
> As one of the folks that answers questions on IRC, I would like to object to 
> the existence of SSLPolicy and . I think it's unwise to have two 
> directives with the same name, for reasons of end-user support.
> 
> As long as it's still only in trunk, we still have an opportunity to avert 
> user confusion.
> 
> I request that one of these be renamed. (No, I'm not suggesting specific 
> names. I suck at naming things.)
> 
> Thanks.
> 
> --Rich