Re: [users@httpd] Fw: unsubscribe

[Eric Covener]

On Thu, Feb 8, 2018 at 9:18 PM, Richards, Toby
 wrote:
> I sent my unsubscribe message over seven hours ago. Why am I still getting
> messages?

Wrong target.  users-unsubscr...@httpd.apache.org

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

[users@httpd] Fw: unsubscribe

[Richards, Toby]

?I sent my unsubscribe message over seven hours ago. Why am I still getting 
messages?



Respectfully Submitted,
R. Toby Richards
Network Administrator
Superior Court of California
In and for the County of San Luis Obispo
(805) 781-4150

From: Richards, Toby
Sent: Thursday, February 8, 2018 10:50 AM
To: list-unsubscr...@apache.org
Subject: unsubscribe



Respectfully Submitted,
R. Toby Richards, Network Administrator
Superior Court of California in and for the County of San Luis Obispo
(805) 781-4150

Re: [users@httpd] Help with ProxyPass and ProxyPassReverse

[John Iliffe]

Please ignore this post.

I knew I was looking at it and not seeing it and the act of sending the 
help request made me look again.

Fixed now.

Sorry for the noise.

John
===
On Thursday 08 February 2018 20:31:45 John Iliffe wrote:
> I have a HTTP mail client running on port 7080 on the server that must
> be proxied through Apache.
> 
> Using a workstation, I can enter:
> 
>http://192.168.1.7:7080/mail.html
> 
> and it brings up the mail client correctly.
> 
> I tried to use ProxyPass/ProxyPassReverse to move the mail client to run
> on port 80 with the following configuration:
> 
> # Surgemail redirect to allow web based e-mail
> 
>ServerName mail.mymaildomain.ca
>ProxyPass "/" "http://127.0.0.1:7080/;
>ProxyPassReverse "/" "http://127.0.0.1:7080/;
>ProxyPassReverseCookieDomain "127.0.0.1" "mail.mymaildomain.ca"
> 
> 
> I also tried
> 
>   ProxyPass "/" "http://127.0.0.1:7080/mail.html;
>   ProxyPassReverse "/" "http://127.0.0.1:7080/mail.html;
> 
> In the first case, when I try to log onto the mail client, the content
> of the page comes up fine BUT the style sheet isn't available and none
> of the links on the login page work.  Clicking on any link from here
> gives the error message:
> 
> 
> Firefox can't establish a connection to the server at 127.0.0.1:7080.
> 
> 
> The second form gives the error:
> 
> --
> The proxy server received an invalid response from an upstream server.
> The proxy server could not handle the request GET /mail.html.
> 
> Reason: DNS lookup failure for: 127.0.0.1:7080mail.html  (note there is
> no / after the socket id in the error message)
> --
> 
> The issue seems to be that the server internal IP (127.0.0.1) is being
> passed back to the browser and is being tried on the local workstation.
> 
> Obviously I don't have the proxy set up properly but this looks to me
> like what the documentation is saying.  Can anyone assist me to fix it?
> 
> Thanks in advance,
> 
> John
> =
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

[users@httpd] Help with ProxyPass and ProxyPassReverse

[John Iliffe]

I have a HTTP mail client running on port 7080 on the server that must be 
proxied through Apache.

Using a workstation, I can enter:

   http://192.168.1.7:7080/mail.html

and it brings up the mail client correctly.

I tried to use ProxyPass/ProxyPassReverse to move the mail client to run on 
port 80 with the following configuration:

# Surgemail redirect to allow web based e-mail

   ServerName mail.mymaildomain.ca
   ProxyPass "/" "http://127.0.0.1:7080/;
   ProxyPassReverse "/" "http://127.0.0.1:7080/;
   ProxyPassReverseCookieDomain "127.0.0.1" "mail.mymaildomain.ca"


I also tried

  ProxyPass "/" "http://127.0.0.1:7080/mail.html;
  ProxyPassReverse "/" "http://127.0.0.1:7080/mail.html;

In the first case, when I try to log onto the mail client, the content of 
the page comes up fine BUT the style sheet isn't available and none of the 
links on the login page work.  Clicking on any link from here gives the 
error message:


