Re: Listen 443 https

2017-09-14 Thread Reindl Harald 



Am 14.09.2017 um 16:08 schrieb Stefan Eissing:

Ok, as I read the code a bit more, there is a tangle of things that can 
influence port/scheme selection. But what I can see, the version in *trunk* 
should do the right thing *iff*

a) you use "SSLEngine *:443" instead of "Optional"
b) you use "ServerName xxx.yyy" *without* a port name

the a

   ServerName xxx.yyy
   SSLEngine *:443
...


should do the right thing here. Internal methods used to generator Redirect 
Location headers, namely
ap_construct_url()
ap_get_server_port()
ap_http_scheme()
should give back the correct values for each connection and als fill the Env 
Variables with the correct values.


what means "trunk" here?
a future 2.5/2.6/3.0 or a 2.4.x in the near future?

within 2 weeks you need TLS on each and every host since Chrome starts 
to warn about every page with a form tag and no TLS


[root@srv-rhsoft:~]$ apachectl -t
AH00526: Syntax error on line 29 of 
/etc/httpd/conf/sites_enabled/contentlounge.conf:

Argument must be On, Off, or Optional

Am 14.09.2017 um 15:46 schrieb Reindl Harald :



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 :



Am 10.08.2017 um 18:22 schrieb Reindl Harald:

If you want to experiment...

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


DocumentRoot "/www/contentlounge"
ServerName contentlounge.rhsoft.net
SSLEngine optional
SSLCertificateFile "conf/ssl/rhsoft.net.pem"


[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

Re: Flood 0.4 status? (was: flood 0.4 was never signed for?)

2017-09-14 Thread William A Rowe Jr 
I know many of you had busy summers and August holidays... just want
to be sure that nobody who wanted to comment has missed discussion
of retiring the Flood subproject.

If we don't reach any other conclusion or interest, we should wind this down
next week in response to Daniel's concern from the Infra team.

The only remaining question is do we (httpd PMC) archive this, or do we
hand the baton off to the Attic for this legacy source code?




On Wed, Sep 6, 2017 at 12:25 AM, Luca Toscano  wrote:
> Hi William,
>
> As far as I can see the project seems abandoned, so in my opinion unless
> somebody steps up to work on it I'd be in favor of remove it from
> www.a.o/dist/httpd/flood.
>
> Luca
>
>
> 2017-09-01 18:39 GMT+02:00 William A Rowe Jr :
>>
>> What's our position on this? Is it time to declare flood abandoned?
>>
>> Are there any users of this tool who want to contribute to maintaining it?
>>
>> Offhand, I expect it does not support TLS/SNI. Nor HTTP/2.
>>
>> If abandoned, we can simply remove www.a.o/dist/httpd/flood
>> to resolve Daniel's issue. If not abandoned, regenerating the
>> tarball from should result in the same file, which can then be
>> signed.
>>
>> Thoughts?
>>
>>
>>
>> On Sat, Aug 19, 2017 at 12:43 AM, Daniel Gruno 
>> wrote:
>> > Hi folks,
>> >
>> > It appears that flood 0.4 (
>> > https://dist.apache.org/repos/dist/release/httpd/flood/ ) was never
>> > signed by anyone, which should likely be fixed. As this was, AIUI,
>> > released 8 years ago, I cannot in good conscience sign for it myself.
>> >
>> > Either we have someone who was present back then sign for it, or we
>> > should remove the release, pursuant to our release policy.
>> >
>> > With regards,
>> > Daniel.
>
>

Re: Drop HttpProtocolOptions Unsafe from 2.later/3.0 httpd releases?

2017-09-14 Thread William A Rowe Jr 
On Thu, Sep 14, 2017 at 4:50 AM, Nick Kew  wrote:
> On Wed, 13 Sep 2017 08:29:44 -0500
> William A Rowe Jr  wrote:
>
>> So moving forwards, can we stop accepting stuff that isn't HTTP/1.1 in
>> our HTTP/1.1 server? Do we really want people to configure their
>> server to speak "other"?
>
> Did you mean to say "stop accepting ..."?
>
>> I'm starting to collect https://wiki.apache.org/httpd/Applications
>> based on searching google for instances where users have toggled
>> HttpProtocolOptions Unsafe, in response to specific application
>> behavior.
>
> Perhaps a useful exercise, but could take us in to a bad cycle
> of application workarounds that long-outlive the application
> being fixed.
>
>> From this list, we might decide to allow non-HTTP/1.1 input in
>> specific cases, and perhaps have multiple grades of protocol
>> correctness, as I first proposed.
>
> You mean something like Options or AllowOverride?  Things that looked
> like a good idea at the time but led to all sorts of issues as the
> server evolved!
>
> OK, perhaps that's unduly harsh: this will be less problematic to
> maintain.  Are you enumerating cases?

I'm strictly taking a survey of reported conflicts with the newer
HttpProtocolOptions Strict behaviors.

My goal isn't to work around them, simply find out their prevalence
in order to make a binary decision over dropping all legacy GIGO
behavior (actually, garbage in, as we have generally done a nice job
of normalizing the request to the backend or response to the client,
which is what leads to splitting/injection vectors.)

Tomcat and other servers and proxies are taking serious steps
toward accepting only valid input. 2.next/3.0 won't be here for
some time, leaving lots of chances for authors to fix the defects
in the client or upstream/app server or custom clients.

My question is whether HttpProtocolOptions Unsafe is needed,
beyond the 2.4.x lifespan of our project? Conversely, did Unsafe
still block some inadvisable but tolerable requests or responses?
That's the purpose of the wiki incompatibilities page.

Re: Listen 443 https

2017-09-14 Thread Stefan Eissing 

> Am 14.09.2017 um 16:19 schrieb Eric Covener :
> 
>> To recap: I am looking for an easy way to instruct someone to enable https: 
>> for
>> 
>> Listen 80
>> 
>> 
>>   ServerName blabla.org
>>   ...lots of stuff...
>> 
>> 
>> and with the current trunk, she can change this to:
>> 
>> Listen 80
>> Listen 443
>> SSLEngine *:443
>> 
>> ManagedDomain blabla.org
>> 
>>   ServerName blabla.org
>>   ...lots of stuff...
>> 
>> 
>> 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.
> 
> It's a bit hard for me to understand the contrast points in this
> thread, even with the followups, especially as a non-mod_ssl user. So
> take my earlier feedback from today with a grain of salt.My
> personal preference is to give someone directives with expressive
> names if the objective is to make the basic configuration easier.

Understood. I can totally agree to the point about descriptive names. I am not 
a big fan of "SSLEngine" myself. I chose it because:

a) it already is the central directive to enable mod_ssl
b) there are other *Engine configs similar, so it is a common pattern in httpd.
c) A new directive would need to describe how it interacts with SSLEngine and 
what has precedence where.

