Listen 443 https

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Listen 443 https

Stefan Eissing
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
Reply | Threaded
Open this post in threaded view
|

Re: Listen 443 https

William A Rowe Jr
Let's break it down and consider the implications of Listen...

On Thu, Aug 10, 2017 at 8:28 AM, Stefan Eissing
<[hidden email]> 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

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

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.


> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Listen 443 https

Stefan Eissing

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

Reply | Threaded
Open this post in threaded view
|

Re: Listen 443 https

Reindl Harald-2
In reply to this post by Stefan Eissing


Am 10.08.2017 um 15:28 schrieb Stefan Eissing:

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

it makes it unflexible, something like port-specific options would solve
the current problem that you need to define aecgh and every vhost with
all it's options twice and that part is my biggest headache by implement
letsencrypt (without mod_md) for hundrets of existing websites

it also would solve the chicken-egg-problem (again, without mod_md) that
you first need the http-host working for the well-known verfication file
and the path of the certificate could be easily pre-configured in the
way of my example, just warn insteda a fatal error on reload when the
certfile don't exist
____________________________________

<VirtualHost *>
  ServerName corecms.example.com
  DocumentRoot "/www/corecms.example.com"
  <If "%{PORT} == '443'">
   SSLEngine On
   SSLUseStapling Off
   SSLCertificateFile "conf/ssl/corecms.pem"
  </If>
  <Directory "/www/corecms.example.com">
   php_admin_value open_basedir "/www/corecms.example.com"
   php_admin_value upload_tmp_dir "/www/corecms.example.com/uploadtemp"
  </Directory>
</VirtualHost>
____________________________________

<VirtualHost *>
  ServerName corecms.example.com
  DocumentRoot "/www/corecms.example.com"
  <Directory "/www/corecms.example.com">
   php_admin_value open_basedir "/www/corecms.example.com"
   php_admin_value upload_tmp_dir "/www/corecms.example.com/uploadtemp"
  </Directory>
</VirtualHost>

<VirtualHost *:443>
  ServerName corecms.example.com
  DocumentRoot "/www/corecms.example.com"
  SSLEngine On
  SSLUseStapling Off
  SSLCertificateFile "conf/ssl/corecms.pem"
  <Directory "/www/corecms.example.com">
   php_admin_value open_basedir "/www/corecms.example.com"
   php_admin_value upload_tmp_dir "/www/corecms.example.com/uploadtemp"
  </Directory>
</VirtualHost>
Reply | Threaded
Open this post in threaded view
|

Re: Listen 443 https

William A Rowe Jr
In reply to this post by Stefan Eissing
On Thu, Aug 10, 2017 at 9:19 AM, Stefan Eissing
<[hidden email]> wrote:

>
>> Am 10.08.2017 um 16:09 schrieb William A Rowe Jr <[hidden email]>:
>>
>>> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Listen 443 https

William A Rowe Jr
In reply to this post by Reindl Harald-2
On Thu, Aug 10, 2017 at 9:21 AM, Reindl Harald <[hidden email]> wrote:

>
> it also would solve the chicken-egg-problem (again, without mod_md) that you
> first need the http-host working for the well-known verfication file and the
> path of the certificate could be easily pre-configured in the way of my
> example, just warn insteda a fatal error on reload when the certfile don't
> exist
> ____________________________________
>
> <VirtualHost *>
>  ServerName corecms.example.com
>  DocumentRoot "/www/corecms.example.com"
>  <If "%{PORT} == '443'">
>   SSLEngine On
>   SSLUseStapling Off
>   SSLCertificateFile "conf/ssl/corecms.pem"
>  </If>
>  <Directory "/www/corecms.example.com">
>   php_admin_value open_basedir "/www/corecms.example.com"
>   php_admin_value upload_tmp_dir "/www/corecms.example.com/uploadtemp"
>  </Directory>
> </VirtualHost>

This doesn't work, of course, owing to server_rec members such as scheme
and port. If these moved to the addrs member, and we tracked the current
vhost by server_rec and individual addrs array member in 2.next, then we
may be able to resolve this (but that is not an insignificant patch.)

Note your misuse of 443 as the sentinel, it prevents your certificate file
and your stapling choice from affecting h2 requests on port 80.
Reply | Threaded
Open this post in threaded view
|

Re: Listen 443 https

William A Rowe Jr

On Thu, Aug 10, 2017 at 9:21 AM, Reindl Harald <[hidden email]> wrote:
>
> <VirtualHost *>
>  ServerName corecms.example.com
>  DocumentRoot "/www/corecms.example.com"
>  <If "%{PORT} == '443'">