Firefox can't establish a connection to the server at 127.0.0.1:7080.


The second form gives the error:

--
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /mail.html.

Reason: DNS lookup failure for: 127.0.0.1:7080mail.html  (note there is no 
/ after the socket id in the error message)
--

The issue seems to be that the server internal IP (127.0.0.1) is being 
passed back to the browser and is being tried on the local workstation.  

Obviously I don't have the proxy set up properly but this looks to me like 
what the documentation is saying.  Can anyone assist me to fix it?

Thanks in advance,

John
=

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] websocket header not passing a long with ProxyPass and mod_headers

[Rainer Jung]

Am 08.02.2018 um 19:50 schrieb Mark Nenadov:

according to the docs, you can actually specify the protocol:

https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html :

"In fact the module can be used to upgrade to other protocols, you can set the 
upgrade parameter in the ProxyPass directive to allow the module to accept other 
protocol."

 From https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypass :

"Parameter "upgrade", default "WebSocket": Protocol accepted in the Upgrade header 
by mod_proxy_wstunnel. See the documentation of this module for more details."

So maybe setting "upgrade=websocket" as a ProxyPass parameter might already 
achieve what Mark is looking for?

Regards
Jens


Hi Jens,

I saw this upgrade parameter in the manual earlier and tried it. But
it doesn't appear to be valid (manual reference notwithstanding),
config test complains about a syntax error when I add it, even with
providing the default value.

The manual isn't very clear about it.

The documentation for the mod_proxy_wstunnel
(https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html)
suggests that it should be upgrade=ANY or upgrade=NONE. But I still
can't get configtest to pass with it set to ANY or NONE either.


Can you post one of your failed configs and the error message?

It should be something like

< LocationMatch "/somewhere" >
  ProxyPass wss://192.168.1.77/some_url_on_tomcat upgrade=websocket
< / LocationMatch >

Regards,

Rainer


-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] websocket header not passing a long with ProxyPass and mod_headers

[Mark Nenadov]

> according to the docs, you can actually specify the protocol:
>
> https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html :
>
> "In fact the module can be used to upgrade to other protocols, you can set 
> the upgrade parameter in the ProxyPass directive to allow the module to 
> accept other protocol."
>
> From https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypass :
>
> "Parameter "upgrade", default "WebSocket": Protocol accepted in the Upgrade 
> header by mod_proxy_wstunnel. See the documentation of this module for more 
> details."
>
> So maybe setting "upgrade=websocket" as a ProxyPass parameter might already 
> achieve what Mark is looking for?
>
> Regards
> Jens

Hi Jens,

I saw this upgrade parameter in the manual earlier and tried it. But
it doesn't appear to be valid (manual reference notwithstanding),
config test complains about a syntax error when I add it, even with
providing the default value.

The manual isn't very clear about it.

The documentation for the mod_proxy_wstunnel
(https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html)
suggests that it should be upgrade=ANY or upgrade=NONE. But I still
can't get configtest to pass with it set to ANY or NONE either.

Thanks,
~Mark

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] websocket header not passing a long with ProxyPass and mod_headers

[Mark Nenadov]

On Thu, Feb 8, 2018 at 1:33 PM,   wrote:
> You are probably proxying with mod_proxy_wstunnel. It seems to me that 
> "Upgrade: WebSocket" is hard-coded in that module.
>
> Regards,
>
> Rainer

Hi Rainer,

Thanks. Yes, I am using mod_proxy_wstunnel and it appears that that is
the issue.

~Mark

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] proxy_fcgi - force flush to client

[Luca Toscano]

2018-02-02 12:20 GMT+01:00 Hajo Locke :

