Re: Please support/enable https by default in the Apache web sever.

2023-09-30 Thread General Email
On Sat, 30 Sep, 2023, 9:32 pm Joe Schaefer,  wrote:

> It is insane to ask this project to cater to the interests of 10 people
> who are so PKI illiterate, the PMC needs to put the rest of the user base
> at risk just to accommodate them.
>
> Certs require mandatory user serviceable parts.  There is no meaningful
> way to  provide a default.
>
> Thanks.
>


Well, if you don't want to do this, its fine.

But you can't abuse the developers by calling them illiterate.

Your words are abusive and offensive for no reason.

I don't like abusive people like you.

I will now not continue this discussion.

By the way, I asked for this change in apache http server. But, may be
thousands of web developers also want the same change but they didn't
approach the dev people of apache http server.

But anyways, this discussion has become abusive now. So I am no more
interested in this discussion.

GE


Re: Please support/enable https by default in the Apache web sever.

2023-09-30 Thread Noel Butler

On 01/10/2023 00:10, General Email wrote:

How hard is it really to uncomment one hash sign and edit a file to set 
correct DocumentRoot  and hostnames and where the keys are... (thats 
rhetorical by the way not actually a question)


What I said was to enable https by default and XAMPP have made it quite 
easy.
If it can't be enabled by default then at least it should be as simple 
as adding one line or uncommenting one line: Listen 443.


I suggest you're trolling, are you on xampps public relations team, I 
mean seriously you come here pushing your agenda with arguments that 
don't make sense, but can't be bothered using your real name or real 
email address.


Currently, enabling https in apache http server is not easy and takes 
multiple steps.


really? I outlined in the first paragraph how EASY it was, if that is 
hard for you, then I suggest you contract someone to do it all for you.


Apache is used by many fortune 500 companies as well as the smaller 
guys, many F500's still insist on using paid certs for the perceived 
beliefs of better trust and recourse for when the likes of debian do 
what they did 10 years ago and compromise openssl.  No project should 
include snakeoil. They might have been OK years ago when we were charged 
criminal rates by likes of verisgn, thawte and co to get a signed cert, 
but those days ended a long time ago.


--
Regards,
Noel Butler

This Email, including attachments, may contain legally privileged 
information, therefore at all times remains confidential and subject to 
copyright protected under international law. You may not disseminate 
this message without the authors express written authority to do so.   
If you are not the intended recipient, please notify the sender then 
delete all copies of this message including attachments immediately. 
Confidentiality, copyright, and legal privilege are not waived or lost 
by reason of the mistaken delivery of this message.

Re: svn commit: r1912459 - in /httpd/httpd/trunk: include/ modules/proxy/

2023-09-30 Thread Ruediger Pluem