This doesn't work, of course, owing to server_rec members such as scheme
and port. If these moved to the addrs member, and we tracked the current
vhost by server_rec and individual addrs array member in 2.next, then we
may be able to resolve this (but that is not an insignificant patch.)

Note your misuse of 443 as the sentinel, it prevents your certificate file
and your stapling choice from affecting h2 requests on port 80.

Another reason this will not work... Server/VHost config is static. All such directives are evaluated at config/startup time, global config is merged to per-vhost config. And that is the state of the host for that generation of the workers process. <If > will never be supported for those directives, it can work only on per-dir config options.

Final reason this won't be adopted as suggested; VirtualHost [:80] is implicit. I cannot see us ever changing this, it would break most configs. Maybe a port * feature?

If you want to experiment...
<VirtualHost IP:80 IP:443>
is already recognized.


Reply | Threaded
Open this post in threaded view
|

Re: Listen 443 https

Reindl Harald-2


Am 10.08.2017 um 17:57 schrieb William A Rowe Jr:

>
>     On Thu, Aug 10, 2017 at 9:21 AM, Reindl Harald
>     <[hidden email] <mailto:[hidden email]>> wrote:
>      >
>      > <VirtualHost *>
>      >  ServerName corecms.example.com <http://corecms.example.com>
>      >  DocumentRoot "/www/corecms.example.com <http://corecms.example.com>"
>      >  <If "%{PORT} == '443'">
>
>     This doesn't work, of course, owing to server_rec members such as scheme
>     and port. If these moved to the addrs member, and we tracked the current
>     vhost by server_rec and individual addrs array member in 2.next, then we
>     may be able to resolve this (but that is not an insignificant patch.)
>
>     Note your misuse of 443 as the sentinel, it prevents your
>     certificate file
>     and your stapling choice from affecting h2 requests on port 80.
>
> Another reason this will not work... Server/VHost config is static. All
> such directives are evaluated at config/startup time, global config is
> merged to per-vhost config. And that is the state of the host for that
> generation of the workers process. <If > will never be supported for
> those directives, it can work only on per-dir config options.
>
> Final reason this won't be adopted as suggested; VirtualHost [:80] is
> implicit. I cannot see us ever changing this, it would break most
> configs. Maybe a port * feature?
>
> If you want to experiment...
> <VirtualHost IP:80 IP:443>
> is already recognized

but with "SSLEngine On" and "SSLCertificateFile" configured non-https no
longer would work, since H2 no longer supports mod_prefork i don't care
about that part

for high traffic sites apache trafficserver is in front which scales
much better and enbales H2 automatically but i want every backend vhost
keep working as now independent and only DNS decides if it goes to the
proxy - proxy which makes no sense for very small pages with no traffic
all the time and only introdcues latency and wastes memory caches
Reply | Threaded
Open this post in threaded view
|

Re: Listen 443 https

Stefan Eissing
In reply to this post by Stefan Eissing
I get the first feedback from Apache users that want their http: only hosts to also serve https:. This is nice feedback to improve usability of mod_md.

Ideally, what these people want - and that is purely my interpretation - is to add a few lines to their config and  - voila - https: is available. And, honestly, why should they not expect that?



Example: Duplication/Redirect

They have something like:
----------------------------------
Listen 80
<VirtualHost *:80>
  ServerName xxx.yyy
  ...
</VirtualHost>
----------------------------------

and want to also make that available on https:
----------------------------------
Listen http://*:80
Listen https://*:443

<VirtualHost *:80>
  ServerName xxx.yyy
  AlternatePorts 443
  ...
</VirtualHost>
----------------------------------

or redirect everyone to https:
----------------------------------
Listen http://*:80
Listen https://*:443

<VirtualHost *:443>
  ServerName xxx.yyy
  RedirectPermanentFrom 80
  ...
</VirtualHost>
----------------------------------

I am not hooked on the names, but I hope you understand the intent? Anyone with me on this?

Cheers,

Stefan


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



Coming back to this. If we - optionally - would support this in the 'Listen' directive
Reply | Threaded
Open this post in threaded view
|

Re: Listen 443 https

Eric Covener
On Fri, Sep 1, 2017 at 10:39 AM, Stefan Eissing
<[hidden email]> wrote:

