> Am 10.08.2017 um 16:09 schrieb William A Rowe Jr <wr...@rowe-clan.net>:
> Let's break it down and consider the implications of Listen...
> On Thu, Aug 10, 2017 at 8:28 AM, Stefan Eissing
> <stefan.eiss...@greenbytes.de> wrote:
>> Now that mod_md has landed in trunk, I am looking at more ways
>> to simplify a SSL configuration. Looking at the Listen directive,
>> it has an optional 2nd protocol parameter.
>> Would it be unreasonable to assume that a
>>    Listen NNN https
>> means that "SSLEngine on" should be the default in all
>>    <VirtualHost *:NNN>
>>       ServerName xxx.yyy
>>       ...
>>    </VirtualHost>
>> sections?
> Firstly, we have well understood protocols definitions, so there
> are several shorthand flavors that could be introduced;
>  Listen https
> has a very plain and obvious meaning. Thus, so would these;
>  Listen
>  Listen https://xxx.yyy
>  Listen
>  Listen https://xxx.yyy:8443

I like this.

>> Would we expect breakage by such a change?
> I think that Listen *:NNN is maybe the most common misconfiguration
> in general, on multihomed boxes (and Listen myhost:NNN not answering
> the call of localhost being a most common point of confusion :)
> Your mention of ServerName is a little misleading. A corresponding
> virtual host isn't needed at all. And mod_ssl handshake is always
> controlled by the physical vhost (first matching named vhost, name
> being ignored), which makes this a little more confusing to users.

If understand you correctly, if the first matching (document order?)
vhost for the address:port (with wildcards) has "SSLEngine on", we
get mod_ssl engaged. If not, we try to parse a http: request?

Hmmm. That...could be improved.

> What leads me to wonder, even with some easier-to-read Listen
> directives, if the user wouldn't be confused by omission of the
> SSLEngine on, when their other SSL directives aren't behaving
> as expected. Because they placed them in the wrong <vhost >,
> obviously. But not obvious to them. The need to toggle SSLEngine
> may be an unintended usability feature.

I think my gut feeling tells me that "SSLEngine on|off" is more
part of the port and of the vhost. The vhost may add other SSL*
configurations, once SNI has identified the correct one. But for
a certain port (address:port) we either do TLS or not.

So, I was looking for ways to express that and Listen seems a good start.

>> What about name-based virtual hosts that apply to _all_
>> addresses and ports? E.g. something like:
>>    <VirtualHost>
>>       ServerName xxx.yyy
>>       ...
>>       <If "%{HTTPS} != 'on'">
>>          Redirect permanent "/" "https://xxx.yyy/";
>>       </If>
>>       ...
>>    </VirtualHost>
>> Do you find that ugly/feasible/desirable?
> Definitely not a fan. Why isn't this rewrite simply given in the system
> global config?
> A connection, later the request, maps to only VirtualHost declaration.
> That block would never fire if there is a matching VirtualHost. OTOH,
> if no VirtualHost matches, then we use the global host anyways.

I now tend to agree that it probably only adds to confusion rather than simpify 


Reply via email to