httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <stefan.eiss...@greenbytes.de>
Subject Re: Listen 443 https
Date Mon, 18 Sep 2017 17:53:03 GMT
Thanks for you feedback, Daniel. Very much appreciated! You describe
the approach I suggest as "confusing" and "complicated", while for me
it is the opposite. ;-)

But there are really two separate things here. The SSLEngine addition
and the multi-port vhost. I'll argue that the first make sense, even if
you do not want to use the second one.

SSLEngine addr-list
-------------------------
The case I would like to make for "SSLEngine addr-list" is that it allows an
admin to define use of TLS on a port (for all or a specific address) in
one line. It is my understanding that all VirtualHosts on the same port
either need to do TLS or none should.

If a server has 100 vhosts on *:443, the admin needs to "SSLEngine on"
in each and every one of them. The task to do that is certainly manageable
for an admin, but why does it have to be that way? Why give the admin
the option to screw up and forget the 99th and see the error only when
someone accesses that host? With an implicit port match on SSLEngine,
  a VirtualHost without certifcates fails the config immediately.

So, I'd argue that for a very common case, "SSLEngine *:443" makes
the configuration easier and offers better fail-safes.

This all holds true if one "folds" virtualhosts on a address/port list
or keeps separate ones for each address, as you think is superior.


VirtualHost addr-list
--------------------------
This is a feature that is already there. The new "SSLEngine addr" makes
it usable for http: and https: access. That is new. I think for someone
migrating a site to https:, it is a good approach, but YMMV.

In https://github.com/icing/mod_md/wiki/Migration I describe how
one ca go from a *:80 vhost, add Let's Encrypt certs, serve 80
and 443 both until everything is working as planned and then switch over
with permanent redirects and HSTS to the https: presence.

I recommend to duplicate VirtualHost initially, so that the *:80 can
be left unchanged during migration. But propose - with the help of
the trunk changes, if we decide to backport them - to end up with
a configuration *very* similar to the start one. To be exact, the
config has 5 lines added and 1 edited to add *:443. Migrating a 2nd
vhost on that server would add only 1 new line and 1 edit.

So, from *that* perspective I hope the admin of such a site sees it
as not confusing and not complicate to migrate to https:.

We need to keep in mind that browser will distrust http: *very* soon
and that admins will look for an easy way to offer https:. I hope that
the proposed way is attractive and will help. But it certainly is not
the only way. And there are certainly configurations where it is not
even a good way.

Cheers,

Stefan

Am 18.09.2017 um 17:56 schrieb Daniel:
> I tried to read and understand the whole thread and what we are trying
> to solve here, but I can't help to think this is an attempt at a new
> ".htaccess" wildcard thing for SSL that will end in greater confusion.
>
> in Freenode #httpd we generally try to teach people to not be afraid
> of defining the necessary virtualhosts. Everyone seems inclined, due
> to the amount of trash they have found through google, to define a
> single .htaccess files that will solve all their cases, redirections,
> and whatnot, and 90% are frustrated on how complicated it is.
>
> The generic solution we give is, (the iconic simplest way), one
> virtualhost for each:
>
> <Virtualhost *:80>
> ServerName whatever.example.com
> Redirect / https://whatever.example.com/
> </Virtualhost>
>
> <Virtualhost *:443>
> ServerName whatever.example.com
> SSLEngine on
> etc..
> </Virtualhost>
>
> Isn't this much better than any other attempt at reducing it to
> "another minimum expression" in a complicated kind of way?
>
> Is it really neccessary to have <Virtualhost *:80 *:443..> and try to
> do the same thing as above in a new more confusing complicated way?
>
> Of course users may not be admins, but still they can have virtualhost
> for both ports (SSL and not SSL) and use .htaccess and all the
> RewriteCond %{HTTPS} !on  etc..
>
> But the way I see it.. Are we really going to complicate virtualhosts
> too? Do we really need to offer added functionality to do the same
> thing that is already being offered now in the simple starting example
> I provided of two single virtualhosts, one for each? Obviously one can
> complicate it already as needed using If, or RewriteCond, etc.. but
> shouldn't we strive to make virtualhosts as simple to understand as
> possible?
>
>
> To me a single virtualhost which handles both SSL and non-SSL
> connection seems like doing the opposite, adding a new way for user
> confusion.
>
> Perhaps we need to stop for a minute if we wand to add more
> complicated ways to do the same thing we can already do (and probably
> many should do) in a very simple way?
>
> Regarding the SSL changes, SSLPolicy and such are great additions and
> they belong in server config, we should stop there for the moment and
> leave Virtualhost as simple as possible.
>
> Hope I don't sound impolite or anything like that, the ideas thrown
> and your work (@Stefan) is amazing!
>
> 2017-08-10 15:28 GMT+02:00 Stefan Eissing <stefan.eissing@greenbytes.de>:
>> 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? Would we expect breakage by such a change?
>>
>> 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?
>>
>> -Stefan
>
>


Mime
View raw message