Re: [VOTE] Release httpd-2.4.37
No issues seen/reported Httpd 36/37 introduced the following build warnings: modules\ssl\ssl_engine_init.c(926): warning C4003: not enough arguments for function-like macro invocation 'APLOGNO' modules\ssl\ssl_engine_kernel.c(1128): warning C4003: not enough arguments for function-like macro invocation 'APLOGNO' modules\ssl\ssl_engine_kernel.c(1147): warning C4003: not enough arguments for function-like macro invocation 'APLOGNO' For you info warnings mod_ssl: All warnings Win32: ..win32\httpd-2.4\modules\ssl\ssl_engine_init.c(926): warning C4003: not enough arguments for function-like macro invocation 'APLOGNO' ..win32\httpd-2.4\modules\ssl\ssl_engine_kernel.c(1128): warning C4003: not enough arguments for function-like macro invocation 'APLOGNO' ..win32\httpd-2.4\modules\ssl\ssl_engine_kernel.c(1147): warning C4003: not enough arguments for function-like macro invocation 'APLOGNO' ..win32\httpd-2.4\modules\ssl\ssl_engine_kernel.c(2605): warning C4018: '<': signed/unsigned mismatch All warnings Win64 ..win64\httpd-2.4\modules\ssl\ssl_engine_config.c(551): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data ..win64\httpd-2.4\modules\ssl\ssl_engine_config.c(639): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data ..win64\httpd-2.4\modules\ssl\ssl_engine_init.c(258): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data ..win64\httpd-2.4\modules\ssl\ssl_engine_init.c(926): warning C4003: not enough arguments for function-like macro invocation 'APLOGNO' ..win64\httpd-2.4\modules\ssl\ssl_engine_io.c(624): warning C4267: 'function': conversion from 'size_t' to 'int', possible loss of data ..win64\httpd-2.4\modules\ssl\ssl_engine_io.c(630): warning C4267: '+=': conversion from 'size_t' to 'int', possible loss of data ..win64\httpd-2.4\modules\ssl\ssl_engine_io.c(673): warning C4267: 'function': conversion from 'size_t' to 'int', possible loss of data ..win64\httpd-2.4\modules\ssl\ssl_engine_io.c(807): warning C4267: 'function': conversion from 'size_t' to 'int', possible loss of data ..win64\httpd-2.4\modules\ssl\ssl_engine_io.c(829): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data ..win64\httpd-2.4\modules\ssl\ssl_engine_io.c(859): warning C4267: 'function': conversion from 'size_t' to 'int', possible loss of data ..win64\httpd-2.4\modules\ssl\ssl_engine_io.c(1216): warning C4244: 'function': conversion from '__int64' to 'unsigned int', possible loss of data ..win64\httpd-2.4\modules\ssl\ssl_engine_io.c(1542): warning C4018: '<': signed/unsigned mismatch ..win64\httpd-2.4\modules\ssl\ssl_engine_io.c(1560): warning C4267: '-=': conversion from 'size_t' to 'int', possible loss of data ..win64\httpd-2.4\modules\ssl\ssl_engine_io.c(1904): warning C4018: '>': signed/unsigned mismatch ..win64\httpd-2.4\modules\ssl\ssl_engine_kernel.c(1128): warning C4003: not enough arguments for function-like macro invocation 'APLOGNO' ..win64\httpd-2.4\modules\ssl\ssl_engine_kernel.c(1147): warning C4003: not enough arguments for function-like macro invocation 'APLOGNO' ..win64\httpd-2.4\modules\ssl\ssl_engine_kernel.c(2605): warning C4018: '<': signed/unsigned mismatch ..win64\httpd-2.4\modules\ssl\ssl_engine_log.c(128): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data ..win64\httpd-2.4\modules\ssl\ssl_engine_pphrase.c(478): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data ..win64\httpd-2.4\modules\ssl\ssl_engine_pphrase.c(570): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data ..win64\httpd-2.4\modules\ssl\ssl_engine_pphrase.c(609): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data ..win64\httpd-2.4\modules\ssl\ssl_engine_rand.c(154): warning C4267: 'function': conversion from 'size_t' to 'int', possible loss of data ..win64\httpd-2.4\modules\ssl\ssl_engine_rand.c(162): warning C4267: 'return': conversion from 'size_t' to 'int', possible loss of data ..win64\httpd-2.4\modules\ssl\ssl_engine_vars.c(668): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data ..win64\httpd-2.4\modules\ssl\ssl_util_ssl.c(141): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data On Thursday 18/10/2018 at 16:36, Daniel Ruggeri wrote: Hi, all; Please find below the proposed release tarball and signatures: https://dist.apache.org/repos/dist/dev/httpd/ I would like to call a VOTE over the next few days to release this candidate tarball as 2.4.37: [ ] +1: It's not just good, it's good enough! [ ] +0: Let's have a talk. [ ] -1: There's trouble in paradise. Here's what's wrong. The computed digests of the tarball up for vote are: sha1: b0521606d1df54bb425adcdecf6348f126aa352c *httpd-2.4.37.tar.gz sha256: aa97a834a32d51974be8d8a013b561e28d327387cb1da2c3c2762acd0146aabd *httpd-2.4.37.tar.gz -- Daniel Ruggeri
Re: NOTICE: Intent to T&R 2.4.35 in the next few hours
Are there examples what (maybe) does not work with OpenSSL 1.1.1 ? Build 2.4.35 with OpenSSL 1.1.1, no issues seen/reported. More then A week ago I ask already the community to test 2.4.34 with OpenSSL 1.1.1 also no issue reported. Plan to ship 2.4.35 with OpenSSL1.1.1 With our announcement I put the note: Apache 2.4.35 does not support yet TLSv1.3, expected in 2.4.36 release.. Note: openssl.org says that the new 1.1.1 is binary and API/ABI compatible with OpenSSL 1.1.0. I can confirm that sofar and also windows PHP-guys. On Wednesday 19/09/2018 at 12:54, Joe Orton wrote: On Tue, Sep 18, 2018 at 11:19:10AM -0500, William A Rowe Jr wrote: On Tue, Sep 18, 2018 at 2:43 AM Joe Orton wrote: You'll likely see issues testing against OpenSSL 1.1.1 until the TLSv1.3 merge is integrated for 2.4.x, yeah, I wouldn't worry about that. But I think this is worth highlighting in our Announcement, that we would strongly caution users to build 2.4.35 against OpenSSL 1.1.0. (And we could tease the forthcoming 2.4 release as building against 1.1.1/TLS 1.3.) Good idea. How about this, to insert after the "This release requires the Apache Portable Runtime (APR)," paragraph? """ This release is compatible with OpenSSL versions from 0.9.8a to 1.1.0 only, and does not support TLSv1.3. Future releases of httpd 2.4 are expected to add compatibility with OpenSSL 1.1.1 and enable support for TLSv1.3. """ Regards, Joe
Win run success tls 1.3 with Chrome
Maybe someone is interested. With initial testing: Chrome 68 with tls 1.3 draft 28 (setting in chrome://flags) OpenSSL version 1.1.1-pre8 httpd-trunk revision 1836684 Chrome Output: Connection - secure (strong TLS 1.3) The connection to this site is encrypted and authenticated using TLS 1.3 (a strong protocol), X25519 (a strong key exchange), and AES_256_GCM (a strong cipher). httpd config: SSLHonorCipherOrder On SSLProtocol -all +TLSv1.3 SSLCompression off SSLSessionTickets off (no SSLCipherSuite defined) Access log : localhost:443 HTTP/2.0 ::1 - - [27/Jul/2018:12:58:21 +0200] TLSv1.3 TLS_AES_256_GCM_SHA384 "GET /index.html HTTP/2.0" 200 320 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.75 Safari/537.36" Sincerely, AL
Win build success httpd-trunk
Build succeeded! Build Output: 143 succeeded, 0 failed, 0 up-to-date, 0 skipped Build Source Stamp: httpd-trunk revision 1836684 Build With: vcxproj Visual Studio Professional 2017 15.7.5 Build Reason: request in httpd dev email thread "re: Current trunk win build error" Build with dependencies: openssl 1.1.0h nghttp2 1.32.0 jansson 2.11 curl 7.61.0 apr 1.6.3 apr-util 1.6.1 apr-iconv 1.2.2 zlib 1.2.11 brotli 1.0.5 pcre 8.42 libxml2 2.9.8 lua 5.2.4 expat 2.2.5 Passes initial tests trunk modules, including: mod_log_json mod_socache_redis session_crypto with openssl mod_apreq Passes initial tests third party modules: mod_bmx mod_bw mod_log_rotate mod_view mod_watch mod_xsendfile mod_vhost_dbd mod_log_dbd mod_caucho mod_evasive mod_security mod_jk mod_fcgid Sincerely, AL
Current trunk win build error
Error C2440 'initializing': cannot convert from 'proxy_worker *(__stdcall *)(proxy_balancer *,request_rec *,proxy_is_best_callback_fn_t (__cdecl *),void *)' to 'apr_OFN_ap_proxy_balancer_get_best_worker_t (__cdecl *)' mod_proxy c:\vc15\win32\httpd-trunk\modules\proxy\proxy_util.c 4082
Apache httpd 2.4.34-dev Win snapshot available.
see www.apachelounge.com/viewtopic.php?p=36981
Re: TLS 1.3 seems to OVERwork with httpd-trunk rev 1833619
Same behavior "read R BLOCK" twice on Windows with trunk from today
(1833659):
On Friday 15/06/2018 at 22:03, Dennis Clarke wrote:
Thank you Yann Ylavic !
Sure enough no patch was needed and trunk compiles up neatly and just
a
bit noisey about a few odd warnings ... nothing too interesting.
So then ... as I reported earlier I can get reasonable handshake and
TLSv1.3 traffic with cipher TLS_AES_128_GCM_SHA256 from the Mozilla
test site. Claims to be Draft 28 of TLS 1.3.
I can now do the exact same with httpd-trunk rev 1833619 and there is
no
need to specify "-tls1_3" because nothing else is supported. However
we
get a double bounce ( for lack of a better work ) in the transitory
SSL_connect:SSL negotiation finished successfully state of the
exchange:
$ openssl s_client -connect beta.tls13.net:443
CONNECTED(0004)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = *.tls13.net
verify return:1
---
Certificate chain
0 s:CN = *.tls13.net
i:C = US, O = Let's Encrypt, CN = Let's Encrypt
Authority X3
1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate
-BEGIN CERTIFICATE-
MIIGAjCCBOqgAwIBAgISA3lbcjYuS0tUnszwWevJIyQaMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
...
...
...
ySsGXKitxY8HofArokYLygbwFVe3A1H4cyWwLQk+vHXDyYJWqh78UFhXS2A6kjwg
1vNRzOHTLCQfYIoWw8CePPeKTbxc7sr3zRBhNCYN/5rhzniBymc72wDcPOXpXSB3
PrK8bh7S
-END CERTIFICATE-
subject=CN = *.tls13.net
issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3281 bytes and written 400 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
SSL-Session:
Protocol : TLSv1.3
Cipher: TLS_AES_256_GCM_SHA384
Session-ID:
Session-ID-ctx:
Master-Key:
5AABE86A1DE9EA6F2EA88AC980C27DAFFC643B13B3A99D63E24BE7A848C71FBCFBDC8EEDFE93EEF1B7D1AFFA38CFDB27
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1529092107
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
---
read R BLOCK
read R BLOCK
GET
HTTP/1.1 400 Bad Request
Date: Fri, 15 Jun 2018 19:48:46 GMT
Server: Apache/2.5.1-dev (Unix) OpenSSL/1.1.1-pre7
Strict-Transport-Security: max-age=7776000; includeSubdomains;
Last-Modified: Mon, 28 May 2018 19:03:30 GMT
ETag: "2b0-56d48c600191c"
Accept-Ranges: bytes
Content-Length: 688
Connection: close
Content-Type: text/html
"http://www.w3.org/TR/html4/strict.dtd"; >
content="max-age=0, must-revalidate">
error code 400 bad request
error code 400 bad request ... that is all for now
closed
$
So that looks great and the ssl_error_log claims all is happy.
Seems to issue "read R BLOCK" twice for some odd reason.
A closer look with "-state -debug" reveals that we get multiple
"SSL_connect:SSL negotiation finished successfully" before ever
accepting a GET/POST/FOO from the client.
...
...
...
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
SSL-Session:
Protocol : TLSv1.3
Cipher: TLS_AES_256_GCM_SHA384
Session-ID:
Session-ID-ctx:
Master-Key:
7B8968F4FAC7878EDD51482F852CDFB38D95C8D27A8B9B9C6038F031387F34A61EF8DF239B8B38FC4163A2987453E90F
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1529092424
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
---
read from 0x100851cd0 [0x100857983] (5 bytes => 5 (0x5))
- 17 03 03 01 23#
read from 0x100851cd0 [0x100857988] (291 bytes => 291 (0x123))
- 90 61 65 22 28 de ed 16-48 01 c4 c9 24 c4 95 c3
.ae"(...H...$...
...
...
...
0110 - 02 57 51 bc d7 0d 2c 64-a3 9d db 21 cc 2e 7b 1c
.WQ...,d...!..{.
0120 - a8 a7 ba
Re: [VOTE] Release Apache httpd 2.4.11 as GA
No issues seen on Windows, good to go. apr-1.5.1 apr-util-1.5.4 apr-iconv-1.2.1 openssl-1.0.1l zlib-1.2.8 pcre-8.36 libxml2-2.9.2 lua-5.1.5 expat-2.1.0 Steffen -Original Message- From: Jim Jagielski Sent: Thursday, January 15, 2015 9:10 PM Newsgroups: gmane.comp.apache.devel To: httpd Subject: [VOTE] Release Apache httpd 2.4.11 as GA The pre-release test tarballs for Apache httpd 2.4.11 can be found at the usual place: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as Apache httpd 2.4.11 GA. [ ] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. Vote will last the normal 72 hrs. NOTE: The *-deps are only there for convenience. Thx!
Re: [VOTE] Release Apache httpd 2.4.10 as GA
Good to go Windows flavors at AL. -Original Message- From: Jim Jagielski Sent: Tuesday, July 15, 2014 7:20 PM Newsgroups: gmane.comp.apache.devel To: httpd Subject: [VOTE] Release Apache httpd 2.4.10 as GA The pre-release test tarballs for Apache httpd 2.4.10 can be found at the usual place: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as Apache httpd 2.4.10 GA. [ ] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. Vote will last the normal 72 hrs. NOTE: The *-deps are only there for convenience.
Re: Rethinking "be liberal in what you accept"
What about mod_security, has a lot of similar checks and even more. -Original Message- From: Stefan Fritsch Sent: Wednesday, November 7, 2012 12:26 Newsgroups: gmane.comp.apache.devel To: dev@httpd.apache.org Subject: Rethinking "be liberal in what you accept" Hi, considering the current state of web security, the old principle of "be liberal in what you accept" seems increasingly inadequate for web servers. It causes lots of issues like response splitting, header injection, cross site scripting, etc. The book "Tangled Web" by Michal Zalewski is a good read on this topic, the chapter on HTTP is available for free download at http://nostarch.com/tangledweb . Also, nowadays performance bottle necks are usually in other places than request parsing. A few more cycles spent for additional checks won't make much difference. Therefore, I think it would make sense to integrate some sanity checks right into the httpd core. For a start, these would need to be enabled in the configuration. Examples for such checks [RFC 2616 sections in brackets]: Request line: - Don't interpret all kinds of junk as "HTTP/1.0" (like "HTTP/ab" or "FOO") [3.1] - If a method is not registered, bail out early. This would prevent CGIs from answering requests to strange methods like "HELO" or "http://foo/bar";. This must be configurable or there must be at least a directive to easily register custom methods. Otherwise, at least forbid strange characters in the method. [The method is a token, which should not contain control characters and separators; 2.2, 5.1] - Forbid control characters in URL - Forbid fragment parts in the URL (i.e. "#..." which should never be sent by the browser) - Forbid special characters in the scheme part of absoluteURL requests, e.g. "<>" Request headers: - In Host header, only allow reasonable characters, i.e. no control characters, no "<>&". Maybe: only allow ascii letters, digits, and "-_.:[]" - Maybe replace the Host header with the request's hostname, if they are different. In: GET http://foo/ HTTP/1.1 Host: bar The "Host: bar" MUST be ignored by RFC 2616 [5.2]. As many webapps likely don't do that, we could replace the Host header to avoid any confusion. - Don't accept requests with multiple Content-Length headers. [4.2] - Don't accept control characters in header values (in particular single CRs, which we don't treat specially, but other proxies may. [4.2] Response headers: - Maybe error out if an output header value or name contains CR/LF/NUL (or all control characters?) [4.2] - Check that some headers appear only once, e.g. Content-Length. - Potentially check in some headers (e.g. Content-Disposition) that key=value pairs appear only once (this may go too far / or be too expensive). Other: - Maybe forbid control characters in username + password (after base64 decoding) As a related issue, it should be possible to disable HTTP 0.9. The dividing line to modules like mod_security should be that we only check things that are forbidden by some standard and that we only look at the protocol and not the body. Also, I would only allow to switch the checks on and off, no further configurability. And the checks should be implemented efficiently, i.e. don't parse things several times to do the checks, normally don't use regexes, etc. What do you think? Cheers, Stefan
Re: Fix for Windows bug#52476
Also here it is running now without issues till now here with
AcceptFilter-none+SSL
Steffen
-Original Message-
From: Jeff Trawick
Sent: Friday, August 10, 2012 7:43 PM Newsgroups: gmane.comp.apache.devel
To: dev@httpd.apache.org
Subject: Re: Fix for Windows bug#52476
This patch is testing great so far with the AcceptFilter-none+SSL
scenario on Windows.
Index: server/core_filters.c
===
--- server/core_filters.c (revision 1371377)
+++ server/core_filters.c (working copy)
@@ -391,10 +391,6 @@
if (ctx == NULL) {
ctx = apr_pcalloc(c->pool, sizeof(*ctx));
net->out_ctx = (core_output_filter_ctx_t *)ctx;
-rv = apr_socket_opt_set(net->client_socket, APR_SO_NONBLOCK, 1);
-if (rv != APR_SUCCESS) {
-return rv;
-}
/*
* Need to create tmp brigade with correct lifetime. Passing
* NULL to apr_brigade_split_ex would result in a brigade
I'll run it through the test framework on Linux before committing.