>
>
> Am 02.02.2018 um 07:05 schrieb Luca Toscano:
>
> Hello Hajo,
>
> 2018-02-01 13:20 GMT+01:00 Hajo Locke :
>
>> Hello Luca,
>>
>> Am 01.02.2018 um 09:10 schrieb Hajo Locke:
>>
>> Hello Luca,
>>
>> Am 01.02.2018 um 04:46 schrieb Luca Toscano:
>>
>> Hi Hajo,
>>
>> 2018-01-31 1:27 GMT-08:00 Hajo Locke :
>>
>>> Hello List,
>>>
>>> currently i compare features and behaviour of proxy_fcgi to classical
>>> methods like mod_fastcgi/mod_php.
>>>
>>> mod_php/fastcgi have options to send every output from backend
>>> immediately to client. So it is possible to see progressing output in
>>> browser and not complete websiteoutput at once.
>>>
>>> Here is an example script:
>>> https://pastebin.com/4drpgBMq
>>>
>>> if you ran this with php-cli or adjusted mod_php/mod_fastcgi you see
>>> progress in browser and numbers 0 1 2 appear one after another.
>>> If you run this with proxy_fcgi you will see no progress, but complete
>>> output at once.
>>>
>>> mod_proxy knows about worker parameter flushpackets, but the docs say
>>> this is in effect only for AJP. I can confirm that this and related options
>>> have no effect.
>>> There are some workarounds posted in the web, but only one worked for
>>> me. If i add following line to the script, i also see a progress with
>>> proxy_fcgi in browser:
>>>
>>> header('Content-Encoding: none');
>>>
>>> Somebody knows a working workaround which works without scriptediting?
>>> some workarounds tell about using "SetEnv no-gzip 1". This was not working
>>> for me and iam not please to disable content-compression.
>>> Is it planned to support >>flushpackets<< also to proxy_fcgi?
>>>
>>> May be this is not important for typical website but some
>>> service/monitoring scripts.
>>>
>>>
>> The functionality is committed to trunk but never backported to 2.4.x
>> because I was not sure about its importance, it looks like some users might
>> benefit from it :)
>>
>> The trunk patch is http://svn.apache.org/r1802040, it should apply to
>> 2.4.x if you want to test it and give me some feedback.
>>
>> Thanks!
>>
>> I tried this and it works great. I see same behaviour as expected with
>> other methods. I think some users might benefit from this. I saw some
>> discussion related to this topic and people just ended up by ungainly
>> workaround.
>> Great news!
>>
>> Unfortunately i spoke too soon. I was too euphoric when reading your
>> answer ;)
>> Behaviour is definitively more then expected, but it seems there is still
>> a minimum-limit for the buffer to flush. I suppose this limit is 4096 bytes.
>> you can comprehend this with pastebinexample above.
>> Change line 2 from "$string_length = 14096;" to "$string_length = 1331;"
>> When calling this php-file you will see no progress. All output appears
>> at once.
>> Change scriptline to "$string_length = 1332;", you will see at least 2
>> steps of output, because first step seems to break this 4096 bufferlimit.
>> increasing $string_length more and more results in more steps of output.
>> So current mod_proxy_fcgi.c from svn with configured "flushpackets=On"
>> seems to work exaktly like "flushpackets=auto iobuffersize=4096".
>> setting iobuffersize to lower numbers has no effect.
>> What do you think? Is there still a hard-coded limit or do i have a
>> problem in my configuration?
>> I would be really glad, if you could take a look at this issue.
>>
>
> I am far from being an expert in PHP, but I added "ob_flush();" right
> before "flush()" in your script and the 1331 use case seems flushing
> correctly. Do you mind to check and let me know what do you get on your
> testing environment? As far as I can see in the mod_proxy_fcgi's code the
> iobuffersize variable is taken into account..
>
> It seems that i was additional mocked by my browser. There is no need to
> edit this script, just using the right browser ;)
> I think your new mod_proxy_fcgi.c did it and my testing was incorrect. I
> think we can go into weekend..
>


Full list of commits is: svn merge -c 1802040,1807876,1808014,1805490
^/httpd/httpd/trunk .

mod_proxy_fcgi.c only patch:
http://people.apache.org/~elukey/httpd_2.4.x-mod_proxy_fcgi-force_flush.patch

If you want to give it another round of test it would be really
appreciated, in case everything is fine I'll propose it for backport to
2.4.x :)

Luca

RE: [users@httpd] SSL Certificate Validation

[Houser, Rick]

I didn’t think you could have two virtualhost entries with the same IP/port.  I 
would probably do this within with a single VirtualHost, myself.  Something 
like this combined with the RewriteRule:

RewriteCond %{HTTP_HOST} !^THE.CORRECT.HOSTNAME$


Rick Houser
Web Engineer

From: Dr James A Smith [mailto:j...@sanger.ac.uk]
Sent: Thursday, February 08, 2018 12:18
To: users@httpd.apache.org
Subject: Re: [users@httpd] SSL Certificate Validation

EXTERNAL EMAIL


The easiest way to do this is to make sure you have the correct hostname in the 
virtual host - the one that matches your certificate and another virtual host 
which has no hostname in it to catch all the other requests.


   return a forbidden response for all requests!
  RewriteEngine On
  RewriteRule ^(.*)$ - [L,F]



  ServerName your.real.host.com
  ... real config...




On 08/02/2018 16:46, Houser, Rick wrote:
In addition to fixing your certificate, you may have a reason to make sure the 
host header they send is correct.  If they are reaching you via an alternate 
hostname or something that’s getting them to the correct IP, but shouldn’t be 
supported for your service, stopping them from doing that might take aware the 
incentive they see to disabling the hostname verification in the first place.


Rick Houser
Web Engineer

From: Eric Covener [mailto:cove...@gmail.com]
Sent: Thursday, February 08, 2018 11:19
To: users@httpd.apache.org
Subject: Re: [users@httpd] SSL Certificate Validation

EXTERNAL EMAIL




On Thu, Feb 8, 2018 at 7:36 AM, Belmona, Nizar 
> wrote:
Thanks Rainer and Daniel.
Sorry for the confusion and please let me clarify.

We have a web server with Apache 2.2.22 with OpenSSL 0.9.8t, the Apache service 
launches fine and the users/developers are able to connect however developers 
through their code bypass the Server SSL certificate verification. I am not 
worried about the client certificate validation since we are not using it,  all 
the concern is we need to stop users bypassing the Server SSL verification who 
are claiming they have to bypass it since the certificate name doesn’t match 
the server name in the link being called. Kindly note that configuration in 
hhtpd.conf is:



​You can't stop them unless you control the client.  You only control the 
server. The only thing you could do is provide a better certificate.
​



-- The Wellcome Sanger Institute is operated by Genome Research Limited, a 
charity registered in England with number 1021457 and a company registered in 
England with number 2742969, whose registered office is 215 Euston Road, 
London, NW1 2BE.

Re: [users@httpd] SSL Certificate Validation

[Dr James A Smith]

The easiest way to do this is to make sure you have the correct hostname 
in the virtual host - the one that matches your certificate and another 
virtual host which has no hostname in it to catch all the other requests.



   return a forbidden response for all requests!
  RewriteEngine On
RewriteRule ^(.*)$ - [L,F]



  ServerName your.real.host.com
  ... real config...




On 08/02/2018 16:46, Houser, Rick wrote:


In addition to fixing your certificate, you may have a reason to make 
sure the host header they send is correct.  If they are reaching you 
via an alternate hostname or something that’s getting them to the 
correct IP, but shouldn’t be supported for your service, stopping them 
from doing that might take aware the incentive they see to disabling 
the hostname verification in the first place.


Rick Houser

Web Engineer

*From:* Eric Covener [mailto:cove...@gmail.com]
*Sent:* Thursday, February 08, 2018 11:19
*To:* users@httpd.apache.org
*Subject:* Re: [users@httpd] SSL Certificate Validation

*EXTERNAL EMAIL*

On Thu, Feb 8, 2018 at 7:36 AM, Belmona, Nizar > wrote:


Thanks Rainer and Daniel.

Sorry for the confusion and please let me clarify.

We have a web server with Apache 2.2.22 with OpenSSL 0.9.8t, the
Apache service launches fine and the users/developers are able to
connect however developers through their code bypass the Server
SSL certificate verification. I am not worried about the client
certificate validation since we are not using it,  all the concern
is we need to stop users bypassing the Server SSL verification who
are claiming they have to bypass it since the certificate name
doesn’t match the server name in the link being called. Kindly
note that configuration in hhtpd.conf is:

​You can't stop them unless you control the client. You only control 
the server. The only thing you could do is provide a better certificate.


