Mailing List Archive

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

>

> Am 30.09.2023 um 14:04 schrieb Will Fatherley <wefatherley@gmail.com>:
>
>
> 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

On Sat, 30 Sep, 2023, 5:34 pm Will Fatherley, <wefatherley@gmail.com> 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

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

> On Sat, 30 Sep, 2023, 5:34 pm Will Fatherley, <wefatherley@gmail.com>
> 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.

On Sat, 30 Sep, 2023, 7:06 pm Noel Butler, <noel.butler@ausics.net> wrote:

> On 30/09/2023 22:28, General Email wrote:
>
>
>
> On Sat, 30 Sep, 2023, 5:34 pm Will Fatherley, <wefatherley@gmail.com>
> 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

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
manu@netbsd.org

On Sat, 30 Sep, 2023, 8:00 pm Emmanuel Dreyfus, <manu@netbsd.org> 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

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 <https://github.com/icing/mod_md>

Cheers,
Stefan


> Am 30.09.2023 um 16:30 schrieb Emmanuel Dreyfus <manu@netbsd.org>:
>
> 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
> manu@netbsd.org

Even for test setups with a few users, I recommend something like this: <https://github.com/icing/blog/blob/main/test_server_tls.md>

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

Cheers,
Stefan

> Am 30.09.2023 um 16:42 schrieb General Email <general.email.12341234@gmail.com>:
>
>
>
> On Sat, 30 Sep, 2023, 8:00 pm Emmanuel Dreyfus, <manu@netbsd.org> 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
>

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.12341234@gmail.com> wrote:

>
>
> On Sat, 30 Sep, 2023, 8:00 pm Emmanuel Dreyfus, <manu@netbsd.org> 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
>
>

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.

On Sat, 30 Sep, 2023, 9:32 pm Joe Schaefer, <joe@sunstarsys.com> 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

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


I am not trolling but I don't use my real name/email address online.

This is because everything online is almost public and google indexes
everything.

So, if someone searches for me online, he/she can find out what I am doing,
where am I involved, etc. and I don't want people to know all this.

GE

>

>

On 01/10/2023 16:06, General Email wrote:

>> 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.
>
> I am not trolling but I don't use my real name/email address online.
>
> This is because everything online is almost public and google indexes
> everything.
>
> So, if someone searches for me online, he/she can find out what I am
> doing, where am I involved, etc. and I don't want people to know all
> this.
>
> GE
>
>>

If you are that paranoid the only option really is to cut that chord.

And you'd be the first person who claims to be a web dev that doesn't
put their name to their code, courts don't recognise an alias if someone
plagiarises your work.

this is bad mean person signing off lolololol

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