But we could use a different name. I would, no matter the name, like a 
directive that is one line in the global context. Editing the same directives 
in all virtual hosts is tedious, error-prone work *). 


One other way of providing more descriptive SSL setups would be a new 
"SSLPolicy" directives. We could pre-define


  SSLEngine *:443


and people just add

SSLPolicy auto-enable

to their httpd.conf (we need *some* new config, to make that happen in 2.4.x).

Cheers,
Stefan

*) I already got several people testing mod_md and forgetting "SSLEngine on". 
The problem is that clients often spew out a cryptic (haha!) error message 
about TLS record lengths or some such that does not really help people to 
discover their, easy to fix, mistake.

Re: Listen 443 https

2017-09-14 Thread Eric Covener 
> To recap: I am looking for an easy way to instruct someone to enable https: 
> for
>
> Listen 80
>
> 
>ServerName blabla.org
>...lots of stuff...
> 
>
> and with the current trunk, she can change this to:
>
> Listen 80
> Listen 443
> SSLEngine *:443
>
> ManagedDomain blabla.org
> 
>ServerName blabla.org
>...lots of stuff...
> 
>
> 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.

It's a bit hard for me to understand the contrast points in this
thread, even with the followups, especially as a non-mod_ssl user. So
take my earlier feedback from today with a grain of salt.My
personal preference is to give someone directives with expressive
names if the objective is to make the basic configuration easier.

Re: Listen 443 https

2017-09-14 Thread Stefan Eissing 
Ok, as I read the code a bit more, there is a tangle of things that can 
influence port/scheme selection. But what I can see, the version in *trunk* 
should do the right thing *iff*

a) you use "SSLEngine *:443" instead of "Optional"
b) you use "ServerName xxx.yyy" *without* a port name

the a 

  ServerName xxx.yyy
  SSLEngine *:443
   ...


should do the right thing here. Internal methods used to generator Redirect 
Location headers, namely
ap_construct_url()
ap_get_server_port()
ap_http_scheme()
should give back the correct values for each connection and als fill the Env 
Variables with the correct values.

-Stefan

