[users@httpd] Peer digest using sha1 on TLS connection - Chrome fails

[Craig H Silva (Cenitex)]

This is probably not the most appropriate mail list to ask this question.

Basically we have apache 2.4.3 on a solaris 10 host running openssl  1.0.2zf.

This was OK up until the 117 release of Chrome, which now rejects sha1.

Funny thing is that one vhost with the same ssl config is ok, whilst one vhost 
is failing. From all that I can tell, the only difference is the certificates - 
the CA cert is different.

I'm the unix admin (typically I don't do the httpd config - that's our 
customer), but the customer wants to make it our issue. Of course this is the 
customer that has resisted upgrading the OS.


There is one available patch for openssl from Oracle (151912-22 - openssl 
1.02.zf) but I can't get any info at this point on whether that might address 
the issue.


Its only Chrome that is failing at the moment, but interested on any thoughts, 
ideas from this list as to whether there is any work around that could be 
attempted.



[cid:6aa97331-adba-4ef9-a852-8a3d241df9a0]



 [cid:8384bf39-db74-4432-90ae-4333642b6464] 
  
[cid:58fc99ef-bfac-4b14-86c8-a2f6c5334a63]   
[cid:00d8edea-a344-475b-b0dd-06f9f2aeedb1] 


Craig Silva | Specialist Engineer – Unix & Storage Services

Level 18, 80 Collins Street, Melbourne 3000

(03) 9063 5126

cenitex.vic.gov.au





[cid:76723db1-425e-4452-825d-a237f76b91e8]



Cenitex acknowledges the Traditional Owners and custodians of the land and we 
pay our respects to their Elders, past, present and emerging. We are an 
inclusive workplace that embraces diversity in all its forms.




--
Notice:

This email and any attachments may contain information that is personal,
confidential, legally privileged and/or copyright. No part of it should be
reproduced, adapted or communicated without the prior written consent of the
copyright owner.

It is the responsibility of the recipient to check for and remove viruses.

If you have received this email in error, please notify the sender by return
email, delete it from your system and destroy any copies. You are not authorised
to use, communicate or rely on the information contained in this email.

Please consider the environment before printing this email.

[users@httpd] Apache dropping Content-Length header for HEAD responses where Content-Length is 0

[Piotr Dobrogost]

Hi,

Using Apache 2.4.57 on Fedora with default
configuration I'm observing that for HEAD response the Content-Length
header is not being sent for empty files (it is present for non-empty
files). When changing HEAD to GET the header is present for such
files.
Sidney Shek asked very similar question on this list in the past with
no response –
"Apache 2.2 proxy dropping content-length header for HEAD responses
where content-length is 0"
(https://lists.apache.org/thread/vlg8x9rl1ob812rhdj7zlbpgsfz7vvw4).

How I tested this:
[user@hostx ~]$ curl -I http://localhost/x.txt
HTTP/1.1 200 OK
Date: Tue, 15 Mar 2022 22:37:56 GMT
Server: Apache/2.4.52 (Fedora Linux)
Last-Modified: Tue, 15 Mar 2022 22:35:21 GMT
ETag: "0-5da4969829e4e"
Accept-Ranges: bytes
Content-Type: text/plain; charset=UTF-8

[user@hostx ~]$ curl -v http://localhost/x.txt
*   Trying 127.0.0.1:80...
* Connected to localhost (127.0.0.1) port 80 (#0)
> GET /x.txt HTTP/1.1
> Host: localhost
> User-Agent: curl/7.79.1
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Tue, 15 Mar 2022 22:38:00 GMT
< Server: Apache/2.4.52 (Fedora Linux)
< Last-Modified: Tue, 15 Mar 2022 22:35:21 GMT
< ETag: "0-5da4969829e4e"
< Accept-Ranges: bytes
< Content-Length: 0
< Content-Type: text/plain; charset=UTF-8
<
* Connection #0 to host localhost left intact

How to configure Apache so that Content-Length header would be sent in
HEAD response when requested resource has no content?

Thank you in advance.

Regards,
Piotr Dobrogost

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

[users@httpd] Logging issue piped logs vs file

[Pedro Coelho Silva]

Hello

I think I have discovered a bug, where using a log file vs using a pipe
command will not log the exact same messages.

System:
Server version: Apache/2.4.56 (Unix)
Server built:   Jul 10 2023 10:58:41
root@ns-pedros# uname -a
FreeBSD ns-pedros 11.4-NETSCALER-13.1 FreeBSD 11.4-NETSCALER-13.1 #0
a7c4dc80d(rs_131_49_4_RTM): Mon Jul 10 12:01:16 PDT 2023
root@sjc-bld-bsd114-232:/usr/obj/usr/home/build/adc/usr.src/sys/NS64  amd64

I configure the following ErrorLog Directive as follows:
-A:ErrorLog "/var/log/httperror.log"
-B:ErrorLog "|/usr/bin/logger -t httperror -p local3.error"

I have also tried option B with |$, yielding the same result.

I have to use logger and not the "syslog:facility:tag" because I need to
control the level of the log, and this doesn't provide me with that option.

I have syslog writing to a different file, /var/log/httperror_syslog.log

If I use option A, I see the following messages after /bin/httpd -k restart
-f /etc/httpd.conf several times, in order to ensure before and after
loading the config I get the same set of messages:
[Wed Oct 11 07:54:34.505202 2023] [mpm_prefork:notice] [pid 215] AH00173:
SIGHUP received.  Attempting to restart
[Wed Oct 11 07:54:34.624822 2023] [mpm_prefork:notice] [pid 215] AH00163:
Apache/2.4.56 (Unix) mod_perl/2.0.10 Perl/v5.30.2 configured -- resuming
normal operations
[Wed Oct 11 07:54:34.625678 2023] [core:notice] [pid 215] AH00094: Command
line: '/bin/httpd -f /etc/httpd.conf'

If I use option B, after several restarts I have the following set of
messages:
Oct 11 07:55:56  ns-pedros httperror: [Wed Oct 11
07:55:56.486944 2023] [mpm_prefork:notice] [pid 215] AH00163: Apache/2.4.56
(Unix) mod_perl/2.0.10 Perl/v5.30.2 configured -- resuming normal operations
Oct 11 07:55:56  ns-pedros httperror: [Wed Oct 11
07:55:56.488838 2023] [core:notice] [pid 215] AH00094: Command line:
'/bin/httpd -f /etc/httpd.conf'


Besides the obvious new prefix from syslog, we can see that the SIGHUP
message is not sent to the piped log. I will theorize that the pipe is
closed before the SIGHUP message is sent.

I believe that this message should be sent before closing the pipe. Should
I open a bug report?

Best Regards
/P
--
--