> I get the first feedback from Apache users that want their http: only hosts to also serve https:. This is nice feedback to improve usability of mod_md.
>
> Ideally, what these people want - and that is purely my interpretation - is to add a few lines to their config and  - voila - https: is available. And, honestly, why should they not expect that?
>
>
>
> Example: Duplication/Redirect
>
> They have something like:
> ----------------------------------
> Listen 80
> <VirtualHost *:80>
>   ServerName xxx.yyy
>   ...
> </VirtualHost>
> ----------------------------------
>
> and want to also make that available on https:
> ----------------------------------
> Listen http://*:80
> Listen https://*:443
>
> <VirtualHost *:80>
>   ServerName xxx.yyy
>   AlternatePorts 443
>   ...
> </VirtualHost>
> ----------------------------------
>
> or redirect everyone to https:
> ----------------------------------
> Listen http://*:80
> Listen https://*:443
>
> <VirtualHost *:443>
>   ServerName xxx.yyy
>   RedirectPermanentFrom 80
>   ...
> </VirtualHost>

I am not keen on the syntax because we already permit multiple
addresses in the VirtualHost tag.

How about e.g.

<virtualhost *:80 *:443>
  # no protocol
  ServerName example.com
  # repurpose "optional" or pick something new
  SSLEgine optional
  # Extend SSLRequireSSL.  no-arg is deny. Default w/ "redirect" is
80, 443. For redirects, may need to not match TCP listening port
  SSLRequireSSL ["redirect" [ from-port to-port ]]
</virtualhost>
Reply | Threaded
Open this post in threaded view
|

Re: Listen 443 https

Stefan Eissing

> Am 01.09.2017 um 17:12 schrieb Eric Covener <[hidden email]>:
>
> On Fri, Sep 1, 2017 at 10:39 AM, Stefan Eissing
> <[hidden email]> wrote:
>> I get the first feedback from Apache users that want their http: only hosts to also serve https:. This is nice feedback to improve usability of mod_md.
>>
>> Ideally, what these people want - and that is purely my interpretation - is to add a few lines to their config and  - voila - https: is available. And, honestly, why should they not expect that?
>>
>>
>>
>> Example: Duplication/Redirect
>>
>> They have something like:
>> ----------------------------------
>> Listen 80
>> <VirtualHost *:80>
>>  ServerName xxx.yyy
>>  ...
>> </VirtualHost>
>> ----------------------------------
>>
>> and want to also make that available on https:
>> ----------------------------------
>> Listen http://*:80
>> Listen https://*:443
>>
>> <VirtualHost *:80>
>>  ServerName xxx.yyy
>>  AlternatePorts 443
>>  ...
>> </VirtualHost>
>> ----------------------------------
>>
>> or redirect everyone to https:
>> ----------------------------------
>> Listen http://*:80
>> Listen https://*:443
>>
>> <VirtualHost *:443>
>>  ServerName xxx.yyy
>>  RedirectPermanentFrom 80
>>  ...
>> </VirtualHost>
>
> I am not keen on the syntax because we already permit multiple
> addresses in the VirtualHost tag.
>
> How about e.g.
>
> <virtualhost *:80 *:443>
>  # no protocol
>  ServerName example.com
>  # repurpose "optional" or pick something new
>  SSLEgine optional
>  # Extend SSLRequireSSL.  no-arg is deny. Default w/ "redirect" is
> 80, 443. For redirects, may need to not match TCP listening port
>  SSLRequireSSL ["redirect" [ from-port to-port ]]
> </virtualhost>

I like the SSLRequireSSL gist. I was thinking about this over the weekend and like the following a lot:

  SSLEngine *:443 10.0.0.1:8001
  SSLRequireSSL ["temporary"|"permanent" [ from-port to-port ]]

with "permanent" as default and port 443, or the first port in SSLEngine - if given - as default.

This can be specified in a <VirtualHost> or, better even, in the base server. I think this can, together with multiple ports at <VirtualHost>, simplify configurations of TLS hosts. At least for people who want to offer the same resources on 80 and 443, or want to migrate existing *:80 hosts to TLS.

What do you think?

-Stefan



Reply | Threaded
Open this post in threaded view
|

Re: Listen 443 https

William A Rowe Jr
In reply to this post by Eric Covener
Reminder, this will not work with the current server_rec, we have a 1:1 correspondence to the server port. We would need to stop looking at that field and track the port entirely on the connection and the server rec addresses array.

On Fri, Sep 1, 2017 at 10:12 AM, Eric Covener <[hidden email]> wrote:

> On Fri, Sep 1, 2017 at 10:39 AM, Stefan Eissing
> <[hidden email]> wrote:
>> I get the first feedback from Apache users that want their http: only hosts to also serve https:. This is nice feedback to improve usability of mod_md.
>>
>> Ideally, what these people want - and that is purely my interpretation - is to add a few lines to their config and - voila - https: is available. And, honestly, why should they not expect that?
>>
>>
>>
>> Example: Duplication/Redirect
>>
>> They have something like:
>> ----------------------------------
>> Listen 80
>> <VirtualHost *:80>
>> ServerName xxx.yyy
>> ...
>> </VirtualHost>
>> ----------------------------------
>>
>> and want to also make that available on https:
>> ----------------------------------
>> Listen http://*:80
>> Listen https://*:443
>>
>> <VirtualHost *:80>
>> ServerName xxx.yyy
>> AlternatePorts 443
>> ...
>> </VirtualHost>
>> ----------------------------------
>>
>> or redirect everyone to https:
>> ----------------------------------
>> Listen http://*:80
>> Listen https://*:443
>>
>> <VirtualHost *:443>
>> ServerName xxx.yyy
>> RedirectPermanentFrom 80
>> ...
>> </VirtualHost>
>
> I am not keen on the syntax because we already permit multiple
> addresses in the VirtualHost tag.
>
> How about e.g.
>
> <virtualhost *:80 *:443>

Again, fo
Reply | Threaded
Open this post in threaded view
|

Re: Listen 443 https

Stefan Eissing

> Am 08.09.2017 um 04:37 schrieb William A Rowe Jr <[hidden email]>:
>
> Reminder, this will not work with the current server_rec, we have a 1:1 correspondence to the server port. We would need to stop looking at that field and track the port entirely on the connection and the server rec addresses array.

Urgs.

1. Irregardless of multiple addresses in a VirtualHost, I still like the idea of

    SSLEngine *:443 local_interface:8001

that is best used in the base server, once.
a) I think it is easy to understand what it does.
b) It prevents missing 'SSLEngine on' in a VirtualHost that needs it
c) It causes required fails when a VirtualHost on a SSL port has no certificates

With that, we could advise people who want to start using SSL to include the following in their main conf:

  Listen 443
  # The following fails if your OpenSSL is not new enough.
  SSLPolicy modern
  SSLEngine *:443


2. For people *moving* from http: to https: for a VirtualHost, we'd advise

  <VirtualHost *:80>
    ServerName yourhostname
    Redirect 301 "/" "https://yourhostname/"
  </VirtualHost>

  <VirtualHost *:443>
    ServerName yourhostname
     ...the former http: config
  </VirtualHost>

?

3. For people wanting to offer both http: and https: for the same resources (maybe for a trial period), what would we tell them?
a) Copy to a new VirtualHost
b) Make separate file and Include in two VirtualHost?
c) Macros???

Cheers,

Stefan

-------------------------------------------------------------------
Quick scan where we use server_rec->port:

core:
AP_DECLARE(apr_port_t) ap_get_server_port(const request_rec *r)
{
                ...
                port = r->parsed_uri.port_str ? r->parsed_uri.port :
                       r->server->port ? r->server->port :
                       ap_default_port(r);

mod_log_config.c:
static const char *log_server_port(request_rec *r, char *a)
{
    apr_port_t port;

    if (*a == '\0' || !strcasecmp(a, "canonical")) {
        port = r->server->port ? r->server->port : ap_default_port(r);
    }


ssl_engine_init.c:
        if ((sc->enabled == SSL_ENABLED_TRUE) && (s->port == DEFAULT_HTTP_PORT)) {

ssl_util.c:
char *ssl_util_vhostid(apr_pool_t *p, server_rec *s)
{
    char *id;
    SSLSrvConfigRec *sc;
    char *host;
    apr_port_t port;

    host = s->server_hostname;
    if (s->port != 0)
        port = s->port;
    else {

vhost.c:
    /* the Port has to match now, because the rest don't have ports associated
     * with them. */
    if (port != s->port) {
        return 0;
    }


> On Fri, Sep 1, 2017 at 10:12 AM, Eric Covener <[hidden email]> wrote:
> > On Fri, Sep 1, 2017 at 10:39 AM, Stefan Eissing
> > <[hidden email]> wrote:
> >> I get the first feedback from Apache users that want their http: only hosts to also serve https:. This is nice feedback to improve usability of mod_md.
> >>
> >> Ideally, what these people want - and that is purely my interpretation - is to add a few lines to their config and - voila - https: is available. And, honestly, why should they not expect that?
> >>
> >>
> >>
> >> Example: Duplication/Redirect
> >>
> >> They have something like:
> >> ----------------------------------
> >> Listen 80
> >> <VirtualHost *:80>
> >> ServerName xxx.yyy
> >> ...
> >> </VirtualHost>
> >> ----------------------------------
> >>
> >> and want to also make that available on https:
> >> ----------------------------------
> >> Listen http://*:80
> >> Listen https://*:443
> >>
> >> <VirtualHost *:80>
> >> ServerName xxx.yyy
> >> AlternatePorts 443
> >> ...
> >> </VirtualHost>
> >> ----------------------------------
> >>
> >> or redirect everyone to https:
> >> ----------------------------------
> >> Listen http://*:80
> >> Listen https://*:443
> >>
> >> <VirtualHost *:443>
> >> ServerName xxx.yyy
> >> RedirectPermanentFrom 80
> >> ...
> >> </VirtualHost>
> >
> > I am not keen on the syntax because we already permit multiple
> > addresses in the VirtualHost tag.
> >
> > How about e.g.
> >
> > <virtualhost *:80 *:443>
>
> Again, fo

Reply | Threaded
Open this post in threaded view
|

Re: Listen 443 https

Reindl Harald-2
In reply to this post by Reindl Harald-2


Am 10.08.2017 um 18:22 schrieb Reindl Harald:
>> If you want to experiment...
>> <VirtualHost IP:80 IP:443>
>> is already recognized
>
> but with "SSLEngine On" and "SSLCertificateFile" configured non-https no
> longer would work

OK, figured it out

* you need the *first* vhost with "SSLEngine On"
* others can have "SSLEngine optional" and listen to 80 and 443

but there is a bug: https://bz.apache.org/bugzilla/show_bug.cgi?id=61519

if the trailing slash is missing in the url the automatic redirect to
the full qualified folder-path points to http:// instead https:// and
that does not happen within a vhost dedicated to :443 and "SSLEngine On"

i was trapped in a endless loop because the php script making a redirect
to https:// had a bug and missed the traling / too

<VirtualHost *:80 *:443>
  DocumentRoot "/www/contentlounge"
  ServerName contentlounge.rhsoft.net
  SSLEngine optional
  SSLCertificateFile "conf/ssl/rhsoft.net.pem"
</VirtualHost>

[harry@srv-rhsoft:~]$ curl --head --insecure https://contentlounge/cms
HTTP/1.1 301 Moved Permanently
Date: Thu, 14 Sep 2017 09:40:27 GMT
X-DNS-Prefetch-Control: off
X-Content-Type-Options: nosniff
X-Response-Time: D=1311 us
Location: http://contentlounge/cms/
Cache-Control: max-age=0
Expires: Thu, 14 Sep 2017 09:40:27 GMT
Content-Type: text/html; charset=iso-8859-1
Reply | Threaded
Open this post in threaded view
|

Re: Listen 443 https

Eric Covener
In reply to this post by Stefan Eissing
On Fri, Sep 8, 2017 at 5:03 AM, Stefan Eissing
<[hidden email]> wrote:

>
>> Am 08.09.2017 um 04:37 schrieb William A Rowe Jr <[hidden email]>:
>>
>> Reminder, this will not work with the current server_rec, we have a 1:1 correspondence to the server port. We would need to stop looking at that field and track the port entirely on the connection and the server rec addresses array.
>
> Urgs.
>
> 1. Irregardless of multiple addresses in a VirtualHost, I still like the idea of
>
>     SSLEngine *:443 local_interface:8001
>
> that is best used in the base server, once.
> a) I think it is easy to understand what it does.
> b) It prevents missing 'SSLEngine on' in a VirtualHost that needs it
> c) It causes required fails when a VirtualHost on a SSL port has no certificates

What do the parameters mean here?

>
> With that, we could advise people who want to start using SSL to include the following in their main conf:
>
>   Listen 443
>   # The following fails if your OpenSSL is not new enough.
>   SSLPolicy modern
>   SSLEngine *:443

I don't like this so much.

I'd rather a new directive altogether if it will live outside of the
affected VH and that the name convey a little more of what it's doing.

> 2. For people *moving* from http: to https: for a VirtualHost, we'd advise
>
>   <VirtualHost *:80>
>     ServerName yourhostname
>     Redirect 301 "/" "https://yourhostname/"
>   </VirtualHost>
>
>   <VirtualHost *:443>
>     ServerName yourhostname
>      ...the former http: config
>   </VirtualHost>
>

The only difference from the as-is here is that the SSL config is
implicit because of some global directive, right?

>
> 3. For people wanting to offer both http: and https: for the same resources (maybe for a trial period), what would we tell them?
> a) Copy to a new VirtualHost
> b) Make separate file and Include in two VirtualHost?
> c) Macros???

