RE: [users@httpd] Urgent issue with reverse proxy
> From: Sean Hurley > Sent: Thursday, February 25, 2021 12:04 PM > To: users@httpd.apache.org > Subject: [users@httpd] Urgent issue with reverse proxy > > Greetings, > > I have an issue with a long payload not being delivered by an Apache 2.4 > reverse proxy. Did it ever work? > > Below is what I am trying to send: > AH00947: connected > /ghost/gl/api/data_option_detail?modifier=%7B%22order%22:%5B%22data_option_id%22,%22study_phase_id%22,%22data_option_detail.rank%22%5D,%22limit%22:1000%7D=%7B%22column%22:%5B%22id%22,%22data_option_id%22,%22name_en%22,%22name_fr%22,%22note_en%22,%22note_fr%22,%22study_phase_id%22,%7B%22table%22:%22study_phase%22,%22column%22:%22name%22,%22alias%22:%22study_phase%22%7D,%7B%22table%22:%22data_option%22,%22column%22:%22data_option_category_id%22%7D%5D%7D > to http://192.168.10.19:80 How short before it starts working? > > I have confirmed the request works if I by-pass the proxy. I have attempted > a number of fixes but so far, no luck. > > The browser displays: Error: Unexpected end of JSON input. Details please? > > It appears the proxy is truncating the request. Any suggestions are welcome. > > Details: Apache 2.4.18 on Ubuntu 16.04.6 > > Thank you, > Sean. - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
[users@httpd] Urgent issue with reverse proxy
Greetings, I have an issue with a long payload not being delivered by an Apache 2.4 reverse proxy. Below is what I am trying to send: AH00947: connected /ghost/gl/api/data_option_detail?modifier=%7B%22order%22:%5B%22data_option_id%22,%22study_phase_id%22,%22data_option_detail.rank%22%5D,%22limit%22:1000%7D=%7B%22column%22:%5B%22id%22,%22data_option_id%22,%22name_en%22,%22name_fr%22,%22note_en%22,%22note_fr%22,%22study_phase_id%22,%7B%22table%22:%22study_phase%22,%22column%22:%22name%22,%22alias%22:%22study_phase%22%7D,%7B%22table%22:%22data_option%22,%22column%22:%22data_option_category_id%22%7D%5D%7D to 192.168.10.19:80 I have confirmed the request works if I by-pass the proxy. I have attempted a number of fixes but so far, no luck. The browser displays: Error: Unexpected end of JSON input. It appears the proxy is truncating the request. Any suggestions are welcome. Details: Apache 2.4.18 on Ubuntu 16.04.6 Thank you, Sean.
Re: Re: [users@httpd] Set SSLCipherSuite dependent on client IP
The question is if the "If/Else" block is being evaluated. I suspect it is, but the selected CipherSuites are not available and therefore the global setting is used to negotiate. On Thu, Feb 25, 2021 at 7:50 AM Yann Ylavic wrote: > On Thu, Feb 25, 2021 at 1:44 PM Brian Wolfe > wrote: > > > > Are you sure that you have any MD5 ciphers enabled. > > Wrong thread? > > Regards; > Yann. > > - > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org > > -- Thanks, Brian Wolfe https://www.linkedin.com/in/brian-wolfe-3136425a/
Re: Re: [users@httpd] Set SSLCipherSuite dependent on client IP
On Thu, Feb 25, 2021 at 1:44 PM Brian Wolfe wrote: > > Are you sure that you have any MD5 ciphers enabled. Wrong thread? Regards; Yann. - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
Re: Re: [users@httpd] Set SSLCipherSuite dependent on client IP
Are you sure that you have any MD5 ciphers enabled. Most of them are disabled nowadays. For example on my OSX I only have 1 MD5 available: :~ $ openssl ciphers -v ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384 ECDHE-RSA-AES256-SHASSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1 ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1 DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256 DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA Enc=ChaCha20-Poly1305 Mac=AEAD ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA Enc=ChaCha20-Poly1305 Mac=AEAD DHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=DH Au=RSA Enc=ChaCha20-Poly1305 Mac=AEAD GOST2012256-GOST89-GOST89 SSLv3 Kx=GOST Au=GOST01 Enc=GOST-28178-89-CNT Mac=GOST89IMIT DHE-RSA-CAMELLIA256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA256 DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1 GOST2001-GOST89-GOST89 SSLv3 Kx=GOST Au=GOST01 Enc=GOST-28178-89-CNT Mac=GOST89IMIT AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 CAMELLIA256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=Camellia(256) Mac=SHA256 CAMELLIA256-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(256) Mac=SHA1 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256 ECDHE-RSA-AES128-SHASSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 ECDHE-ECDSA-AES128-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1 DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 DHE-RSA-CAMELLIA128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA256 DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA1 AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 CAMELLIA128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=Camellia(128) Mac=SHA256 CAMELLIA128-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(128) Mac=SHA1 ECDHE-RSA-RC4-SHA SSLv3 Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1 ECDHE-ECDSA-RC4-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=RC4(128) Mac=SHA1 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 ECDHE-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=RSA Enc=3DES(168) Mac=SHA1 ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=3DES(168) Mac=SHA1 EDH-RSA-DES-CBC3-SHASSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1 DES-CBC3-SHASSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 On Thu, Feb 25, 2021 at 6:46 AM Yann Ylavic wrote: > On Wed, Feb 24, 2021 at 6:01 PM Hildegard Meier wrote: > > > > I thought about something like that as cause, but since the client IP is > known from the very first start of the request, before TLS handshake, I > thought it could be evaluated. > > Yes but to determine the context from which the takes place > (VirtualHost, directory, location..), the server needs to know the > request header, thus negotiate TLS with the user-agent already. > Chicken and egg.. > > Regards; > Yann. > > - > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org > > -- Thanks, Brian Wolfe https://www.linkedin.com/in/brian-wolfe-3136425a/
Re: Re: [users@httpd] Set SSLCipherSuite dependent on client IP
On Wed, Feb 24, 2021 at 6:01 PM Hildegard Meier wrote: > > I thought about something like that as cause, but since the client IP is > known from the very first start of the request, before TLS handshake, I > thought it could be evaluated. Yes but to determine the context from which the takes place (VirtualHost, directory, location..), the server needs to know the request header, thus negotiate TLS with the user-agent already. Chicken and egg.. Regards; Yann. - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
Re: Re: [users@httpd] Set SSLCipherSuite dependent on client IP
On Wed, Feb 24, 2021 at 6:01 PM Hildegard Meier wrote: [...] > Could it be possible another way to give clients of a specific vHost > different SSLCipherSuite's depending on their IP address? (cipher of first > handshake, no renegotiation) You can work around this by setting up a separate vhost on a different port or IP and redirect the incoming traffic using the firewall/NAT tools supplied with your OS. Under Linux, something similar to the following might work: iptables -t nat -A PREROUTING -p tcp -s 1.2.3.0/24 --dport 80 -j REDIRECT --to 8080 regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