​






--
The Wellcome Sanger Institute is operated by Genome Research 
Limited, a charity registered in England with number 1021457 and a 
company registered in England with number 2742969, whose registered 
office is 215 Euston Road, London, NW1 2BE. 

RE: [users@httpd] SSL Certificate Validation

[Houser, Rick]

In addition to fixing your certificate, you may have a reason to make sure the 
host header they send is correct.  If they are reaching you via an alternate 
hostname or something that’s getting them to the correct IP, but shouldn’t be 
supported for your service, stopping them from doing that might take aware the 
incentive they see to disabling the hostname verification in the first place.


Rick Houser
Web Engineer

From: Eric Covener [mailto:cove...@gmail.com]
Sent: Thursday, February 08, 2018 11:19
To: users@httpd.apache.org
Subject: Re: [users@httpd] SSL Certificate Validation

EXTERNAL EMAIL



On Thu, Feb 8, 2018 at 7:36 AM, Belmona, Nizar 
> wrote:
Thanks Rainer and Daniel.
Sorry for the confusion and please let me clarify.

We have a web server with Apache 2.2.22 with OpenSSL 0.9.8t, the Apache service 
launches fine and the users/developers are able to connect however developers 
through their code bypass the Server SSL certificate verification. I am not 
worried about the client certificate validation since we are not using it,  all 
the concern is we need to stop users bypassing the Server SSL verification who 
are claiming they have to bypass it since the certificate name doesn’t match 
the server name in the link being called. Kindly note that configuration in 
hhtpd.conf is:



​You can't stop them unless you control the client.  You only control the 
server. The only thing you could do is provide a better certificate.
​

Re: [users@httpd] websocket header not passing a long with ProxyPass and mod_headers

[Jens-U. Mozdzen]

Hi Rainer, hi Mark,

Zitat von Rainer Jung :

Hi Mark,

Am 08.02.2018 um 16:49 schrieb Mark Nenadov:
Hello, I have an operational setup where Apache httpd is proxying  
secure websockets traffic to an Apache Tomcat server. In other  
words, I'm using ProxyPass to pass traffic along to a WSS url.


I'm now having some issues trying to throw mod_headers into the  
mix. I'm attempting to manipulate the "Upgrade" header like so in  
my Apache httpd Virtual Host:


< LocationMatch "/somewhere" >
  RequestHeader set Upgrade websocket
  ProxyPass wss://192.168.1.77/some_url_on_tomcat  


< / LocationMatch >

So, supposing the client sends something funky for Upgrade like  
"WebSocket" (as an older version of a certain websocket library  
does), this RequestHeader directive should, by my understanding,  
replace it with "websocket".


However, when I place %{Upgrade}i in both my Apache httpd and  
Apache Tomcat access logs, I'm finding that the modified Upgrade  
header appears only in my httpd access logs, Tomcat says it is  
getting the original unmodified value!


This is rather perplexing to me as my understanding is that  
RequestHeader should permanently alter that request header. The  
Tomcat setup I have is very straightforward and there should be no  
surprises there.


I've tried changing my RequestHeader usage to do an unset and add  
I've also tried adding the "early" directive to the end of  
RequestHeader, but that does not alter the behavior.


It sure seems like the problem is with how Apache httpd is passing  
things along somehow, but my research hasn't come up with an answer  
that explains it or offers a resolution. Am I missing something here?


Versions: Apache httpd 2.4.18 / Apache Tomcat 8.5.24


You are probably proxying with mod_proxy_wstunnel. It seems to me  
that "Upgrade: WebSocket" is hard-coded in that module.


according to the docs, you can actually specify the protocol:

https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html :

"In fact the module can be used to upgrade to other protocols, you can  
set the upgrade parameter in the ProxyPass directive to allow the  
module to accept other protocol."


From https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypass :

"Parameter "upgrade", default "WebSocket": Protocol accepted in the  
Upgrade header by mod_proxy_wstunnel. See the documentation of this  
module for more details."


So maybe setting "upgrade=websocket" as a ProxyPass parameter might  
already achieve what Mark is looking for?


Regards
Jens