I think this leads back to 1 VH with directives like SSLRequireSSL and
automatic SSL over 443 or opted in ports.
Or, global configs w/ no VH at all that just work.
Reply | Threaded
Open this post in threaded view
|

Re: Listen 443 https

Stefan Eissing

> Am 14.09.2017 um 14:56 schrieb Eric Covener <[hidden email]>:
>
> On Fri, Sep 8, 2017 at 5:03 AM, Stefan Eissing
> <[hidden email]> wrote:
>>
>>> Am 08.09.2017 um 04:37 schrieb William A Rowe Jr <[hidden email]>:
>>>
>>> Reminder, this will not work with the current server_rec, we have a 1:1 correspondence to the server port. We would need to stop looking at that field and track the port entirely on the connection and the server rec addresses array.
>>
>> Urgs.
>>
>> 1. Irregardless of multiple addresses in a VirtualHost, I still like the idea of
>>
>>    SSLEngine *:443 local_interface:8001
>>
>> that is best used in the base server, once.
>> a) I think it is easy to understand what it does.
>> b) It prevents missing 'SSLEngine on' in a VirtualHost that needs it
>> c) It causes required fails when a VirtualHost on a SSL port has no certificates
>
> What do the parameters mean here?

Those are the addresses (same format as in VirtualHost) where "SSLEngine on" is implied, for all vhosts where no other SSLEngine is defined.

>>
>> With that, we could advise people who want to start using SSL to include the following in their main conf:
>>
>>  Listen 443
>>  # The following fails if your OpenSSL is not new enough.
>>  SSLPolicy modern
>>  SSLEngine *:443
>
> I don't like this so much.

You mean, you will not use it? Or that you think this leads to misconfigurations? Or that there is an easier way?

> I'd rather a new directive altogether if it will live outside of the
> affected VH and that the name convey a little more of what it's doing.
>
>> 2. For people *moving* from http: to https: for a VirtualHost, we'd advise
>>
>>  <VirtualHost *:80>
>>    ServerName yourhostname
>>    Redirect 301 "/" "https://yourhostname/"
>>  </VirtualHost>
>>
>>  <VirtualHost *:443>
>>    ServerName yourhostname
>>     ...the former http: config
>>  </VirtualHost>
>>
>
> The only difference from the as-is here is that the SSL config is
> implicit because of some global directive, right?

No, the SSL config is inherited, just as it is now. You can still overwrite it in the vhost.

>
>>
>> 3. For people wanting to offer both http: and https: for the same resources (maybe for a trial period), what would we tell them?
>> a) Copy to a new VirtualHost
>> b) Make separate file and Include in two VirtualHost?
>> c) Macros???
>
> I think this leads back to 1 VH with directives like SSLRequireSSL and
> automatic SSL over 443 or opted in ports.
> Or, global configs w/ no VH at all that just work.

I am not sure what you mean and if you think it's positive or not.

To recap: I am looking for an easy way to instruct someone to enable https: for

Listen 80

<VirtualHost *:80>
   ServerName blabla.org
   ...lots of stuff...
</VirtualHost>

and with the current trunk, she can change this to:

Listen 80
Listen 443
SSLEngine *:443

ManagedDomain blabla.org
<VirtualHost *:443 *:80>
   ServerName blabla.org
   ...lots of stuff...
</VirtualHost>

Hey, it's not that I *want* to define this on my own. I am asking since March for feedback on these things here. I am not sure how to react to "Don't like this so much." now.


Cheers,

Stefan

Reply | Threaded
Open this post in threaded view
|

Re: Listen 443 https

Stefan Eissing
In reply to this post by Reindl Harald-2

> Am 14.09.2017 um 12:00 schrieb Reindl Harald <[hidden email]>:
>
>
>
> Am 10.08.2017 um 18:22 schrieb Reindl Harald:
>>> If you want to experiment...
>>> <VirtualHost IP:80 IP:443>
>>> is already recognized
>> but with "SSLEngine On" and "SSLCertificateFile" configured non-https no longer would work
>
> OK, figured it out
>
> * you need the *first* vhost with "SSLEngine On"
> * others can have "SSLEngine optional" and listen to 80 and 443
>
> but there is a bug: https://bz.apache.org/bugzilla/show_bug.cgi?id=61519

This seems what ap_get_server_port() does right now which is used by ap_construct_url(), which is used in the redirect.

As William pointed out already, server_rec->port is the culprit. Will look at it to see if it can be salvaged, at least for the standard ports.

-Stefan


