> Am 10.08.2017 um 16:09 schrieb William A Rowe Jr <[email protected]>:
>
> Let's break it down and consider the implications of Listen...
>
> On Thu, Aug 10, 2017 at 8:28 AM, Stefan Eissing
> <[email protected]> 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 https://192.168.1.1
> Listen https://xxx.yyy
> Listen https://192.168.1.1:8443
> 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
things.
-Stefan