-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] websocket header not passing a long with ProxyPass and mod_headers

[Rainer Jung]

Hi Mark,

Am 08.02.2018 um 16:49 schrieb Mark Nenadov:
Hello, I have an operational setup where Apache httpd is proxying secure 
websockets traffic to an Apache Tomcat server. In other words, I'm using 
ProxyPass to pass traffic along to a WSS url.


I'm now having some issues trying to throw mod_headers into the mix. I'm 
attempting to manipulate the "Upgrade" header like so in my Apache httpd 
Virtual Host:


< LocationMatch "/somewhere" >
   RequestHeader set Upgrade websocket
   ProxyPass wss://192.168.1.77/some_url_on_tomcat 


< / LocationMatch >

So, supposing the client sends something funky for Upgrade like 
"WebSocket" (as an older version of a certain websocket library does), 
this RequestHeader directive should, by my understanding, replace it 
with "websocket".


However, when I place %{Upgrade}i in both my Apache httpd and Apache 
Tomcat access logs, I'm finding that the modified Upgrade header appears 
only in my httpd access logs, Tomcat says it is getting the original 
unmodified value!


This is rather perplexing to me as my understanding is that 
RequestHeader should permanently alter that request header. The Tomcat 
setup I have is very straightforward and there should be no surprises there.


I've tried changing my RequestHeader usage to do an unset and add I've 
also tried adding the "early" directive to the end of RequestHeader, but 
that does not alter the behavior.


It sure seems like the problem is with how Apache httpd is passing 
things along somehow, but my research hasn't come up with an answer that 
explains it or offers a resolution. Am I missing something here?


Versions: Apache httpd 2.4.18 / Apache Tomcat 8.5.24


You are probably proxying with mod_proxy_wstunnel. It seems to me that 
"Upgrade: WebSocket" is hard-coded in that module.


Regards,

Rainer


-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] SSL Certificate Validation

[Eric Covener]

On Thu, Feb 8, 2018 at 7:36 AM, Belmona, Nizar 
wrote:

> Thanks Rainer and Daniel.
>
> Sorry for the confusion and please let me clarify.
>
>
>
> We have a web server with Apache 2.2.22 with OpenSSL 0.9.8t, the Apache
> service launches fine and the users/developers are able to connect however
> developers through their code bypass the Server SSL certificate
> verification. I am not worried about the client certificate validation
> since we are not using it,  all the concern is we need to stop users
> bypassing the Server SSL verification who are claiming they have to bypass
> it since the certificate name doesn’t match the server name in the link
> being called. Kindly note that configuration in hhtpd.conf is:
>



​You can't stop them unless you control the client.  You only control the
server. The only thing you could do is provide a better certificate.
​

[users@httpd] websocket header not passing a long with ProxyPass and mod_headers

[Mark Nenadov]

Hello, I have an operational setup where Apache httpd is proxying secure
websockets traffic to an Apache Tomcat server. In other words, I'm using
ProxyPass to pass traffic along to a WSS url.

I'm now having some issues trying to throw mod_headers into the mix. I'm
attempting to manipulate the "Upgrade" header like so in my Apache httpd
Virtual Host:

< LocationMatch "/somewhere" >
  RequestHeader set Upgrade websocket
  ProxyPass wss://192.168.1.77/some_url_on_tomcat
< / LocationMatch >

So, supposing the client sends something funky for Upgrade like "WebSocket"
(as an older version of a certain websocket library does), this
RequestHeader directive should, by my understanding, replace it with
"websocket".

However, when I place %{Upgrade}i in both my Apache httpd and Apache Tomcat
access logs, I'm finding that the modified Upgrade header appears only in
my httpd access logs, Tomcat says it is getting the original unmodified
value!

This is rather perplexing to me as my understanding is that RequestHeader
should permanently alter that request header. The Tomcat setup I have is
very straightforward and there should be no surprises there.

I've tried changing my RequestHeader usage to do an unset and add I've also
tried adding the "early" directive to the end of RequestHeader, but that
does not alter the behavior.

It sure seems like the problem is with how Apache httpd is passing things
along somehow, but my research hasn't come up with an answer that explains
it or offers a resolution. Am I missing something here?