> Am 14.09.2017 um 15:46 schrieb Reindl Harald :
> 
> 
> 
> 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 :
>>> 
>>> 
>>> 
>>> Am 10.08.2017 um 18:22 schrieb Reindl Harald:
> If you want to experiment...
> 
> 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
>>> 
>>> 
>>> DocumentRoot "/www/contentlounge"
>>> ServerName contentlounge.rhsoft.net
>>> SSLEngine optional
>>> SSLCertificateFile "conf/ssl/rhsoft.net.pem"
>>> 
>>> 
>>> [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

Re: Listen 443 https

2017-09-14 Thread Reindl Harald 



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 :



Am 10.08.2017 um 18:22 schrieb Reindl Harald:

If you want to experiment...

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


DocumentRoot "/www/contentlounge"
ServerName contentlounge.rhsoft.net
SSLEngine optional
SSLCertificateFile "conf/ssl/rhsoft.net.pem"


[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

Re: Listen 443 https

2017-09-14 Thread Stefan Eissing 
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 :
> 
> 
> 
> Am 10.08.2017 um 18:22 schrieb Reindl Harald:
>>> If you want to experiment...
>>> 
>>> 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
> 
> 
> DocumentRoot "/www/contentlounge"
> ServerName contentlounge.rhsoft.net
> SSLEngine optional
> SSLCertificateFile "conf/ssl/rhsoft.net.pem"
> 
> 
> [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

Re: Listen 443 https

2017-09-14 Thread Stefan Eissing 

> Am 14.09.2017 um 12:00 schrieb Reindl Harald :
> 
> 
> 
> Am 10.08.2017 um 18:22 schrieb Reindl Harald:
>>> If you want to experiment...
>>> 
>>> 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
> 
> 
> DocumentRoot "/www/contentlounge"
> ServerName contentlounge.rhsoft.net
> SSLEngine optional
> SSLCertificateFile "conf/ssl/rhsoft.net.pem"
> 
> 
> [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

Re: Listen 443 https

2017-09-14 Thread Stefan Eissing 

> Am 14.09.2017 um 14:56 schrieb Eric Covener :
> 
> On Fri, Sep 8, 2017 at 5:03 AM, Stefan Eissing
>  wrote:
>> 
>>> Am 08.09.2017 um 04:37 schrieb William A Rowe Jr :
>>> 
>>> 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
>> 
>>  
>>ServerName yourhostname
>>Redirect 301 "/" "https://yourhostname/;
>>  
>> 
>>  
>>ServerName yourhostname
>> ...the former http: config
>>  
>> 
> 
> 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


   ServerName blabla.org
   ...lots of stuff...


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

Listen 80
Listen 443
SSLEngine *:443

ManagedDomain blabla.org

   ServerName blabla.org
   ...lots of stuff...


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

Re: Listen 443 https

2017-09-14 Thread Eric Covener 
On Fri, Sep 8, 2017 at 5:03 AM, Stefan Eissing
 wrote:
>
>> Am 08.09.2017 um 04:37 schrieb William A Rowe Jr :
>>
>> 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
>
>   
> ServerName yourhostname
> Redirect 301 "/" "https://yourhostname/;
>   
>
>   
> ServerName yourhostname
>  ...the former http: config
>   
>

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.

Re: Listen 443 https

2017-09-14 Thread Reindl Harald 



Am 10.08.2017 um 18:22 schrieb Reindl Harald:

If you want to experiment...

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



 DocumentRoot "/www/contentlounge"
 ServerName contentlounge.rhsoft.net
 SSLEngine optional
 SSLCertificateFile "conf/ssl/rhsoft.net.pem"


[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

Re: Drop HttpProtocolOptions Unsafe from 2.later/3.0 httpd releases?

2017-09-14 Thread Nick Kew 
On Wed, 13 Sep 2017 08:29:44 -0500
William A Rowe Jr  wrote:

> So moving forwards, can we stop accepting stuff that isn't HTTP/1.1 in
> our HTTP/1.1 server? Do we really want people to configure their
> server to speak "other"?

Did you mean to say "stop accepting ..."?

> I'm starting to collect https://wiki.apache.org/httpd/Applications
> based on searching google for instances where users have toggled
> HttpProtocolOptions Unsafe, in response to specific application
> behavior.

Perhaps a useful exercise, but could take us in to a bad cycle
of application workarounds that long-outlive the application
being fixed.

> From this list, we might decide to allow non-HTTP/1.1 input in
> specific cases, and perhaps have multiple grades of protocol
> correctness, as I first proposed.

You mean something like Options or AllowOverride?  Things that looked
like a good idea at the time but led to all sorts of issues as the
server evolved!

OK, perhaps that's unduly harsh: this will be less problematic to
maintain.  Are you enumerating cases?

-- 
Nick Kew