On 9/21/23 3:15 PM, yla...@apache.org wrote:
> Author: ylavic
> Date: Thu Sep 21 13:15:35 2023
> New Revision: 1912459
> 
> URL: http://svn.apache.org/viewvc?rev=1912459=rev
> Log:
> mod_proxy: Handle backend address renewal with address_ttl= parameter.
> 
> Define a new proxy_address struct holding the current/latest sockaddr in use
> by each proxy worker and conn. Since backend addresses can be updated when
> their TTL expires and while connections are being processed, each address is
> refcounted and freed only when the last worker (or conn) using it grabs the
> new one.
> 
> The lifetime of the addresses is handled at a single place by the new
> ap_proxy_determine_address() function. It guarantees to bind the 
> current/latest
> backend address to the passed in conn (or do nothing if it's up to date 
> already).
> The function is called indirectly by ap_proxy_determine_connection() for the
> proxy modules that use it, or directly by mod_proxy_ftp and mod_proxy_hcheck.
> It also is called eventually by ap_proxy_connect_backend() when connect()ing 
> all
> the current addresses fails, to check (PROXY_DETERMINE_ADDRESS_CHECK) if some
> new addrs are available.
> 
> This commit is also a rework of the lifetime of conn->addr, conn->hostname
> and conn->forward, using the conn->uds_pool and conn->fwd_pool for the cases
> where the backend is connected through a UDS socket and a remote CONNECT proxy
> respectively.
> 
> * include/ap_mmn.h:
>   Minor bump for new function/fields.
> 
> * modules/proxy/mod_proxy.h (struct proxy_address,
>  ap_proxy_determine_addresss()):
>   Declare ap_proxy_determine_addresss() and opaque struct proxy_address,
>   new fields to structs proxy_conn_rec/proxy_worker_shared/proxy_worker.
> 
> * modules/proxy/mod_proxy.c (set_worker_param):
>   Parse/set the new worker->address_ttl parameter.
> 
> * modules/proxy/proxy_util.c (proxy_util_register_hooks(),
>   ap_proxy_initialize_worker(),
>   ap_proxy_connection_reusable(),
>   ap_proxyerror(), proxyerror_core(),
>   init_conn_pool(), make_conn_subpool(),
>   connection_make(), connection_cleanup(),
>   connection_constructor()):
>  Initialize *proxy_start_time in proxy_util_register_hooks() as the epoch
>  from which expiration times are relative (i.e. seconds stored in an uint32_t
>  for atomic changes).
>  Make sure worker->s->is_address_reusable and worker->s->disablereuse are
>  consistant in ap_proxy_initialize_worker(), thus no need to check for both
>  in ap_proxy_connection_reusable().
>  New proxyerror_core() helper taking an apr_status_t to log, wrap in
>  ap_proxyerror().
>  New make_conn_subpool() to create worker->cp->{pool,dns} with their own
>  allocator.
>  New connection_make() helper to factorize code in connection_cleanup() and
>  connection_constructor().
> 
> * modules/proxy/proxy_util.c (proxy_address_inc(), proxy_address_dec(),
>   proxy_address_cleanup(), 
> proxy_address_set_expired(),
>   worker_address_get(), worker_address_set(),
>   worker_address_resolve(), proxy_addrs_equal(),
>   ap_proxy_determine_address(),
>   ap_proxy_determine_connection(),
>   ap_proxy_connect_backend()):
>  Implement ap_proxy_determine_address() using the above helpers for atomic 
> changes,
>  and call it from ap_proxy_determine_connection() and 
> ap_proxy_connect_backend().
> 
> * modules/proxy/mod_proxy_ftp.c (proxy_ftp_handler):
>   Use ap_proxy_determine_address() and use the returned backend->addr.
> 
> * modules/proxy/mod_proxy_hcheck.c (hc_determine_connection, hc_get_backend,
> hc_init_worker, hc_watchdog_callback):
>   Use ap_proxy_determine_address() in hc_determine_connection() and call the
>   latter from hc_get_backend(), replace hc_init_worker() by hc_init_baton()
>   which now calls hc_get_hcworker() and hc_get_backend() to resolve the first
>   address at init time.
> 
> * modules/proxy/mod_proxy_http.c (proxy_http_handler):
>   Use backend->addr and ->hostname instead of worker->cp->addr and
>   worker->s->hostname_ex respectively.
> 
> * modules/proxy/mod_proxy_ajp.c (ap_proxy_ajp_request):
>   Use backend->addr and ->hostname instead of worker->cp->addr and
>   worker->s->hostname_ex respectively.
> 
> 
> Closes #367
> 
> 
> Modified:
> httpd/httpd/trunk/include/ap_mmn.h
> httpd/httpd/trunk/modules/proxy/mod_proxy.c
> httpd/httpd/trunk/modules/proxy/mod_proxy.h
> httpd/httpd/trunk/modules/proxy/mod_proxy_ajp.c
> httpd/httpd/trunk/modules/proxy/mod_proxy_ftp.c
> httpd/httpd/trunk/modules/proxy/mod_proxy_hcheck.c
> httpd/httpd/trunk/modules/proxy/mod_proxy_http.c
> 

Re: Please support/enable https by default in the Apache web sever.

2023-09-30 Thread Joe Schaefer
It is insane to ask this project to cater to the interests of 10 people who
are so PKI illiterate, the PMC needs to put the rest of the user base at
risk just to accommodate them.

Certs require mandatory user serviceable parts.  There is no meaningful way
to  provide a default.

Thanks.

On Sat, Sep 30, 2023 at 10:45 AM General Email <
general.email.12341...@gmail.com> wrote:

>
>
> On Sat, 30 Sep, 2023, 8:00 pm Emmanuel Dreyfus,  wrote:
>
>> On Sat, Sep 30, 2023 at 07:40:34PM +0530, General Email wrote:
>> > By the way, I don't understand how the default certificate can be
>> abused.
>>
>> It is not signed by a trusted CA, hence your browser cannot tell if it
>> is speaking to your legitimate web server, or to some malware lurking
>> in between. Perhaps your web trafic is not worth being evesdropped, but
>> consider a malware could inject an exploit against your browser in your
>> web trafic. The attacker could just be an infected machine on the same
>> LAN.
>>
>> The security level of an untrusted ceritificate is not much better than
>> plain text HTTP.
>>
>
>
> Yes, I understand this.
>
> We will not be using the default untrusted certificate when we go live.
>
> But during development, if 10 people are working on the development of one
> website and each of them has their own apache http installation, then we
> have to generate 10 certificates and do a few changes or more than few
> changes to get https enabled on each of 10 installations.
>
> Having a default certificate (not signed by trusted CA) in official http
> server will make enabling https on each installation much easier and we
> won't have to generate 10 certificates, etc.
>
> Regards,
> GE
>
>


Re: Please support/enable https by default in the Apache web sever.

2023-09-30 Thread Stefan Eissing via dev
Even for test setups with a few users, I recommend something like this: 


We use this method in our test and CI workflows as well. 

Cheers,
Stefan

> Am 30.09.2023 um 16:42 schrieb General Email 
> :
> 
> 
> 
> On Sat, 30 Sep, 2023, 8:00 pm Emmanuel Dreyfus,  wrote:
> On Sat, Sep 30, 2023 at 07:40:34PM +0530, General Email wrote:
> > By the way, I don't understand how the default certificate can be abused.
> 
> It is not signed by a trusted CA, hence your browser cannot tell if it
> is speaking to your legitimate web server, or to some malware lurking
> in between. Perhaps your web trafic is not worth being evesdropped, but
> consider a malware could inject an exploit against your browser in your
> web trafic. The attacker could just be an infected machine on the same
> LAN.
> 
> The security level of an untrusted ceritificate is not much better than
> plain text HTTP.
> 
> 
> Yes, I understand this.
> 
> We will not be using the default untrusted certificate when we go live.
> 
> But during development, if 10 people are working on the development of one 
> website and each of them has their own apache http installation, then we have 
> to generate 10 certificates and do a few changes or more than few changes to 
> get https enabled on each of 10 installations.
> 
> Having a default certificate (not signed by trusted CA) in official http 
> server will make enabling https on each installation much easier and we won't 
> have to generate 10 certificates, etc.
> 
> Regards,
> GE
> 



Re: Please support/enable https by default in the Apache web sever.

2023-09-30 Thread Stefan Eissing via dev
Take for example Caddy, which is https: by default and gets you a valid Let's 
Encrypt certificate (unless you configure it to do something different). You 
enter your domain in the config file and it does the rest.

Such a setup would be possible with Apache as well. It's a matter of the 
configuration files the installed package provides.

But some people do not want this. Some people prefer to use certbot or acme.sh 
or another setup. There is a large variety how this can go and no single best 
solution for everyone.

I have written several recipes for Apache ACME myself to help people with this. 
See 

Cheers,
Stefan


> Am 30.09.2023 um 16:30 schrieb Emmanuel Dreyfus :
> 
> On Sat, Sep 30, 2023 at 07:40:34PM +0530, General Email wrote:
>> By the way, I don't understand how the default certificate can be abused.
> 
> It is not signed by a trusted CA, hence your browser cannot tell if it
> is speaking to your legitimate web server, or to some malware lurking
> in between. Perhaps your web trafic is not worth being evesdropped, but
> consider a malware could inject an exploit against your browser in your
> web trafic. The attacker could just be an infected machine on the same
> LAN.
> 
> The security level of an untrusted ceritificate is not much better than
> plain text HTTP. 
> 
> -- 
> Emmanuel Dreyfus
> m...@netbsd.org



Re: Please support/enable https by default in the Apache web sever.

2023-09-30 Thread General Email
On Sat, 30 Sep, 2023, 8:00 pm Emmanuel Dreyfus,  wrote:

> On Sat, Sep 30, 2023 at 07:40:34PM +0530, General Email wrote:
> > By the way, I don't understand how the default certificate can be abused.
>
> It is not signed by a trusted CA, hence your browser cannot tell if it
> is speaking to your legitimate web server, or to some malware lurking
> in between. Perhaps your web trafic is not worth being evesdropped, but
> consider a malware could inject an exploit against your browser in your
> web trafic. The attacker could just be an infected machine on the same
> LAN.
>
> The security level of an untrusted ceritificate is not much better than
> plain text HTTP.
>


Yes, I understand this.

We will not be using the default untrusted certificate when we go live.

But during development, if 10 people are working on the development of one
website and each of them has their own apache http installation, then we
have to generate 10 certificates and do a few changes or more than few
changes to get https enabled on each of 10 installations.

Having a default certificate (not signed by trusted CA) in official http
server will make enabling https on each installation much easier and we
won't have to generate 10 certificates, etc.

Regards,
GE


Re: Please support/enable https by default in the Apache web sever.

2023-09-30 Thread Emmanuel Dreyfus
On Sat, Sep 30, 2023 at 07:40:34PM +0530, General Email wrote:
> By the way, I don't understand how the default certificate can be abused.

It is not signed by a trusted CA, hence your browser cannot tell if it
is speaking to your legitimate web server, or to some malware lurking
in between. Perhaps your web trafic is not worth being evesdropped, but
consider a malware could inject an exploit against your browser in your
web trafic. The attacker could just be an infected machine on the same
LAN.

The security level of an untrusted ceritificate is not much better than
plain text HTTP. 

-- 
Emmanuel Dreyfus
m...@netbsd.org


Re: Please support/enable https by default in the Apache web sever.

2023-09-30 Thread General Email
On Sat, 30 Sep, 2023, 7:06 pm Noel Butler,  wrote:

> On 30/09/2023 22:28, General Email wrote:
>
>
>
> On Sat, 30 Sep, 2023, 5:34 pm Will Fatherley, 
> wrote:
>
>
>
> Please support/enable https by default in the Apache web server.
>
>
> HTTPS is supported already by default. I like the idea of enabling by
> default, but as it stands now probably should not be done as the generation
> of keying material is required; the certification of keying material, while
> capable of being automated, may become overburdened or more easily abused;
> and other such complications related to authentication.
>
>
> In XAMPP (https://www.apachefriends.org/download.html) https can be
> enabled easily (change of only couple of lines is required).
>
> XAMPP has apache http web server.
>
> It looks like they have a default SSL certificate in their distribution.
>
> Fitefox and other browsers complain something like "the certificate is not
> trusted" but they also give an option of taking the risk and going ahead.
> When you go ahead, you can access your site using https.
>
> This is good when a developer is developing a website on his local
> computer.
>
> Later, when going for hosting the website, the hosting providers do
> everything for you for supporting https.
>
> So, if whatever XAMPP has done in their distribution of apache http
> server, if the same can be done in official apache http server then this
> will be of great help during  website development and testing.
>
> Regards,
> GE
>
>
>
>
> Please re-read Stefan's reply.
>
> It is not up to the project to dictate to administrators, there are
> examples that are easy implementable, use them. The project is not to know
> where you want your docroot, if you want CGI or what directories require
> special permissions or options are they, configuring your host to how you
> want it is your job.
>
> How hard is it really to uncomment one hash sign and edit a file to set
> correct DocumentRoot  and hostnames and where the keys are... (thats
> rhetorical by the way not actually a question)
>
> And as for those "webhosts" doing it automatically, all we do is use a
> vhost template that we created and is used when adding each host,
> customised by perl or php or whatever prog language the webhost uses in
> their backend.
>

I actually didn't understand your answer.

What I said was to enable https by default and XAMPP have made it quite
easy.

If it can't be enabled by default then at least it should be as simple as
adding one line or uncommenting one line: Listen 443.

Currently, enabling https in apache http server is not easy and takes
multiple steps.

XAMPP doesn't require generation of SSL  certificate by the user but its
certificate can't be used in production and this is ok because its
certificate can be used during development.

I am just suggesting that why can't official apache http server do the same
as XAMPP.

The main problem is that it is not recommended to use XAMPP in production
so we need official apache http server in production.

By the way, I don't understand how the default certificate can be abused.

Anyways, may be I didn't understand well enough but please have a look as
to how XAMPP is doing it and whether their certificates, etc. can also be
abused or not.

Regards,
GE


Re: Please support/enable https by default in the Apache web sever.

2023-09-30 Thread Noel Butler

On 30/09/2023 22:28, General Email wrote:

On Sat, 30 Sep, 2023, 5:34 pm Will Fatherley,  
wrote:


Please support/enable https by default in the Apache web server.

HTTPS is supported already by default. I like the idea of enabling by 
default, but as it stands now probably should not be done as the 
generation of keying material is required; the certification of keying 
material, while capable of being automated, may become overburdened or 
more easily abused; and other such complications related to 
authentication.


In XAMPP (https://www.apachefriends.org/download.html) https can be 
enabled easily (change of only couple of lines is required).


XAMPP has apache http web server.

It looks like they have a default SSL certificate in their distribution.

Fitefox and other browsers complain something like "the certificate is 
not trusted" but they also give an option of taking the risk and going 
ahead. When you go ahead, you can access your site using https.


This is good when a developer is developing a website on his local 
computer.


Later, when going for hosting the website, the hosting providers do 
everything for you for supporting https.


So, if whatever XAMPP has done in their distribution of apache http 
server, if the same can be done in official apache http server then this 
will be of great help during  website development and testing.


Regards,
GE





Please re-read Stefan's reply.

It is not up to the project to dictate to administrators, there are 
examples that are easy implementable, use them. The project is not to 
know where you want your docroot, if you want CGI or what directories 
require special permissions or options are they, configuring your host 
to how you want it is your job.


How hard is it really to uncomment one hash sign and edit a file to set 
correct DocumentRoot  and hostnames and where the keys are... (thats 
rhetorical by the way not actually a question)


And as for those "webhosts" doing it automatically, all we do is use a 
vhost template that we created and is used when adding each host, 
customised by perl or php or whatever prog language the webhost uses in 
their backend.

Re: Please support/enable https by default in the Apache web sever.

2023-09-30 Thread General Email
On Sat, 30 Sep, 2023, 5:34 pm Will Fatherley,  wrote:

>
> Please support/enable https by default in the Apache web server.
>>
>
> HTTPS is supported already by default. I like the idea of enabling by
> default, but as it stands now probably should not be done as the generation
> of keying material is required; the certification of keying material, while
> capable of being automated, may become overburdened or more easily abused;
> and other such complications related to authentication.
>

In XAMPP (https://www.apachefriends.org/download.html) https can be enabled
easily (change of only couple of lines is required).

XAMPP has apache http web server.

It looks like they have a default SSL certificate in their distribution.

Fitefox and other browsers complain something like "the certificate is not
trusted" but they also give an option of taking the risk and going ahead.
When you go ahead, you can access your site using https.

This is good when a developer is developing a website on his local computer.

Later, when going for hosting the website, the hosting providers do
everything for you for supporting https.

So, if whatever XAMPP has done in their distribution of apache http server,
if the same can be done in official apache http server then this will be of
great help during  website development and testing.

Regards,
GE


Re: Please support/enable https by default in the Apache web sever.

2023-09-30 Thread Stefan Eissing via dev



> Am 30.09.2023 um 14:04 schrieb Will Fatherley :
> 
> 
> Please support/enable https by default in the Apache web server.
> 
> HTTPS is supported already by default. I like the idea of enabling by 
> default, but as it stands now probably should not be done as the generation 
> of keying material is required; the certification of keying material, while 
> capable of being automated, may become overburdened or more easily abused; 
> and other such complications related to authentication.

The capabilities are all there. It's a matter how your Apache is configured on 
install by whatever distribution you use. Since we do not provide installation 
packages, the project can not solve this for you.

Kind Regards,
Stefan





Re: Please support/enable https by default in the Apache web sever.

2023-09-30 Thread Will Fatherley
> Please support/enable https by default in the Apache web server.
>

HTTPS is supported already by default. I like the idea of enabling by
default, but as it stands now probably should not be done as the generation
of keying material is required; the certification of keying material, while
capable of being automated, may become overburdened or more easily abused;
and other such complications related to authentication.

>


Please support/enable https by default in the Apache web sever.

2023-09-30 Thread General Email
Hi,

Everyone is moving to "https" these days. Almost no one is using "http"
these days.

Please support/enable https by default in the Apache web server.

Enabling https support manually is a lengthy (and probably a little bit
difficult) process.

Regards,
GE