Versions: Apache httpd 2.4.18 / Apache Tomcat 8.5.24

Many thanks,
~Mark

RE: [users@httpd] SSL Certificate Validation

[Belmona, Nizar]

Thanks Rainer and Daniel.
Sorry for the confusion and please let me clarify.

We have a web server with Apache 2.2.22 with OpenSSL 0.9.8t, the Apache service 
launches fine and the users/developers are able to connect however developers 
through their code bypass the Server SSL certificate verification. I am not 
worried about the client certificate validation since we are not using it,  all 
the concern is we need to stop users bypassing the Server SSL verification who 
are claiming they have to bypass it since the certificate name doesn’t match 
the server name in the link being called. Kindly note that configuration in 
hhtpd.conf is:


DocumentRoot "C:/Program Files (x86)/Apache Software 
Foundation/Apache2.2/htdocs"
ServerName xxx.xxx.com
SSLEngine On
SSLCertificateFile "C:\Program Files (x86)\Apache Software 
Foundation\Apache2.2\conf\A.crt"
SSLCertificateKeyFile "C:\Program Files (x86)\Apache Software 
Foundation\Apache2.2\conf\B.pem"
SSLCertificateChainFile "C:\Program Files (x86)\Apache Software 
Foundation\Apache2.2\conf\C.crt"


Regards,


From: Daniel [mailto:dferra...@gmail.com]
Sent: Thursday, February 8, 2018 12:38 PM
To:  
Subject: Re: [users@httpd] SSL Certificate Validation

Hello Nizar,

You need to provide much more info on your current setup so we can provide any 
meaningful advice. Which SSL verification? What configuration?

Regarding httpd what's needed in config, the basic thing to have 
"SSLVerifyClient require" and a list of accepted CA's but that could be 
overriden in config, that's why you need to show your actual setup or more 
relevant info.
As an added note, if you have real concerns regarding security one of the best 
things to do is probably to consider upgrading your openssl version which seems 
ancient.

2018-02-08 7:16 GMT+01:00 Belmona, Nizar 
>:
Dear users,
We are currently using Apache 2.2.22 (mod_ssl 2.2.22, OpenSSL/0.9.8t) and we 
have a security concern since developers are able to bypass the SSL certificate 
verification when using HTTPS calls. Kindly advise what configuration is needed 
to enforce the certificate verification? In other words should anyone tries to 
bypass this verification, the call fails returning some kind of error code.
Please note that our environment is a simple one; it consists of one web server 
with no proxies.

Your help is greatly appreciated.

Regards,

Nizar Belmona



Deputy Section Head






Card Management System Department | CSCBank SAL

[cid:image001.jpg@01D3A0E6.AAB50A70]

t +961 1 742555 | ext. 1647 | f +961 1 
352281

e nbelm...@cscgroup.com | w 
www.cscgroup.com

150 Commodore Street, Hamra | Beirut, 1103 2120, Lebanon


[cid:image002.jpg@01D3A0E6.AAB50A70]


[cid:image003.jpg@01D3A0E6.AAB50A70] Save a tree. Please consider the 
environment before printing this email.





--
Daniel Ferradal
IT Specialist

email dferradal at gmail.com
linkedin 
es.linkedin.com/in/danielferradal


Nizar Belmona
Deputy Section Head

Card Management System Department | CSCBank SAL 
[cid:image9d3542.JPG@1f7b3054.42986040]
t +961 1 742555 | ext. 1647 | f +961 1 352281
e nbelm...@cscgroup.com | w www.cscgroup.com
150 Commodore Street, Hamra | Beirut, 1103 2120, Lebanon

[cid:imagee0a400.JPG@aa7f5c22.4bb91fb7]

[cid:imaged2f457.JPG@1c44af97.4481dc3c] Save a tree. Please consider the 
environment before printing this email.

Re: [users@httpd] SSL Certificate Validation

[Daniel]

Hello Nizar,

You need to provide much more info on your current setup so we can provide
any meaningful advice. Which SSL verification? What configuration?

