You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2022/01/25 12:56:44 UTC
[Bug 65844] New: Expect: 100-continue changed behavior in ecebcc0
https://bz.apache.org/bugzilla/show_bug.cgi?id=65844
Bug ID: 65844
Summary: Expect: 100-continue changed behavior in ecebcc0
Product: Apache httpd-2
Version: 2.4.49
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Core
Assignee: bugs@httpd.apache.org
Reporter: pgajdos@suse.cz
Target Milestone: ---
https://github.com/apache/httpd/commit/ecebcc035ccd8d0e2984fe41420d9e944f456b3c
seem to had changed behavior for 'Expect: 100-continue'. For
https://github.com/pgajdos/apache-rex/tree/master/mod_ssl-proxy-auth
I get with 2.4.48+ecebcc0:
[1] with Expect: 100-continue
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
< Connection: close
* Closing connection 0
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* Connection #1 to host frontend.su.se left intact
[2] without Expect: 100-continue
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* Connection #0 to host frontend.su.se left intact
* Re-using existing connection! (#0) with host frontend.su.se
* Connection #0 to host frontend.su.se left intact
For 2.4.48 I get in [1] the same behavior (reusing connection) as in
[2] here. Is that intended? If I got it correctly, some site have a
problem with not maintaining keepalive connection after 401.
Details
=======
requests are made by
echo "[1] with Expect: 100-continue"
curl -v -s -H 'Expect: 100-continue' --cacert $AREX_RUN_DIR/ca/my.crt --resolve
"frontend.su.se:$AREX_PORT1:127.0.0.1" https://frontend.su.se:$AREX_PORT1/ \
--next --cacert $AREX_RUN_DIR/ca/my.crt --resolve
"frontend.su.se:$AREX_PORT1:127.0.0.1" -u john:StrongPassword
https://frontend.su.se:$AREX_PORT1/ \
2>&1 | grep -i connection
echo "[2] without Expect: 100-continue"
curl -v -s --cacert $AREX_RUN_DIR/ca/my.crt --resolve
"frontend.su.se:$AREX_PORT1:127.0.0.1" https://frontend.su.se:$AREX_PORT1/ \
--next --cacert $AREX_RUN_DIR/ca/my.crt --resolve
"frontend.su.se:$AREX_PORT1:127.0.0.1" -u john:StrongPassword
https://frontend.su.se:$AREX_PORT1/ \
2>&1 | grep -i connection
configured virtualhosts
<VirtualHost *:60081>
ServerName frontend.su.se
ErrorLog "/tmp/apache-rex/mod_ssl-proxy-auth/error_log-frontend"
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl .crl
RequestHeader unset Expect early
SSLEngine on
SSLProxyEngine on
SSLCertificateFile
/tmp/apache-rex/mod_ssl-proxy-auth/frontend.su.se/my.crt
SSLCertificateKeyFile
/tmp/apache-rex/mod_ssl-proxy-auth/frontend.su.se/private.key
SSLProtocol all
<IfVersion >= 2.3.0>
SSLCipherSuite DEFAULT
</IfVersion>
<IfVersion < 2.3.0>
SSLCipherSuite ALL
</IfVersion>
SSLHonorCipherOrder on
CustomLog /tmp/apache-rex/mod_ssl-proxy-auth/server_log-frontend
ssl_combined
SSLProxyCheckPeerName off
ProxyPass / "https://127.0.0.1:60082/"
</Virtualhost>
Listen 60082
<VirtualHost *:60082>
ServerName backend.su.se
ErrorLog "/tmp/apache-rex/mod_ssl-proxy-auth/error_log-backend"
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl .crl
SSLEngine on
SSLCertificateFile /tmp/apache-rex/mod_ssl-proxy-auth/backend.su.se/my.crt
SSLCertificateKeyFile
/tmp/apache-rex/mod_ssl-proxy-auth/backend.su.se/private.key
SSLProtocol all
<IfVersion >= 2.3.0>
SSLCipherSuite DEFAULT
</IfVersion>
<IfVersion < 2.3.0>
SSLCipherSuite ALL
</IfVersion>
SSLHonorCipherOrder on
CustomLog /tmp/apache-rex/mod_ssl-proxy-auth/server_log-backend
ssl_combined
<Directory /tmp/apache-rex/mod_ssl-proxy-auth/htdocs>
AuthType Basic
AuthBasicProvider file
AuthName "Restricted Area"
AuthUserFile /tmp/apache-rex/mod_ssl-proxy-auth/htpasswd
Require valid-user
</Directory>
</Virtualhost>
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 65844] Expect: 100-continue changed behavior in ecebcc0
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65844
--- Comment #2 from Yann Ylavic <yl...@gmail.com> ---
Also, please test with 2.4.52 (not 2.4.49).
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 65844] Expect: 100-continue changed behavior in ecebcc0
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65844
--- Comment #7 from Petr Gajdos <pg...@suse.cz> ---
(In reply to Ruediger Pluem from comment #4)
> I think we need to close the the connection in case the reverse proxy
> answers with a final response it got from the backend. See
> https://datatracker.ietf.org/doc/html/rfc7231#page-35:
>
> o A server that responds with a final status code before reading the
> entire message body SHOULD indicate in that response whether it
> intends to close the connection or continue reading and discarding
> the request message (see Section 6.6 of [RFC7230]).
>
>
> This should avoid request smuggling attacks as once we send the final
> response to the client we don't know if the next data send from the client
> is the request body for the previous request or a new request. This is
> because of
>
> o A client that sends a 100-continue expectation is not required to
> wait for any specific length of time; such a client MAY proceed to
> send the message body even if it has not yet received a response.
> Furthermore, since 100 (Continue) responses cannot be sent through
> an HTTP/1.0 intermediary, such a client SHOULD NOT wait for an
> indefinite period before sending the message body.
>
>
> at https://datatracker.ietf.org/doc/html/rfc7231#page-35.
I will need time to go trough this info, thanks for the references!
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 65844] Expect: 100-continue changed behavior in ecebcc0
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65844
--- Comment #6 from Petr Gajdos <pg...@suse.cz> ---
(In reply to Yann Ylavic from comment #2)
> Also, please test with 2.4.52 (not 2.4.49).
Yes, tested with 2.4.52.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 65844] Expect: 100-continue changed behavior in ecebcc0
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65844
--- Comment #3 from Yann Ylavic <yl...@gmail.com> ---
What might happen is that the backend responds with 401 without first sending
the "100 Continue" interim response, because the auth on the backend happens
before the request body is read (it does not need the body).
Given the final response, the frontend has to "Connection: close" with the
client because the 100-continue is now incomplete (the request body was never
read).
Adding "Proxy100Continue off" to the frontend configuration should prevent that
since the "100 continue" would be handled entirely on the frontend.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 65844] Expect: 100-continue changed behavior in ecebcc0
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65844
--- Comment #5 from Petr Gajdos <pg...@suse.cz> ---
Created attachment 38178
--> https://bz.apache.org/bugzilla/attachment.cgi?id=38178&action=edit
error_log of proxy frontend
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 65844] Expect: 100-continue changed behavior in ecebcc0
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65844
--- Comment #1 from Yann Ylavic <yl...@gmail.com> ---
Please provide the error_log of the frontend with this added to the global
configuration:
LoadModule dumpio_module modules/mod_dumpio.so
DumpIOInput on
DumpIOOutput on
LogLevel trace8
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 65844] Expect: 100-continue changed behavior in ecebcc0
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65844
Ruediger Pluem <rp...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|NEW |RESOLVED
--- Comment #4 from Ruediger Pluem <rp...@apache.org> ---
I think we need to close the the connection in case the reverse proxy answers
with a final response it got from the backend. See
https://datatracker.ietf.org/doc/html/rfc7231#page-35:
o A server that responds with a final status code before reading the
entire message body SHOULD indicate in that response whether it
intends to close the connection or continue reading and discarding
the request message (see Section 6.6 of [RFC7230]).
This should avoid request smuggling attacks as once we send the final response
to the client we don't know if the next data send from the client is the
request body for the previous request or a new request. This is because of
o A client that sends a 100-continue expectation is not required to
wait for any specific length of time; such a client MAY proceed to
send the message body even if it has not yet received a response.
Furthermore, since 100 (Continue) responses cannot be sent through
an HTTP/1.0 intermediary, such a client SHOULD NOT wait for an
indefinite period before sending the message body.
at https://datatracker.ietf.org/doc/html/rfc7231#page-35.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org