> if the trailing slash is missing in the url the automatic redirect to the full qualified folder-path points to http:// instead https:// and that does not happen within a vhost dedicated to :443 and "SSLEngine On"
>
> i was trapped in a endless loop because the php script making a redirect to https:// had a bug and missed the traling / too
>
> <VirtualHost *:80 *:443>
> DocumentRoot "/www/contentlounge"
> ServerName contentlounge.rhsoft.net
> SSLEngine optional
> SSLCertificateFile "conf/ssl/rhsoft.net.pem"
> </VirtualHost>
>
> [harry@srv-rhsoft:~]$ curl --head --insecure https://contentlounge/cms
> HTTP/1.1 301 Moved Permanently
> Date: Thu, 14 Sep 2017 09:40:27 GMT
> X-DNS-Prefetch-Control: off
> X-Content-Type-Options: nosniff
> X-Response-Time: D=1311 us
> Location: http://contentlounge/cms/
> Cache-Control: max-age=0
> Expires: Thu, 14 Sep 2017 09:40:27 GMT
> Content-Type: text/html; charset=iso-8859-1

Reply | Threaded
Open this post in threaded view
|

Re: Listen 443 https

Stefan Eissing
In reply to this post by Reindl Harald-2
Harald,

could you check if a configuration like:

  UseCanonicalPhysicalPort on

in the server or vhost mitigates the problem?

Cheers,

Stefan

> Am 14.09.2017 um 12:00 schrieb Reindl Harald <[hidden email]>:
>
>
>
> Am 10.08.2017 um 18:22 schrieb Reindl Harald:
>>> If you want to experiment...
>>> <VirtualHost IP:80 IP:443>
>>> is already recognized
>> but with "SSLEngine On" and "SSLCertificateFile" configured non-https no longer would work
>
> OK, figured it out
>
> * you need the *first* vhost with "SSLEngine On"
> * others can have "SSLEngine optional" and listen to 80 and 443
>
> but there is a bug: https://bz.apache.org/bugzilla/show_bug.cgi?id=61519
>
> if the trailing slash is missing in the url the automatic redirect to the full qualified folder-path points to http:// instead https:// and that does not happen within a vhost dedicated to :443 and "SSLEngine On"
>
> i was trapped in a endless loop because the php script making a redirect to https:// had a bug and missed the traling / too
>
> <VirtualHost *:80 *:443>
> DocumentRoot "/www/contentlounge"
> ServerName contentlounge.rhsoft.net
> SSLEngine optional
> SSLCertificateFile "conf/ssl/rhsoft.net.pem"
> </VirtualHost>
>
> [harry@srv-rhsoft:~]$ curl --head --insecure https://contentlounge/cms
> HTTP/1.1 301 Moved Permanently
> Date: Thu, 14 Sep 2017 09:40:27 GMT
> X-DNS-Prefetch-Control: off
> X-Content-Type-Options: nosniff
> X-Response-Time: D=1311 us
> Location: http://contentlounge/cms/
> Cache-Control: max-age=0
> Expires: Thu, 14 Sep 2017 09:40:27 GMT
> Content-Type: text/html; charset=iso-8859-1

Reply | Threaded
Open this post in threaded view
|

Re: Listen 443 https

Reindl Harald-2


Am 14.09.2017 um 15:40 schrieb Stefan Eissing:
> Harald,
>
> could you check if a configuration like:
>
>    UseCanonicalPhysicalPort on
>
> in the server or vhost mitigates the problem?

it makes it even more terrible and the resulting http:// protocol
instead https// on port 443 here even tiggers mod_security

even if it would mitigate that issue - having ports in redirect urls
easily leads to a lot of other problems when proxy-servers are part of
the game

[harry@srv-rhsoft:/mnt/data/downloads]$ curl --head --insecure
https://contentlounge/cms
HTTP/1.1 301 Moved Permanently
Date: Thu, 14 Sep 2017 13:43:06 GMT
X-DNS-Prefetch-Control: off
X-Content-Type-Options: nosniff
X-Response-Time: D=1561 us
Location: http://contentlounge:443/cms/
Cache-Control: max-age=0
Expires: Thu, 14 Sep 2017 13:43:06 GMT
Content-Type: text/html; charset=iso-8859-1