Regarding httpd what's needed in config, the basic thing to have
"SSLVerifyClient require" and a list of accepted CA's but that could be
overriden in config, that's why you need to show your actual setup or more
relevant info.
As an added note, if you have real concerns regarding security one of the
best things to do is probably to consider upgrading your openssl version
which seems ancient.

2018-02-08 7:16 GMT+01:00 Belmona, Nizar :

> Dear users,
>
> We are currently using Apache 2.2.22 (mod_ssl 2.2.22, OpenSSL/0.9.8t) and
> we have a security concern since developers are able to bypass the SSL
> certificate verification when using HTTPS calls. Kindly advise what
> configuration is needed to enforce the certificate verification? In other
> words should anyone tries to bypass this verification, the call fails
> returning some kind of error code.
>
> Please note that our environment is a simple one; it consists of one web
> server with no proxies.
>
>
>
> Your help is greatly appreciated.
>
>
>
> Regards,
>
>
> Nizar Belmona
> Deputy Section Head
> Card Management System Department *|* CSCBank SAL
> *t* +961 1 742555 <+961%201%20742%20555> | *ext.* 1647 |* f* +961 1 352281
> <+961%201%20352%20281>
> *e* nbelm...@cscgroup.com | *w* www.cscgroup.com
> 150 Commodore Street, Hamra | Beirut, 1103 2120, Lebanon
>  Save a tree. Please consider the environment before printing this email.
>
>


-- 
*Daniel Ferradal*
IT Specialist

email dferradal at gmail.com
linkedin es.linkedin.com/in/danielferradal

Re: [users@httpd] symbol SSLv2_client_method

[Rainer Jung]

Am 07.02.2018 um 11:03 schrieb Stefan Eissing:

Your openssl is not the version that your apache was compiled
against. If you updated it, you need to also re-compile
any executables that link it.

Note that running SSL without staying on current software
versions is highly discouraged. For example, Apache does
not support versions 2.0 or 2.2 any longer.


In addition it is also possible that you ran into a temporary 
incompatibility in OpenSSL 1.0.2g and 1.0.1s. The symbol 
SSLv2_client_method was accidentally removed when sslv2 support was 
removed. To stay API compatible, it should have been replaced by a dummy 
impl that simply returns NULL.


This was corrected in 1.0.2h and 1.0.1t, so if are using the buggy 
versions, any minor patch update should be fine.


The simple commits were:

https://github.com/openssl/openssl/commit/133138569f37d149ed1d7641fe8c75a93fded445

(for 1.0.2) and

https://github.com/openssl/openssl/commit/5bac9d44e712bc4acfbdd156244fca4486285ec9

(for 1.0.1).

Regards,

Rainer


Am 07.02.2018 um 10:44 schrieb Pietro Pesce :

hello

i have a solaris zone whit apache:

# /app/apache/bin/httpd -version
Server version: Apache/2.0.59
Server built:   Jun 18 2007 14:27:08

when a try to start receive this error:

yntax error on line 32 of /app/apache/conf/httpd.conf:
Cannot load /app/apache/modules/mod_ssl.so into server: ld.so.1: httpd: fatal: 
relocation error: file /app/apache/modules/mod_ssl.so: symbol 
SSLv2_client_method: referenced symbol not found

# ldd /app/apache/modules/mod_ssl.so
 libc.so.1 => /lib/libc.so.1
 libgcc_s.so.1 => /usr/sfw/lib/libgcc_s.so.1
 libm.so.2 => /lib/libm.so.2
 /lib/libm/libm_hwcap1.so.2
 /platform/sun4v/lib/libc_psr.so.1

ldd /lib/libc.so.1
 libm.so.2 => /lib/libm.so.2
 /lib/libm/libm_hwcap1.so.2
 /platform/sun4v/lib/libc_psr.so.1


can help please?

tnx



-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org




--
kippdata
informationstechnologie GmbH   Tel: 0228 98549 -0
Bornheimer Str. 33aFax: 0228 98549 -50
53111 Bonn www.kippdata.de

HRB 8018 Amtsgericht Bonn / USt.-IdNr. DE 196 457 417
Geschäftsführer: Dr. Thomas Höfer, Rainer Jung, Sven Maurmann

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org