Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
MIME-Version: 1.0
In-Reply-To: <A3713651-58B7-4C4F-8236-3EDE7D8E59CD@greenbytes.de>
References: <678BA83E-09F8-4216-9F8A-675176BEDCCB@greenbytes.de>
 <CACsi253MnMrmh5vxLnxbT7uhn_nWtEhhJnRVC7riXwCyGSQ3PA@mail.gmail.com> <A3713651-58B7-4C4F-8236-3EDE7D8E59CD@greenbytes.de>
From: William A Rowe Jr <wrowe@rowe-clan.net>
Date: Thu, 10 Aug 2017 09:55:01 -0500
Message-ID: <CACsi250D-eco49E2PrOncvxkuWqSczDJOWR2bUuR9okL6acCow@mail.gmail.com>
Subject: Re: Listen 443 https
To: httpd <dev@httpd.apache.org>
Content-Type: text/plain; charset="UTF-8"
archived-at: Thu, 10 Aug 2017 14:55:09 -0000

On Thu, Aug 10, 2017 at 9:19 AM, Stefan Eissing
<stefan.eissing@greenbytes.de> wrote:
>
>> Am 10.08.2017 um 16:09 schrieb William A Rowe Jr <wrowe@rowe-clan.net>:
>>
>>> 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.

When the NamedVirtualHost still existed and was still documented,
this was all more obvious to the end-user

This is where it is all explained poorly as features such as '*' were
further modified, so the document is pretty muddy and partly wrong;

http://httpd.apache.org/docs/2.4/vhosts/name-based.html

The author here clearly misunderstood the role of virtual hosts for
directives which affect the initial establishment of the connection
in the read request behavior, prior to re-electing a more specific
name-based vhost match. This sentence in particular could be
corrected; "In first establishing the connection and reading the
request off the wire, and subsequently, If no matching ServerName
or ServerAlias is found in the set of virtual hosts containing the
most specific matching IP address and port combination, then
the first listed virtual host that matches that will be used."

That's more correct but still clumsy, better wordsmithing would
be appreciated. It's answered much better in
http://httpd.apache.org/docs/2.4/mod/core.html#virtualhost

"When a request is received, the server first maps it to the best
matching <VirtualHost> based on the local IP address and port
combination only. Non-wildcards have a higher precedence. If no match
based on IP and port occurs at all, the "main" server configuration is
used."

"If multiple virtual hosts contain the best matching IP address and
port, the server selects from these virtual hosts the best match based
on the requested hostname. If no matching name-based virtual host is
found, then the first listed virtual host that matched the IP address
will be used. As a consequence, the first listed virtual host for a
given IP address and port combination is the default virtual host for
that IP and port combination."

But even here we could be more specific in the second para;
"Once the request is received"...

Back to the behavior of mod_ssl, the SSLProtocol directive is
obviously dictated by the physical vhost. But SSLHonorCipherOrder
and other post-SNI decisions? I'm unsure whether the handshake
is "completed" with the SNI name-based election or physical vhost.


>> 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.

The protocol tag existed for only one reason, to imply a corresponding
AcceptFilter (e.g. data or no data or http ready on the wire before the
accept would recognize the connection.)

Each time we overload this meaning we are introducing an alternate
or alias to other httpd configuration, which might become confusing
to many users. I just suggest we tread carefully and this time, think
the potential confusion and side effects through.

The other issue IMO is multiple protocols on the given listener.
Already true of http / h2c / h2. A recent proposal suggested to add
PROXY protocol to that list, and the list of potential combinations
goes on.