>> Am 14.09.2017 um 12:00 schrieb Reindl Harald <[hidden email]>:
>>
>>
>>
>> Am 10.08.2017 um 18:22 schrieb Reindl Harald:
>>>> If you want to experiment...
>>>> <VirtualHost IP:80 IP:443>
>>>> is already recognized
>>> but with "SSLEngine On" and "SSLCertificateFile" configured non-https no longer would work
>>
>> OK, figured it out
>>
>> * you need the *first* vhost with "SSLEngine On"
>> * others can have "SSLEngine optional" and listen to 80 and 443
>>
>> but there is a bug: https://bz.apache.org/bugzilla/show_bug.cgi?id=61519
>>
>> if the trailing slash is missing in the url the automatic redirect to the full qualified folder-path points to http:// instead https:// and that does not happen within a vhost dedicated to :443 and "SSLEngine On"
>>
>> i was trapped in a endless loop because the php script making a redirect to https:// had a bug and missed the traling / too
>>
>> <VirtualHost *:80 *:443>
>> DocumentRoot "/www/contentlounge"
>> ServerName contentlounge.rhsoft.net
>> SSLEngine optional
>> SSLCertificateFile "conf/ssl/rhsoft.net.pem"
>> </VirtualHost>
>>
>> [harry@srv-rhsoft:~]$ curl --head --insecure https://contentlounge/cms
>> HTTP/1.1 301 Moved Permanently
>> Date: Thu, 14 Sep 2017 09:40:27 GMT
>> X-DNS-Prefetch-Control: off
>> X-Content-Type-Options: nosniff
>> X-Response-Time: D=1311 us
>> Location: http://contentlounge/cms/
>> Cache-Control: max-age=0
>> Expires: Thu, 14 Sep 2017 09:40:27 GMT
>> Content-Type: text/html; charset=iso-8859-1
Reply | Threaded
Open this post in threaded view
|

Re: Listen 443 https

Stefan Eissing

> Am 14.09.2017 um 15:46 schrieb Reindl Harald <[hidden email]>:
>
>
>
> Am 14.09.2017 um 15:40 schrieb Stefan Eissing:
>> Harald,
>> could you check if a configuration like:
>>   UseCanonicalPhysicalPort on
>> in the server or vhost mitigates the problem?
>
> it makes it even more terrible and the resulting http:// protocol instead https// on port 443 here even tiggers mod_security
>
> even if it would mitigate that issue - having ports in redirect urls easily leads to a lot of other problems when proxy-servers are part of the game
>
> [harry@srv-rhsoft:/mnt/data/downloads]$ curl --head --insecure https://contentlounge/cms
> HTTP/1.1 301 Moved Permanently
> Date: Thu, 14 Sep 2017 13:43:06 GMT
> X-DNS-Prefetch-Control: off
> X-Content-Type-Options: nosniff
> X-Response-Time: D=1561 us
> Location: http://contentlounge:443/cms/
> Cache-Control: max-age=0
> Expires: Thu, 14 Sep 2017 13:43:06 GMT
> Content-Type: text/html; charset=iso-8859-1

Wow. Thanks for the quick test.

>>> Am 14.09.2017 um 12:00 schrieb Reindl Harald <[hidden email]>:
>>>
>>>
>>>
>>> Am 10.08.2017 um 18:22 schrieb Reindl Harald:
>>>>> If you want to experiment...
>>>>> <VirtualHost IP:80 IP:443>
>>>>> is already recognized
>>>> but with "SSLEngine On" and "SSLCertificateFile" configured non-https no longer would work
>>>
>>> OK, figured it out
>>>
>>> * you need the *first* vhost with "SSLEngine On"
>>> * others can have "SSLEngine optional" and listen to 80 and 443
>>>
>>> but there is a bug: https://bz.apache.org/bugzilla/show_bug.cgi?id=61519
>>>
>>> if the trailing slash is missing in the url the automatic redirect to the full qualified folder-path points to http:// instead https:// and that does not happen within a vhost dedicated to :443 and "SSLEngine On"
>>>
>>> i was trapped in a endless loop because the php script making a redirect to https:// had a bug and missed the traling / too
>>>
>>> <VirtualHost *:80 *:443>
>>> DocumentRoot "/www/contentlounge"
>>> ServerName contentlounge.rhsoft.net
>>> SSLEngine optional
>>> SSLCertificateFile "conf/ssl/rhsoft.net.pem"
>>> </VirtualHost>
>>>
>>> [harry@srv-rhsoft:~]$ curl --head --insecure https://contentlounge/cms
>>> HTTP/1.1 301 Moved Permanently
>>> Date: Thu, 14 Sep 2017 09:40:27 GMT
>>> X-DNS-Prefetch-Control: off
>>> X-Content-Type-Options: nosniff
>>> X-Response-Time: D=1311 us
>>> Location: http://contentlounge/cms/
>>> Cache-Control: max-age=0
>>> Expires: Thu, 14 Sep 2017 09:40:27 GMT
>>> Content-Type: text/html; charset=iso-8859-1

12