SOLVED: Invalid method in request
I found the solution to my problem at this website: https://forum.bytemark.co.uk/viewtopic.php?pid=2072 Basically, any VirtualHost entries that are defined in the httpd.conf file need to have a :80 at the end of them. i.e.: to -Rob -Original Message- From: Dege, Robert C. Sent: Wednesday, February 28, 2007 11:53 AM To: 'modssl-users@modssl.org' Subject: Invalid method in request Hi, I have a 64bit RHEL3 box that I'm trying to configure SSL on. After making the appropriate modifications to the httpd.conf file, I restarted the service, & tested out the setup. I can get to the site using http://mysite.com:443 (not in secure mode), but not https://mysite.com. I get an error message in the logs that says "Invalid method in request !!!" Any help would be appreciated. Red Hat Enterprise v.3 (64bit) httpd-2.0.46, mod_ssl-2.0.46 openssl-0.9.7a, openssl096b-0.9.6b Code from httpd.conf file: == Listen 0.0.0.0:443 DocumentRoot "/var/www/html" ServerName www.mysite.com SSLEngine On SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL SSLCertificateFile /etc/httpd/conf/ssl/cert.pem SSLCertificateKeyFile /etc/httpd/conf/ssl/server.key SSLCACertificateFile /etc/httpd/conf/ssl/DigiCertSecurityServicesCA.crt SetEnvIf User-Agent ".*MSIE.*" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 -Rob __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List modssl-users@modssl.org Automated List Manager[EMAIL PROTECTED]
Invalid method in request
Hi, I have a 64bit RHEL3 box that I'm trying to configure SSL on. After making the appropriate modifications to the httpd.conf file, I restarted the service, & tested out the setup. I can get to the site using http://mysite.com:443 (not in secure mode), but not https://mysite.com. I get an error message in the logs that says "Invalid method in request !!!" Any help would be appreciated. Red Hat Enterprise v.3 (64bit) httpd-2.0.46, mod_ssl-2.0.46 openssl-0.9.7a, openssl096b-0.9.6b Code from httpd.conf file: == Listen 0.0.0.0:443 DocumentRoot "/var/www/html" ServerName www.mysite.com SSLEngine On SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL SSLCertificateFile /etc/httpd/conf/ssl/cert.pem SSLCertificateKeyFile /etc/httpd/conf/ssl/server.key SSLCACertificateFile /etc/httpd/conf/ssl/DigiCertSecurityServicesCA.crt SetEnvIf User-Agent ".*MSIE.*" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 -Rob __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List modssl-users@modssl.org Automated List Manager[EMAIL PROTECTED]
Invalid method in request \x80z\x01\x03\x01
Hello!
I'm using apache modssl and I'm not able to connect to port 443.
This problem is betwen server and client communication (HTTP versus
HTTPS), I think. But I don't know, how to solve this.
error_log:
Invalid method in request \x80L\x01\x03
host# /usr/bin/openssl s_client -connect myIP:443 -state -debug
CONNECTED(0003)
SSL_connect:before/connect initialization
write to 0808D4C0 [0809D000] (124 bytes => 124 (0x7C))
- 80 7a 01 03 01 00 51 00-00 00 20 00 00 16 00 00 .zQ... .
0010 - 13 00 00 0a 07 00 c0 00-00 66 00 00 05 00 00 04 .f..
0020 - 03 00 80 01 00 80 08 00-80 00 00 65 00 00 64 00 ...e..d.
0030 - 00 63 00 00 62 00 00 61-00 00 60 00 00 15 00 00 .c..b..a..`.
0040 - 12 00 00 09 06 00 40 00-00 14 00 00 11 00 00 08 ..@.
0050 - 00 00 06 00 00 03 04 00-80 02 00 80 af 78 8c e2 .x..
0060 - 0e ff ff 96 5b 2d 4e 31-6d c5 47 01 b0 61 c5 33 [-N1m.G..a.3
0070 - 39 b1 4f dd 0e b2 7b 3d-0a 2f 3e 7b 9.O...{=./>{
SSL_connect:SSLv2/v3 write client hello A
read from 0808D4C0 [080A3000] (7 bytes => 7 (0x7))
- 3c 21 44 4f 43 54 59
SSLOptions +StdEnvVars
SSLOptions +StdEnvVars
CustomLog /var/log/httpd/ssl_request_log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
Please, can you help me?
Thanx a lot!
--
Radek
__
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]
Re: Invalid method in request \x80\x80\x01\x03\x01
On Wednesday 30 Oct 2002 1:14 pm, Roger Rosenblum wrote:
> Greetings,
>
> I'm having problems getting SSL to work with Apache at the moment.
"SSLEngine on"
Your (virtual) host is expecting to talk clear HTTP to the client, and
you need to tell it to talk HTTPS instead. Ie. on the server, you're
seeing it try to interpret the SSL/TLS handshake data from the client as
though it was a clear-text HTTP request, ie;
> The message showing up the the error_log is:
> Invalid method in request \x80\x80\x01\x03\x01
and your SSL/TLS client is getting a clear-text ("bad request") response
from the server and trying to interpret it as SSL/TLS handshake data.
> and openssl reports "unknown protocol:s23_clnt.c:460:"
[snip]
> SSL_connect:SSLv2/v3 write client hello A
> read from 0015E368 [00165A68] (7 bytes => 7 (0x7))
> - 3c 21 44 4f 43 54 59 http://www.geoffthorpe.net/
__
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]
Invalid method in request \x80\x80\x01\x03\x01
Greetings,
I'm having problems getting SSL to work with Apache at the moment.
The message showing up the the error_log is:
Invalid method in request \x80\x80\x01\x03\x01
and openssl reports "unknown protocol:s23_clnt.c:460:"
Situation:
=
Sparc Solaris 9,
Apache 1.3.27
mod_ssl-2.18.12 for apache 1.3.27
openssl-0.9.6.g
mm-1.1.3
perl 5.8.0
openldap-2.0.25
mod_fastcgi-2.2.12
mod_perl-1.27
All statically compiled with no visible errors from the install.
I created an SSL key and signed a test certificate and installed them in the
/usr/lcoal/apache/conf/ssl.crt/server.crt
/usr/local/apache/conf/ssl.key/server.key
But I get errors trying to connect to it either as https:// and
also with the openssl command itself:
*
../bin/openssl s_client -connect localhost:443 -state -debug
CONNECTED(0003)
SSL_connect:before/connect initialization
write to 0015E368 [00160508] (130 bytes => 130 (0x82))
- 80 80 01 03 01 00 57 00-00 00 20 00 00 16 00 00 ..W... .
0010 - 13 00 00 0a 07 00 c0 00-00 66 00 00 07 00 00 05 .f..
0020 - 00 00 04 05 00 80 03 00-80 01 00 80 08 00 80 00
0030 - 00 65 00 00 64 00 00 63-00 00 62 00 00 61 00 00 .e..d..c..b..a..
0040 - 60 00 00 15 00 00 12 00-00 09 06 00 40 00 00 14 `...@...
0050 - 00 00 11 00 00 08 00 00-06 00 00 03 04 00 80 02
0060 - 00 80 92 22 27 d6 22 a7-d0 f7 1b 6f 47 89 7e 64 ..."'."oG.~d
0070 - 2a be ef ca 6d 31 8c 83-7c 91 84 a4 29 17 24 f1 *...m1..|...).$.
0080 - 9b 51 .Q
SSL_connect:SSLv2/v3 write client hello A
read from 0015E368 [00165A68] (7 bytes => 7 (0x7))
- 3c 21 44 4f 43 54 59
Re: Invalid method in request
> >--- Pavel_Hlou¹ek <[EMAIL PROTECTED]> wrote: >> What's wrong? When I connect to apache via https, Netscape says >> "Conection refused" and there is "invalid method in request" written >> in apache's error_log. >> I'm using Apache 1.3.19 + mod_ssl-2.8.1-1.3.19 + openssl-0.9.6. > >Did you use GET? or maybe a form, with POST? or even HEAD? >Some servers restrict certain methods, for example PUT is pretty >commonly a no-no. > Yes, I did. The same happens when I try to connect using openssl from command line. It means, that the error is caused prior to evaluation which of GET/POST/PUT/... methods was used. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Invalid method in request
--- Pavel_Hlou¹ek <[EMAIL PROTECTED]> wrote: > What's wrong? When I connect to apache via https, Netscape says > "Conection refused" and there is "invalid method in request" written > in apache's error_log. > I'm using Apache 1.3.19 + mod_ssl-2.8.1-1.3.19 + openssl-0.9.6. Did you use GET? or maybe a form, with POST? or even HEAD? Some servers restrict certain methods, for example PUT is pretty commonly a no-no. __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Invalid method in request
What's wrong? When I connect to apache via https, Netscape says "Conection refused" and there is "invalid method in request" written in apache's error_log. I'm using Apache 1.3.19 + mod_ssl-2.8.1-1.3.19 + openssl-0.9.6. Thanks Pavel
Re: Invalid method in request
On Fri, Mar 30, 2001, Pavel Hlou¹ek wrote: > I cannot connect to apache+mod_ssl with command recommended by mod_ssl documentation >(openssl s_client -connect localhost:443 -state -debug > ). It results in a message in error_log of apache: > > Ivalid method in request > > Any idea? You connect with HTTPS to a port where only HTTP is spoken. Check your server configuration, it's certainly a configure error. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Invalid method in request
I cannot connect to apache+mod_ssl with command recommended by mod_ssl documentation (openssl s_client -connect localhost:443 -state -debug). It results in a message in error_log of apache: Ivalid method in request Any idea? Pavel Hlousek
Re: Invalid method in request C or F
On Fri, Mar 24, 2000, jleung wrote: > We have Apache 1.3.12 with mod_ssl-2.6.1-1.3.12, and secure and non-secure > web server running on the same Solaris box. The SSL had been working fine > for weeks before the system rebooted a couple of days ago. Now, we > couldn't connect to the secure server, and the following is the error > message it logged into the error_log: > > [error] [client x.x.x.x] Invalid method in request C > [error] [client x.x.x.x]Invalid method in request F > > and for the access_log, its says: > > - - [24/Mar/2000:11:04:51 -0800] "F" 501 - > > Do you know what could be the problem here? We did start and stop the > secure server before with the system up and running with no ill effects. > Now, does it mean that we need to test the secure server with a system > reload as well? The problem is just that you are speaking HTTPS to a port where only HTTP is spoken. The reason is always a server mis-configuration. Make sure your Listen and directives match and that an "SSLEngine on" is present in your vitual host for HTTPS. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
RE: Invalid method in request C or F
I faced the same trouble, on NT. Fixed by simply restarting all the stuff on my side! HTH Daniel. > -Message d'origine- > De: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]De la part de jleung > Date: vendredi 24 mars 2000 20:52 > À: [EMAIL PROTECTED] > Objet: Invalid method in request C or F > > > We have Apache 1.3.12 with mod_ssl-2.6.1-1.3.12, and secure and non-secure > web server running on the same Solaris box. The SSL had been working fine > for weeks before the system rebooted a couple of days ago. Now, we > couldn't connect to the secure server, and the following is the error > message it logged into the error_log: > > [error] [client x.x.x.x] Invalid method in request C > [error] [client x.x.x.x]Invalid method in request F > > and for the access_log, its says: > > - - [24/Mar/2000:11:04:51 -0800] "F" 501 - > > Do you know what could be the problem here? We did start and stop the > secure server before with the system up and running with no ill effects. > Now, does it mean that we need to test the secure server with a system > reload as well? > > Regards, > Janet Leung E-mail: [EMAIL PROTECTED] > ISD USC, Los Angeles, CA 90089-0251 > > __ > Apache Interface to OpenSSL (mod_ssl) www.modssl.org > User Support Mailing List [EMAIL PROTECTED] > Automated List Manager[EMAIL PROTECTED] > > __ > Apache Interface to OpenSSL (mod_ssl) www.modssl.org > User Support Mailing List [EMAIL PROTECTED] > Automated List Manager[EMAIL PROTECTED] > __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Invalid method in request C or F
We have Apache 1.3.12 with mod_ssl-2.6.1-1.3.12, and secure and non-secure web server running on the same Solaris box. The SSL had been working fine for weeks before the system rebooted a couple of days ago. Now, we couldn't connect to the secure server, and the following is the error message it logged into the error_log: [error] [client x.x.x.x] Invalid method in request C [error] [client x.x.x.x]Invalid method in request F and for the access_log, its says: - - [24/Mar/2000:11:04:51 -0800] "F" 501 - Do you know what could be the problem here? We did start and stop the secure server before with the system up and running with no ill effects. Now, does it mean that we need to test the secure server with a system reload as well? Regards, Janet Leung E-mail: [EMAIL PROTECTED] ISD USC, Los Angeles, CA 90089-0251 __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Apache+mod_SSL - Invalid method in request
I have enabled SSL on one of my virtual hosts. I have specified the snakeoil certs and keys for now to test. When the browser goes to the protected site, it just hangs. I am entering it with the https:// prefix. In my error log, it says Invalid method in request and gives the client's IP. I have had this trouble now for quite some time and I thank anyone in advance for helping me with it. Thanks, Robert Oliver __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Invalid method in request C or F
On Fri, Mar 24, 2000, jleung wrote: > We have Apache 1.3.12 with mod_ssl-2.6.1-1.3.12, and secure and non-secure > web server running on the same Solaris box. The SSL had been working fine > for weeks before the system rebooted a couple of days ago. Now, we > couldn't connect to the secure server, and the following is the error > message it logged into the error_log: > > [error] [client x.x.x.x] Invalid method in request C > [error] [client x.x.x.x]Invalid method in request F > > and for the access_log, its says: > > - - [24/Mar/2000:11:04:51 -0800] "F" 501 - > > Do you know what could be the problem here? We did start and stop the > secure server before with the system up and running with no ill effects. > Now, does it mean that we need to test the secure server with a system > reload as well? This has nothing to do with a reboot. If it worked before, someone has changed your server config. The problem you have is that you're speaking HTTPS to a port where only HTTP is spoken. There can be various reasons. the most common reason is that the Listen and directives do not exactly match or that an "SSLEngine on" is missing in the HTTPS virtual server part. Check your server configuration, please. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Invalid method in request C or F
We have Apache 1.3.12 with mod_ssl-2.6.1-1.3.12, and secure and non-secure web server running on the same Solaris box. The SSL had been working fine for weeks before the system rebooted a couple of days ago. Now, we couldn't connect to the secure server, and the following is the error message it logged into the error_log: [error] [client x.x.x.x] Invalid method in request C [error] [client x.x.x.x]Invalid method in request F and for the access_log, its says: - - [24/Mar/2000:11:04:51 -0800] "F" 501 - Do you know what could be the problem here? We did start and stop the secure server before with the system up and running with no ill effects. Now, does it mean that we need to test the secure server with a system reload as well? Regards, Janet Leung E-mail: [EMAIL PROTECTED] ISD USC, Los Angeles, CA 90089-0251 __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Apache+mod_SSL - Invalid method in request
Good morning, I ran into this when I did not have SSLEngine specified to "on". If you use http://my.host.org:443 and get what you would expect with https://my.host.org then I would say check for this option. Here's a sample of a running conf file. The server is apache 1.3.12 with SSL for win32. The only thing different I suspect is the SSLMutex and the serverroot Oddly enough name based virtual host *seems* to be working for SSL. Did that get changed? I need to test it with more than one domain per host. Haven't done that yet. So many things to do so little time... =) Later, -Rob In the main httpd.conf file Port 80 Listen 80 Listen 443 ## SSL Global Context AddType application/x-x509-ca-cert .crt AddType application/x-pkcs7-crl.crl SSLPassPhraseDialog builtin SSLSessionCachenone SSLMutex sem SSLRandomSeed startup builtin SSLRandomSeed connect builtin SSLLog logs/ssl_engine_log SSLLogLevel warn SSLCACertificatePath D:/AppSSL/conf/SSL SSLCACertificateFile D:/AppSSL/conf/SSL/ca-bundle.crt <...snip...> # This conf works in a live test box # Apache win32 mod ssl running a verisign test cert NameVirtualHost 10.2.6.13 DocumentRoot d:\AppSSL ServerName itocert.state.il.us ErrorLog logs/itocert-error.log CustomLog logs/itocert-access.log common DocumentRoot d:\AppSSL ServerName itocert.state.il.us ErrorLog logs/itocert-error.log CustomLog logs/itocert-access.log \ "%t %h %(SSL_PROTOCOL) %(SSL_CIPHER)x \"%r\" %b" SSLEngine On # # For problematic Microsoft # SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown # # Set encryption to high or medium only # SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM SSLCertificateFile D:/AppSSL/conf/SSL/itocertver.crt SSLCertificateKeyFile D:/AppSSL/conf/SSL/itocert.key # # Use these if you want the remote clients to have certificates # issued to them. Might be useful for high security needs # #SSLVerifyClient require #SSLVerifyDepth 10 At 10:04 PM 03/13/2000 -0600, you wrote: > >I have enabled SSL on one of my virtual hosts. I have specified the >snakeoil certs and keys for now to test. When the browser goes to the >protected site, it just hangs. I am entering it with the https:// prefix. >In my error log, it says Invalid method in request and gives the client's >IP. I have had this trouble now for quite some time and I thank anyone in >advance for helping me with it. > >Thanks, > >Robert Oliver > >__ >Apache Interface to OpenSSL (mod_ssl) www.modssl.org >User Support Mailing List [EMAIL PROTECTED] >Automated List Manager[EMAIL PROTECTED] > > __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Apache+mod_SSL - Invalid method in request
On Mon, Mar 13, 2000, Robert W. Oliver wrote: > I have enabled SSL on one of my virtual hosts. I have specified the > snakeoil certs and keys for now to test. When the browser goes to the > protected site, it just hangs. I am entering it with the https:// prefix. > In my error log, it says Invalid method in request and gives the client's > IP. I have had this trouble now for quite some time and I thank anyone in > advance for helping me with it. Although you're connecting with HTTPS, on the HTTPS port your server speaks only HTTP! Check your server configuration, please. Make sure Listen and directives match and that the has an "SSLEngine on", too. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Apache+mod_SSL - Invalid method in request
I have enabled SSL on one of my virtual hosts. I have specified the snakeoil certs and keys for now to test. When the browser goes to the protected site, it just hangs. I am entering it with the https:// prefix. In my error log, it says Invalid method in request and gives the client's IP. I have had this trouble now for quite some time and I thank anyone in advance for helping me with it. Thanks, Robert Oliver __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: [BugDB] Invalid method in request E% (PR#324)
On Wed, Dec 08, 1999, [EMAIL PROTECTED] wrote: > Full_Name: Ken > Version: 2.4.9-1.3.9 > OS: Solaris 2.6 Sparc > Submission from: (NULL) (202.64.57.66) > > This is a question from a newbie. > > I've installed openssl-0.9.4, mm-1.0.12, modssl-2.4.9-1.3.9, apache-1.3.9. I > tried to make my own certificate, signed by a self-created ca.crt. I also tried > "make certificate". > > The result is I get "Invalid method in request..." in my log file. Can someone > tell me what's going on? This usually means you're speaking HTTPS to a port where only HTTP is spoken. Check your server configuration (by comparing with httpd.conf-dist) and make sure SSL is actually enabled for the virtual host which corresponds to the port you connect to. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
[BugDB] Invalid method in request E% (PR#324)
Full_Name: Ken Version: 2.4.9-1.3.9 OS: Solaris 2.6 Sparc Submission from: (NULL) (202.64.57.66) This is a question from a newbie. I've installed openssl-0.9.4, mm-1.0.12, modssl-2.4.9-1.3.9, apache-1.3.9. I tried to make my own certificate, signed by a self-created ca.crt. I also tried "make certificate". The result is I get "Invalid method in request..." in my log file. Can someone tell me what's going on? __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: "Invalid method in request %" error
On Fri, 22 Oct 1999, Ralf S. Engelschall wrote: > On Thu, Oct 21, 1999, [EMAIL PROTECTED] wrote: > > > I just built apache_1.3.9 + mod_ssl-2.4.5-1.3.9 + openssl-0.9.4 (it > > wouldn't build with rsaref, but that's another can o' worms I'll worry > > about later). > > > > It's running on both ports 80 and 443. I can connect with standard http > > fine, but when I try https, the client just hangs and I get the following > > in the logs: > > > > error_log: > > " [error] [client x] Invalid method in request % " > > access_log: > > " x - - [21/Oct/1999:17:02:33 -0400] "%" 501 - " > > > > So it's seeing a request for "%" from https, but not http ? > > Hints appreciated. > > As the FAQ explains, such errors usually indicate that you're speaking HTTPS Actually, I looked through the FAQ, as well as the past two months of list archives before posting and saw no mention of this "%" error. In fact, I just looked again, and I still don't...in any case, this was indeed the problem. Thanks. > to a port where HTTP is spoken only. Make sure "SSLEngine on" is present and > that your Listen directives match your sections. I was trying to run the standalone server as SSL, and thought that telling it to listen on port 443 was enough...still used to Apache_SSL, and the idea of running two different daemons, with two separate web roots, etc. The idea of running the SSL virtual host as a virtual host under a regular httpd standalone server sounds the more I think about it, though... James Smallacombe PlantageNet, Inc. CEO and Janitor [EMAIL PROTECTED] http://3.am = ISPF 3 - The Forum for ISPs by ISPs(tm) || Nov 15-17, 1999, New Orleans 3 days of clues, news, and views from the industry's best and brightest. Visit <http://www.ispf.com/> for information and registration. = __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: "Invalid method in request %" error
On Thu, Oct 21, 1999, [EMAIL PROTECTED] wrote: > I just built apache_1.3.9 + mod_ssl-2.4.5-1.3.9 + openssl-0.9.4 (it > wouldn't build with rsaref, but that's another can o' worms I'll worry > about later). > > It's running on both ports 80 and 443. I can connect with standard http > fine, but when I try https, the client just hangs and I get the following > in the logs: > > error_log: > " [error] [client x] Invalid method in request % " > access_log: > " x - - [21/Oct/1999:17:02:33 -0400] "%" 501 - " > > So it's seeing a request for "%" from https, but not http ? > Hints appreciated. As the FAQ explains, such errors usually indicate that you're speaking HTTPS to a port where HTTP is spoken only. Make sure "SSLEngine on" is present and that your Listen directives match your sections. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: "Invalid method in request %" error
<[EMAIL PROTECTED]> writes: > I just built apache_1.3.9 + mod_ssl-2.4.5-1.3.9 + openssl-0.9.4 (it > wouldn't build with rsaref, but that's another can o' worms I'll worry > about later). > > It's running on both ports 80 and 443. I can connect with standard http > fine, but when I try https, the client just hangs and I get the following > in the logs: > > error_log: > > " [error] [client x] Invalid method in request % " > > access_log: > > " x - - [21/Oct/1999:17:02:33 -0400] "%" 501 - " > > So it's seeing a request for "%" from https, but not http ? > > Hints appreciated. This means that you're speaking https when the server thinks you should be speaking http. This is either a config file issue, or an URL in your HTML issue. -Tom -- Tom Vaughan __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
"Invalid method in request %" error
I just built apache_1.3.9 + mod_ssl-2.4.5-1.3.9 + openssl-0.9.4 (it wouldn't build with rsaref, but that's another can o' worms I'll worry about later). It's running on both ports 80 and 443. I can connect with standard http fine, but when I try https, the client just hangs and I get the following in the logs: error_log: " [error] [client x] Invalid method in request % " access_log: " x - - [21/Oct/1999:17:02:33 -0400] "%" 501 - " So it's seeing a request for "%" from https, but not http ? Hints appreciated. TIA! James Smallacombe PlantageNet, Inc. CEO and Janitor [EMAIL PROTECTED] http://3.am = ISPF 3 - The Forum for ISPs by ISPs(tm) || Nov 15-17, 1999, New Orleans 3 days of clues, news, and views from the industry's best and brightest. Visit <http://www.ispf.com/> for information and registration. = __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: [apache-ssl] Assertions considered bad!? (was: Re: [apache-ssl] Invalid method in request)
On Wed, Nov 18, 1998, Ben Laurie wrote: > > Please be technical only and correct. The assertions were not just removed in > > mod_ssl. They were replaced with run-time checks which pass the error up to > > the callers and there it's handled without and exit(). > > I don't understand the distinction you are trying to draw. A fatal error > was made non-fatal when it should not have been. > > > And IMHO the assertions > > were also not assertions for programming errors. Because why has asserting the > > returned number of bytes from read() anything to do with a programming error? > > It's just an I/O error. > > We've been over this already, but once more: it isn't "just an I/O > error", its something that can only happen if something has gone wrong > with either Apache-SSL or gcache. The fact that this results in an I/O > error is no more relevant than if it resulted a segmentation fault or in > a variable being set to an impossible value. If an I/O error can occur > _without_ a bug in the code, and with some possibility of recovering > from it, then it would be appropriate to attempt to handle the error. As > far as I currently know, this is not the case. Yes, your position is based on the assumption that an I/O _cannot_ occur. And I don't want to assume this, so I check for those I/O errors explicitly. Actually not really a point of discussion, more a point of programming style. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [apache-ssl] Assertions considered bad!? (was: Re: [apache-ssl] Invalid method in request)
Ralf S. Engelschall wrote: > > On Wed, Nov 18, 1998, Ben Laurie wrote: > > >[...] > > > My $0.02, if it's worth anything. But if that's the way you code > > > Apache-SSL, I'm very glad my friend pointed me to mod_ssl. > > > > If you want to use a system where programming errors are "corrected" by > > removing the assertions that reveal them, that is your choice, of > > course. > > Please be technical only and correct. The assertions were not just removed in > mod_ssl. They were replaced with run-time checks which pass the error up to > the callers and there it's handled without and exit(). I don't understand the distinction you are trying to draw. A fatal error was made non-fatal when it should not have been. > And IMHO the assertions > were also not assertions for programming errors. Because why has asserting the > returned number of bytes from read() anything to do with a programming error? > It's just an I/O error. We've been over this already, but once more: it isn't "just an I/O error", its something that can only happen if something has gone wrong with either Apache-SSL or gcache. The fact that this results in an I/O error is no more relevant than if it resulted a segmentation fault or in a variable being set to an impossible value. If an I/O error can occur _without_ a bug in the code, and with some possibility of recovering from it, then it would be appropriate to attempt to handle the error. As far as I currently know, this is not the case. Cheers, Ben. -- Ben Laurie|Phone: +44 (181) 735 0686| Apache Group member Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/ and Technical Director|Email: [EMAIL PROTECTED] | A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/ London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/ __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [apache-ssl] Assertions considered bad!? (was: Re: [apache-ssl] Invalid method in request)
On Wed, Nov 18, 1998, Ben Laurie wrote: >[...] > > My $0.02, if it's worth anything. But if that's the way you code > > Apache-SSL, I'm very glad my friend pointed me to mod_ssl. > > If you want to use a system where programming errors are "corrected" by > removing the assertions that reveal them, that is your choice, of > course. Please be technical only and correct. The assertions were not just removed in mod_ssl. They were replaced with run-time checks which pass the error up to the callers and there it's handled without and exit(). And IMHO the assertions were also not assertions for programming errors. Because why has asserting the returned number of bytes from read() anything to do with a programming error? It's just an I/O error. OTOH gcache (where the assertions originally were used) is already gone in mod_ssl 2.1... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [apache-ssl] Assertions considered bad!? (was: Re: [apache-ssl] Invalid method in request)
SPASTIC Member wrote:
>
> 127.0.0.1 is just another interface. All possible errors can happen.
> Imagine a server where the load is high enough that other processes don't
> get to run much... they write to localhost, expecting what's on the other
> end to get it, but the localhost interface buffers overflow.
I would expect them to do what any other interface does, i.e. block
until there is space.
> Or the misconfigured routed that brings down the route to 127.0.0.1, or
> routes it to Timbuktu.
What error will this cause, and what is the correct action to take when
you get that error?
> Or the novice sysadmin who decides to ifconfig [lo|l0|lo0] down.
Same question.
> (Yes, I've seen all of these situations happen. The second one, I can't
> remember why we figured that the UNIX didn't read it anyway, since it had
> an interface with the destination IP number, but it routed it before
> checking its local interface list.)
>
> Assertions only belong in debugging code, not production code. In
> production code, reliability/robustness is more important than 'proper
> coding'. Granted, gcache is fixed now, but in the event of an error, if
> I'd coded it, I would have logged the error and moved on -- not died the
> first time an I/O operation failed to return the expected number of bytes.
> ('robust' means 'fault-tolerant', among other things.)
In my book, robust means correct behaviour. I do not see how you can
improve robustness by tolerating things that can only occur if there is
a programming error. I only assert stuff I believe cannot possibly occur
except if there is a programming error. Of course, I could be wrong in
my beliefs, in which case I have a bug, which I will fix as soon as I'm
told about it, naturally.
Next people will be suggesting that ignoring all signals leads to more
robust code. Sheesh.
> My $0.02, if it's worth anything. But if that's the way you code
> Apache-SSL, I'm very glad my friend pointed me to mod_ssl.
If you want to use a system where programming errors are "corrected" by
removing the assertions that reveal them, that is your choice, of
course.
Cheers,
Ben.
--
Ben Laurie|Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/
and Technical Director|Email: [EMAIL PROTECTED] |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/
__
Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/
Official Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [apache-ssl] Assertions considered bad!? (was: Re: [apache-ssl] Invalid method in request)
127.0.0.1 is just another interface. All possible errors can happen.
Imagine a server where the load is high enough that other processes don't
get to run much... they write to localhost, expecting what's on the other
end to get it, but the localhost interface buffers overflow.
Or the misconfigured routed that brings down the route to 127.0.0.1, or
routes it to Timbuktu.
Or the novice sysadmin who decides to ifconfig [lo|l0|lo0] down.
(Yes, I've seen all of these situations happen. The second one, I can't
remember why we figured that the UNIX didn't read it anyway, since it had
an interface with the destination IP number, but it routed it before
checking its local interface list.)
Assertions only belong in debugging code, not production code. In
production code, reliability/robustness is more important than 'proper
coding'. Granted, gcache is fixed now, but in the event of an error, if
I'd coded it, I would have logged the error and moved on -- not died the
first time an I/O operation failed to return the expected number of bytes.
('robust' means 'fault-tolerant', among other things.)
My $0.02, if it's worth anything. But if that's the way you code
Apache-SSL, I'm very glad my friend pointed me to mod_ssl.
-Mat Butler
---
Mat Butler, Winged Wolf <[EMAIL PROTECTED]>
SPASTIC Web Engineer SPASTIC Server Administrator
Begin FurryCode v1.3
FCWw5amrsw A- C+ D H+++ M+[servercoder] P+ R++ T+++ W Z++ Sm++
RLCT/M*/LW* a cl/u/v>+ !d e- f> h++ iwf+++ j p->+ sm++
End FurryCode v1.3
On Sat, 31 Oct 1998, Ben Laurie wrote:
> Ralf S. Engelschall wrote:
> >
> > On Sat, Oct 31, 1998, Ben Laurie wrote:
> >
> > > Ralf S. Engelschall wrote:
> > > > H??? Do you mean it cannot occur in practice? Or do I misunderstand you
> > > > here. As I said: We not even need an attacker: When an I/O read error occurs
> > > > for gcache it already falls down. So the DoS attacker is just the worst case.
> > >
> > > Aha. Now we get down to it. OK, please describe how an I/O error can
> > > occur on a locally connected socket.
> >
> > How it actually can occur I don't know. Depends on the platform, I think. But
> > in general I don't think that Unix guarantees that a TCP connection to
> > localhost always can be performed without any problems. I've no actual
> > scenario of an I/O communication error at hand, but I've at least the code
> > parts at hand which then could fail:
> >
> > | nRead=saferead(nFD,&usLength,sizeof usLength);
> > | assert(nRead == sizeof usLength);
> >
> > Here the assert makes sure that really the requested number of bytes are read.
> > But when an I/O error or some other communication problem occurs the actual
> > number of read bytes can be different. Then the gcache process falls down.
> > And I've seen exactly gcache exits with this assertion on my boxes (Solaris
> > 2.6) while I was mostly sure that no personal attacker was involved. Instead
> > I really assume it was just some I/O communication error...
>
> This is exactly where it failed when gcache was crashing because of a
> bug. Could it be that you assumed there was a network error instead?
> Since gcache was fixed I have had no reports of this assertion failing.
>
> I do not believe that an I/O error is possible on a locally connected
> socket. I would be most reluctant to fix this without evidence that it
> is actually a bug. Since this seems to be the thread for maxims, one of
> my favourites is "if you don't understand why it is broken, don't fix
> it", and I intend to stick to that.
>
> Cheers,
>
> Ben.
>
> --
> Ben Laurie|Phone: +44 (181) 735 0686| Apache Group member
> Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/
> and Technical Director|Email: [EMAIL PROTECTED] |
> A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
> London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/
> __
> Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/
> Official Support Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
>
__
Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/
Official Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [apache-ssl] Assertions considered bad!? (was: Re: [apache-ssl] Invalid method in request)
Ralf S. Engelschall wrote: > > On Sat, Oct 31, 1998, Ben Laurie wrote: > > >[...] > > > While you may think that the only way to run a SSL server is where no one > > > can login, no users can run any programs on it, etc. in the real world > > > that isn't always possible. > > > > I have to say that my main interest is in secure servers. If people want > > to run toy SSL servers, then I'll support them as far as I can, but not > > if it means compromising the safety of the real ones. That said, I > > haven't said that no one can log in, no users can run programs, etc. > > You've just invented that requirement. What I have said is that my > > threat model says that a local attacker is something that should not be > > permitted. > > Ben, seems like you think that when something has to be secure it has to > implicate that it cannot be robust at the same time. This has not to be the > case: It can and should be always robust _AND_ secure. Both are important the > same way: Because lack of robustness opens new security holes. So security > software has to be designed and implemented in a robust way, then checked for > any special security problems and finally enhanced with security checks (DoS, > etc.) in _addition_ to the standard error checks, IMHO. Yawn. I knew I'd regret saying that. I'm not suggesting that they are mutually exclusive, I'm just saying that I need to know that there is a problem before I fix it, and if that means it has to go wrong first, so be it. But the point is that I don't believe there's a problem. I don't think I should change the way it works on the off-chance that there _might_ be a problem. > > Bottom line: if gcache is a problem in your environment, disable it. > > Hmmm... is this very user friendly, Ben? I think we cannot say: "Hey, here is > the SSL solution. When something of it bores you, disable it" just because we > didn't spent enough time to make it as secure and robust as it should be to be > acceptable for the users. Then it's better at least to disable it all the time > and declare it as an experimental feature. I personally think the default > functionality should be already as secure and robust that users don't have > problems with it, shouldn't it? It should. And as far as I know, it is. All this is pure speculation, arising from your original stance that "assertions are bad", which you now agree is not actually true. You are now trying to find a way to demonstrate that my assertions are bad, while yours are good. So you are invoking an error condition that is not known to occur to justify the argument. I'm getting bored with this, I have to admit. Cheers, Ben. -- Ben Laurie|Phone: +44 (181) 735 0686| Apache Group member Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/ and Technical Director|Email: [EMAIL PROTECTED] | A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/ London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/ __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [apache-ssl] Assertions considered bad!? (was: Re: [apache-ssl] Invalid method in request)
On Sat, Oct 31, 1998, Ben Laurie wrote: >[...] > > While you may think that the only way to run a SSL server is where no one > > can login, no users can run any programs on it, etc. in the real world > > that isn't always possible. > > I have to say that my main interest is in secure servers. If people want > to run toy SSL servers, then I'll support them as far as I can, but not > if it means compromising the safety of the real ones. That said, I > haven't said that no one can log in, no users can run programs, etc. > You've just invented that requirement. What I have said is that my > threat model says that a local attacker is something that should not be > permitted. Ben, seems like you think that when something has to be secure it has to implicate that it cannot be robust at the same time. This has not to be the case: It can and should be always robust _AND_ secure. Both are important the same way: Because lack of robustness opens new security holes. So security software has to be designed and implemented in a robust way, then checked for any special security problems and finally enhanced with security checks (DoS, etc.) in _addition_ to the standard error checks, IMHO. > Bottom line: if gcache is a problem in your environment, disable it. Hmmm... is this very user friendly, Ben? I think we cannot say: "Hey, here is the SSL solution. When something of it bores you, disable it" just because we didn't spent enough time to make it as secure and robust as it should be to be acceptable for the users. Then it's better at least to disable it all the time and declare it as an experimental feature. I personally think the default functionality should be already as secure and robust that users don't have problems with it, shouldn't it? Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [apache-ssl] Assertions considered bad!? (was: Re: [apache-ssl] Invalid method in request)
It is hard to come up with a universal solution. The user has to decide for themselves. If their site is high liability site, anything suspecius occurs and they should shut down. This prevent any further possible exploit. If their liability is not very high and availability is important, they may decide to stay up even. -Original Message- From: Ralf S. Engelschall <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Cc: Apache-SSL ML <[EMAIL PROTECTED]> Date: Saturday, October 31, 1998 12:22 PM Subject: Re: [apache-ssl] Assertions considered bad!? (was: Re: [apache-ssl] Invalid method in request) >On Sat, Oct 31, 1998, Ben Laurie wrote: > >> > > >[...] >> > > > | nRead=saferead(nFD,&usLength,sizeof usLength); >> > > > | assert(nRead == sizeof usLength); >> > > > >> > > > Here the assert makes sure that really the requested number of bytes are read. >> > > > But when an I/O error or some other communication problem occurs the actual >> > > > number of read bytes can be different. Then the gcache process falls down. >> > > > And I've seen exactly gcache exits with this assertion on my boxes (Solaris >> > > > 2.6) while I was mostly sure that no personal attacker was involved. Instead >> > > > I really assume it was just some I/O communication error... >> > > >> > > This is exactly where it failed when gcache was crashing because of a >> > > bug. Could it be that you assumed there was a network error instead? >> > > Since gcache was fixed I have had no reports of this assertion failing. >> > >> > May be, I've the error messages no longer available. >> >> I assume you log something when it happens. Do you see the log message? > >It was in the error_log, yes. But a quick grep over my error log archive of >www.engelschall.com currently results in nothing. Either it was not this >particular box or I've to search in even older error logs. I'll search for >the entry in more depth the next days, Ben. > >>[...] >> > But always do good prevention is another good maxim, too ;-) >> >> I do. That's why I back my assumption up with an assertion. The >> assertion is not intended to catch a condition I believe will ever occur >> in normal operation. It is a symptom that something is wrong. Isn't this >> where we came in? > >Yes, and the only problem is that although we both are the opinion that >something is wrong under those situations we still differ in the opinion which >action should be done. I'm still convinced that it's not really reasonable to >use assertions (which do the exit of the process). But as we discovered by our >discussion now there is no generally correct way. So your assertion-based >approach can be acceptable although it makes life of the users nasty. >Nevertheless I _personally_ prefer non-assertion based error checking where >error codes are passed up to the callers and where the processed don't die. > >And I would appreciate when Apache-SSL's gcache would use the same approach. >That's why we discussed this topic. > > Ralf S. Engelschall > [EMAIL PROTECTED] > www.engelschall.com >__ >Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ >Official Support Mailing List [EMAIL PROTECTED] >Automated List Manager [EMAIL PROTECTED] > __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [apache-ssl] Assertions considered bad!? (was: Re: [apache-ssl] Invalid method in request)
Marc Slemko wrote: > > On Sat, 31 Oct 1998, Ben Laurie wrote: > > > Ah, I also forgot to mention that an attacker with the ability to talk > > to gcache can completely screw you with just legitimate messages - by > > poisoning your cache. They can presumably also get access to session > > keys. So, if anyone can talk to gcache apart from Apache-SSL, you've had > > it anyway. > > Then running gacache in this way is fundamentally broken and should > assert() right after it opens the socket and figures out that it worked so > it is completely insecure. I'm not sure gcache is in a position to detect this situation. If you think it can, I'd like to know how. > You think anyone runs a proxy on the same machine as gcache? Well, oops, > sorry, can't do that since it could connect to gcache and make it exit by > sending an invalid request. Pay attention. a) you should prevent the proxy from doing it (allowing a proxy to make random requests to random servers is a well known hole). b) you should be using Unix domain sockets. > While you may think that the only way to run a SSL server is where no one > can login, no users can run any programs on it, etc. in the real world > that isn't always possible. I have to say that my main interest is in secure servers. If people want to run toy SSL servers, then I'll support them as far as I can, but not if it means compromising the safety of the real ones. That said, I haven't said that no one can log in, no users can run programs, etc. You've just invented that requirement. What I have said is that my threat model says that a local attacker is something that should not be permitted. Bottom line: if gcache is a problem in your environment, disable it. Cheers, Ben. -- Ben Laurie|Phone: +44 (181) 735 0686| Apache Group member Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/ and Technical Director|Email: [EMAIL PROTECTED] | A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/ London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/ __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [apache-ssl] Assertions considered bad!? (was: Re: [apache-ssl] Invalid method in request)
Marc Slemko wrote: > > On Sat, 31 Oct 1998, Ben Laurie wrote: > > > This is far to general a criterion. Some kinds of I/O are completely > > deterministic (given correct code). I agree that to assert on user input > > is not a brilliant idea, but on a tightly linked client/server pair, it > > seems to me no different to asserting on the value of a parameter. > > The difference is that you are assuming that if there is a problem with > the client, then there is a problem with the server. That is like saying > that if a web browser makes an improperly formatted request to Apache, it > should assert() because that shouldn't happen and could mean the server is > messed up and doing something wrong. No, it isn't. I wrote both ends of the link. > It doesn't make sense to assume that communications are perfect unless you > have proof otherwise. In this case, I'm guessing that if the client > connects then closes the socket for some reason before sending the request > then gcache will die. This could be due to any one of a huge number of > issues in the client or the OS, eg. temporary lack of networking buffers, > stray timeout, logic error in the client, etc. It simply isn't robust to > assume that if there is ever an error in any part of the system the whole > system should fall down! If I have to choose between secure and robust, I choose secure every time (for this application). There shouldn't be logic errors in the client, stray timeouts etc. Temporary lack of network buffers I don't buy for UNIX domain sockets, and if I'm going to allow for it, I want to know that it occurs and exactly what the symptoms are. Cheers, Ben. -- Ben Laurie|Phone: +44 (181) 735 0686| Apache Group member Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/ and Technical Director|Email: [EMAIL PROTECTED] | A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/ London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/ __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [apache-ssl] Assertions considered bad!? (was: Re:[apache-ssl] Invalid method in request)
On Sat, 31 Oct 1998, Ben Laurie wrote: > This is far to general a criterion. Some kinds of I/O are completely > deterministic (given correct code). I agree that to assert on user input > is not a brilliant idea, but on a tightly linked client/server pair, it > seems to me no different to asserting on the value of a parameter. The difference is that you are assuming that if there is a problem with the client, then there is a problem with the server. That is like saying that if a web browser makes an improperly formatted request to Apache, it should assert() because that shouldn't happen and could mean the server is messed up and doing something wrong. It doesn't make sense to assume that communications are perfect unless you have proof otherwise. In this case, I'm guessing that if the client connects then closes the socket for some reason before sending the request then gcache will die. This could be due to any one of a huge number of issues in the client or the OS, eg. temporary lack of networking buffers, stray timeout, logic error in the client, etc. It simply isn't robust to assume that if there is ever an error in any part of the system the whole system should fall down! __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [apache-ssl] Assertions considered bad!? (was: Re:[apache-ssl] Invalid method in request)
On Sat, 31 Oct 1998, Ben Laurie wrote: > Ah, I also forgot to mention that an attacker with the ability to talk > to gcache can completely screw you with just legitimate messages - by > poisoning your cache. They can presumably also get access to session > keys. So, if anyone can talk to gcache apart from Apache-SSL, you've had > it anyway. Then running gacache in this way is fundamentally broken and should assert() right after it opens the socket and figures out that it worked so it is completely insecure. You think anyone runs a proxy on the same machine as gcache? Well, oops, sorry, can't do that since it could connect to gcache and make it exit by sending an invalid request. While you may think that the only way to run a SSL server is where no one can login, no users can run any programs on it, etc. in the real world that isn't always possible. __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [apache-ssl] Assertions considered bad!? (was: Re: [apache-ssl] Invalid method in request)
On Sat, Oct 31, 1998, Ben Laurie wrote: >[...] > > Nevertheless I _personally_ prefer non-assertion based error checking where > > error codes are passed up to the callers and where the processed don't die. > > What? We've already agreed that assertions should not be used in place > of error handling. Do not put words into my mouth. Sorry, I was not clear: I referred here to the particular I/O related assertions in gcache which I would like to see replaced, not to assertions in general. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [apache-ssl] Assertions considered bad!? (was: Re: [apache-ssl] Invalid method in request)
Ralf S. Engelschall wrote: > Yes, and the only problem is that although we both are the opinion that > something is wrong under those situations we still differ in the opinion which > action should be done. I'm still convinced that it's not really reasonable to > use assertions (which do the exit of the process). But as we discovered by our > discussion now there is no generally correct way. So your assertion-based > approach can be acceptable although it makes life of the users nasty. No. Users should not see the assertions, unless there are bugs. If an assertion is seen during normal operation, then there is a bug. The problem is that you are claiming something happens during normal operation that causes an assertion to fail. However, this claim currently appears to be erroneous. Your approach hides bugs, which is why I'm not currently prepared to change this correct assertion into an incorrect and bug-concealing logging message. > Nevertheless I _personally_ prefer non-assertion based error checking where > error codes are passed up to the callers and where the processed don't die. What? We've already agreed that assertions should not be used in place of error handling. Do not put words into my mouth. Cheers, Ben. -- Ben Laurie|Phone: +44 (181) 735 0686| Apache Group member Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/ and Technical Director|Email: [EMAIL PROTECTED] | A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/ London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/ __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [apache-ssl] Assertions considered bad!? (was: Re: [apache-ssl] Invalid method in request)
On Sat, Oct 31, 1998, Ben Laurie wrote: > > > >[...] > > > > | nRead=saferead(nFD,&usLength,sizeof usLength); > > > > | assert(nRead == sizeof usLength); > > > > > > > > Here the assert makes sure that really the requested number of bytes are read. > > > > But when an I/O error or some other communication problem occurs the actual > > > > number of read bytes can be different. Then the gcache process falls down. > > > > And I've seen exactly gcache exits with this assertion on my boxes (Solaris > > > > 2.6) while I was mostly sure that no personal attacker was involved. Instead > > > > I really assume it was just some I/O communication error... > > > > > > This is exactly where it failed when gcache was crashing because of a > > > bug. Could it be that you assumed there was a network error instead? > > > Since gcache was fixed I have had no reports of this assertion failing. > > > > May be, I've the error messages no longer available. > > I assume you log something when it happens. Do you see the log message? It was in the error_log, yes. But a quick grep over my error log archive of www.engelschall.com currently results in nothing. Either it was not this particular box or I've to search in even older error logs. I'll search for the entry in more depth the next days, Ben. >[...] > > But always do good prevention is another good maxim, too ;-) > > I do. That's why I back my assumption up with an assertion. The > assertion is not intended to catch a condition I believe will ever occur > in normal operation. It is a symptom that something is wrong. Isn't this > where we came in? Yes, and the only problem is that although we both are the opinion that something is wrong under those situations we still differ in the opinion which action should be done. I'm still convinced that it's not really reasonable to use assertions (which do the exit of the process). But as we discovered by our discussion now there is no generally correct way. So your assertion-based approach can be acceptable although it makes life of the users nasty. Nevertheless I _personally_ prefer non-assertion based error checking where error codes are passed up to the callers and where the processed don't die. And I would appreciate when Apache-SSL's gcache would use the same approach. That's why we discussed this topic. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [apache-ssl] Assertions considered bad!? (was: Re: [apache-ssl] Invalid method in request)
Ralf S. Engelschall wrote: > > On Sat, Oct 31, 1998, Ben Laurie wrote: > > > >[...] > > > | nRead=saferead(nFD,&usLength,sizeof usLength); > > > | assert(nRead == sizeof usLength); > > > > > > Here the assert makes sure that really the requested number of bytes are read. > > > But when an I/O error or some other communication problem occurs the actual > > > number of read bytes can be different. Then the gcache process falls down. > > > And I've seen exactly gcache exits with this assertion on my boxes (Solaris > > > 2.6) while I was mostly sure that no personal attacker was involved. Instead > > > I really assume it was just some I/O communication error... > > > > This is exactly where it failed when gcache was crashing because of a > > bug. Could it be that you assumed there was a network error instead? > > Since gcache was fixed I have had no reports of this assertion failing. > > May be, I've the error messages no longer available. I assume you log something when it happens. Do you see the log message? > > I do not believe that an I/O error is possible on a locally connected > > socket. > > But isn't this assumption at least _risky_, Ben? It isn't an assumption, it is something I believe to be true. I could doubt everything I believe to be true, I suppose. It would make programming rather hard. Actually, it would make existing rather hard. > > I would be most reluctant to fix this without evidence that it > > is actually a bug. Since this seems to be the thread for maxims, one of > > my favourites is "if you don't understand why it is broken, don't fix > > it", and I intend to stick to that. > > That's a good maxim, of course. > But always do good prevention is another good maxim, too ;-) I do. That's why I back my assumption up with an assertion. The assertion is not intended to catch a condition I believe will ever occur in normal operation. It is a symptom that something is wrong. Isn't this where we came in? Cheers, Ben. -- Ben Laurie|Phone: +44 (181) 735 0686| Apache Group member Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/ and Technical Director|Email: [EMAIL PROTECTED] | A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/ London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/ __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [apache-ssl] Assertions considered bad!? (was: Re: [apache-ssl] Invalid method in request)
On Sat, Oct 31, 1998, Ben Laurie wrote: > >[...] > > | nRead=saferead(nFD,&usLength,sizeof usLength); > > | assert(nRead == sizeof usLength); > > > > Here the assert makes sure that really the requested number of bytes are read. > > But when an I/O error or some other communication problem occurs the actual > > number of read bytes can be different. Then the gcache process falls down. > > And I've seen exactly gcache exits with this assertion on my boxes (Solaris > > 2.6) while I was mostly sure that no personal attacker was involved. Instead > > I really assume it was just some I/O communication error... > > This is exactly where it failed when gcache was crashing because of a > bug. Could it be that you assumed there was a network error instead? > Since gcache was fixed I have had no reports of this assertion failing. May be, I've the error messages no longer available. > I do not believe that an I/O error is possible on a locally connected > socket. But isn't this assumption at least _risky_, Ben? > I would be most reluctant to fix this without evidence that it > is actually a bug. Since this seems to be the thread for maxims, one of > my favourites is "if you don't understand why it is broken, don't fix > it", and I intend to stick to that. That's a good maxim, of course. But always do good prevention is another good maxim, too ;-) You know: Just because one knows that on a one-way street cars can come only from one side doesn't mean it isn't a good approach to look at both sides before crossing the street... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [apache-ssl] Assertions considered bad!? (was: Re: [apache-ssl] Invalid method in request)
Ralf S. Engelschall wrote: > > On Sat, Oct 31, 1998, Ben Laurie wrote: > > > Ralf S. Engelschall wrote: > > > H??? Do you mean it cannot occur in practice? Or do I misunderstand you > > > here. As I said: We not even need an attacker: When an I/O read error occurs > > > for gcache it already falls down. So the DoS attacker is just the worst case. > > > > Aha. Now we get down to it. OK, please describe how an I/O error can > > occur on a locally connected socket. > > How it actually can occur I don't know. Depends on the platform, I think. But > in general I don't think that Unix guarantees that a TCP connection to > localhost always can be performed without any problems. I've no actual > scenario of an I/O communication error at hand, but I've at least the code > parts at hand which then could fail: > > | nRead=saferead(nFD,&usLength,sizeof usLength); > | assert(nRead == sizeof usLength); > > Here the assert makes sure that really the requested number of bytes are read. > But when an I/O error or some other communication problem occurs the actual > number of read bytes can be different. Then the gcache process falls down. > And I've seen exactly gcache exits with this assertion on my boxes (Solaris > 2.6) while I was mostly sure that no personal attacker was involved. Instead > I really assume it was just some I/O communication error... This is exactly where it failed when gcache was crashing because of a bug. Could it be that you assumed there was a network error instead? Since gcache was fixed I have had no reports of this assertion failing. I do not believe that an I/O error is possible on a locally connected socket. I would be most reluctant to fix this without evidence that it is actually a bug. Since this seems to be the thread for maxims, one of my favourites is "if you don't understand why it is broken, don't fix it", and I intend to stick to that. Cheers, Ben. -- Ben Laurie|Phone: +44 (181) 735 0686| Apache Group member Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/ and Technical Director|Email: [EMAIL PROTECTED] | A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/ London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/ __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [apache-ssl] Assertions considered bad!? (was: Re: [apache-ssl] Invalid method in request)
On Sat, Oct 31, 1998, Ben Laurie wrote: > Ah, I also forgot to mention that an attacker with the ability to talk > to gcache can completely screw you with just legitimate messages - by > poisoning your cache. They can presumably also get access to session > keys. So, if anyone can talk to gcache apart from Apache-SSL, you've had > it anyway. Correct, of course. Nevertheless we shouldn't accept the assertion problems (the exit) just because in the worst case there can be even more bad things happen at other edges. Because my opinion is that I/O errors or other non-attacker-based invalid input occurs at least as often than attacker-based invalid input. So we should take care of them, too. And one way to take care of them is to make sure that the processes don't fall down. And here not using assertions _at least_ for those I/O related things sounds very reasonable to me. Ben, you don't have to eliminate all assertions, of course. Some of them can be ok. But the I/O related ones should be replaced by different error checking code... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [apache-ssl] Assertions considered bad!? (was: Re: [apache-ssl] Invalid method in request)
On Sat, Oct 31, 1998, Ben Laurie wrote: > Ralf S. Engelschall wrote: > > H??? Do you mean it cannot occur in practice? Or do I misunderstand you > > here. As I said: We not even need an attacker: When an I/O read error occurs > > for gcache it already falls down. So the DoS attacker is just the worst case. > > Aha. Now we get down to it. OK, please describe how an I/O error can > occur on a locally connected socket. How it actually can occur I don't know. Depends on the platform, I think. But in general I don't think that Unix guarantees that a TCP connection to localhost always can be performed without any problems. I've no actual scenario of an I/O communication error at hand, but I've at least the code parts at hand which then could fail: | nRead=saferead(nFD,&usLength,sizeof usLength); | assert(nRead == sizeof usLength); Here the assert makes sure that really the requested number of bytes are read. But when an I/O error or some other communication problem occurs the actual number of read bytes can be different. Then the gcache process falls down. And I've seen exactly gcache exits with this assertion on my boxes (Solaris 2.6) while I was mostly sure that no personal attacker was involved. Instead I really assume it was just some I/O communication error... > > > BTW, I'm not claiming that I can defend every piece of code I've ever > > > written. If I've got it wrong, I'm keen to hear about it, especially if > > > accompanied by patches. Where I draw the line is with statements like > > > "assertions are inherently bad". > > > > I didn't say this. I said you're right that assertions are not bad in general. > > But any I/O or input related assertions are bad IMHO. And the patch is > > available, of course: diff gcache.c ssl_gcache.c, diff gcacheclient.c > > ssl_gcacheclient.c, diff gcachecommon.c ssl_gcachecommon.c. > > This is far to general a criterion. Some kinds of I/O are completely > deterministic (given correct code). I agree that to assert on user input > is not a brilliant idea, but on a tightly linked client/server pair, it > seems to me no different to asserting on the value of a parameter. Yes, it may be a little bit too general criterion. But implemented parameter variants depend only on the actually used parameter variants (all used variants should be implemented). But no one can externally inject other parameter variants into the code. While on I/O related things the used things depend on the actually received data under runtime. Here replacing assertions with normal error checks and error code returns seems more reasonable. > > > I'll also admit that my coding style is more biased towards defending > > > against programmer error than attackers, but it is programmer errors > > > that attackers exploit, of course. > > > > As I said: As long as the assertions are not I/O or input related they are ok. > > But they are very problematic for a production system when they depend on > > input coming from external sources. > > And the external source in this case is? The external source is the request data which comes in through the socket. Sure, usually this source is the gcache client code. But as we already discovered in the worst case this could also be a real attacker. Greetings, Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [apache-ssl] Assertions considered bad!? (was: Re: [apache-ssl] Invalid method in request)
Ah, I also forgot to mention that an attacker with the ability to talk to gcache can completely screw you with just legitimate messages - by poisoning your cache. They can presumably also get access to session keys. So, if anyone can talk to gcache apart from Apache-SSL, you've had it anyway. Cheers, Ben. -- Ben Laurie|Phone: +44 (181) 735 0686| Apache Group member Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/ and Technical Director|Email: [EMAIL PROTECTED] | A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/ London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/ __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [apache-ssl] Assertions considered bad!? (was: Re: [apache-ssl] Invalid method in request)
Ralf S. Engelschall wrote: > H??? Do you mean it cannot occur in practice? Or do I misunderstand you > here. As I said: We not even need an attacker: When an I/O read error occurs > for gcache it already falls down. So the DoS attacker is just the worst case. Aha. Now we get down to it. OK, please describe how an I/O error can occur on a locally connected socket. > > BTW, I'm not claiming that I can defend every piece of code I've ever > > written. If I've got it wrong, I'm keen to hear about it, especially if > > accompanied by patches. Where I draw the line is with statements like > > "assertions are inherently bad". > > I didn't say this. I said you're right that assertions are not bad in general. > But any I/O or input related assertions are bad IMHO. And the patch is > available, of course: diff gcache.c ssl_gcache.c, diff gcacheclient.c > ssl_gcacheclient.c, diff gcachecommon.c ssl_gcachecommon.c. This is far to general a criterion. Some kinds of I/O are completely deterministic (given correct code). I agree that to assert on user input is not a brilliant idea, but on a tightly linked client/server pair, it seems to me no different to asserting on the value of a parameter. > > I'll also admit that my coding style is more biased towards defending > > against programmer error than attackers, but it is programmer errors > > that attackers exploit, of course. > > As I said: As long as the assertions are not I/O or input related they are ok. > But they are very problematic for a production system when they depend on > input coming from external sources. And the external source in this case is? Cheers, Ben. -- Ben Laurie|Phone: +44 (181) 735 0686| Apache Group member Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/ and Technical Director|Email: [EMAIL PROTECTED] | A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/ London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/ __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [apache-ssl] Assertions considered bad!? (was: Re: [apache-ssl] Invalid method in request)
On Fri, Oct 30, 1998, Ben Laurie wrote: > Ralf S. Engelschall wrote: > > And now I ask me why _isn't_ this better? I don't understand it, Ben. IMHO > > this non-assertion way _is_ better, because it prevents the system from being > > dropped down (kind of DoS) by a local attacker > > I'm happy to admit that is is a marginal improvement wrt a local > attacker, but I can't see that it makes a significant difference to your > defences against a local attacker, for the following reasons: > > 1. You should be using a UNIX domain socket. With appropriate > permissions, this cannot be exploited as described. Correct, then you need at least gained access to the UID of the httpd processes. But you know that mostly all Apache-SSL and mod_ssl users are using TCP sockets with gcache because this was the default configuration for years. You changed it in Apache-SSL only _recently_, Ben. > 2. The local attacker can DoS you trivially simply by overloading the > HTTP/HTTPS port. That's not really trivially IMHO, but ok. Accepted. Nevertheless: just because there are other DoS possibilities doesn't mean we can ignore the gcache related ones. Actually we don't talk about gcache vs. httpd. We talk about assertions which are used inside gcache and httpd in general. Because just sending gcache an incorrect request is not the only way you can let it fall down, of course. There are other I/O related assertions. For instance when you break the communication while sending data it fall down, too. > 3. On most OSes a local attacker can kill you anyway in many othe ways. Sure, but again: Just because of this we cannot say I/O-related assertions are then ok. > 4. No secure server should have local attackers. "should", yes > The downside is that, in the event of a remote attack that makes Apache > behave incorrectly, you will continue to run. Whether it is worth > defending against a local attacker (given that if you even have one, > you've got a serious problem) rather than against the (rather more > likely) remote attacker is a difficult question. So, on balance, I can't > answer the question "is it better?". All I can say is that it is > different, and addresses a different threat model. My threat model says > that if I've got a local attacker, I've already lost, so that makes my > solution better. I don't know what your threat model is, so I can't tell > what your evaluation will be (except I can guess it won't favour me). My threat model is that a server process should never just die because of bogus external input, independent whether the input comes from remote or local host. All the time error checks should apply and correctly deny access without DoS problems. > The bottom line is that neither of our solutions should ever be > exercised, so the relative merit is largely academic. H??? Do you mean it cannot occur in practice? Or do I misunderstand you here. As I said: We not even need an attacker: When an I/O read error occurs for gcache it already falls down. So the DoS attacker is just the worst case. > BTW, I'm not claiming that I can defend every piece of code I've ever > written. If I've got it wrong, I'm keen to hear about it, especially if > accompanied by patches. Where I draw the line is with statements like > "assertions are inherently bad". I didn't say this. I said you're right that assertions are not bad in general. But any I/O or input related assertions are bad IMHO. And the patch is available, of course: diff gcache.c ssl_gcache.c, diff gcacheclient.c ssl_gcacheclient.c, diff gcachecommon.c ssl_gcachecommon.c. > I'll also admit that my coding style is more biased towards defending > against programmer error than attackers, but it is programmer errors > that attackers exploit, of course. As I said: As long as the assertions are not I/O or input related they are ok. But they are very problematic for a production system when they depend on input coming from external sources. Greetings, Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [apache-ssl] Assertions considered bad!? (was: Re: [apache-ssl] Invalid method in request)
Ralf S. Engelschall wrote: > And now I ask me why _isn't_ this better? I don't understand it, Ben. IMHO > this non-assertion way _is_ better, because it prevents the system from being > dropped down (kind of DoS) by a local attacker I'm happy to admit that is is a marginal improvement wrt a local attacker, but I can't see that it makes a significant difference to your defences against a local attacker, for the following reasons: 1. You should be using a UNIX domain socket. With appropriate permissions, this cannot be exploited as described. 2. The local attacker can DoS you trivially simply by overloading the HTTP/HTTPS port. 3. On most OSes a local attacker can kill you anyway in many othe ways. 4. No secure server should have local attackers. The downside is that, in the event of a remote attack that makes Apache behave incorrectly, you will continue to run. Whether it is worth defending against a local attacker (given that if you even have one, you've got a serious problem) rather than against the (rather more likely) remote attacker is a difficult question. So, on balance, I can't answer the question "is it better?". All I can say is that it is different, and addresses a different threat model. My threat model says that if I've got a local attacker, I've already lost, so that makes my solution better. I don't know what your threat model is, so I can't tell what your evaluation will be (except I can guess it won't favour me). The bottom line is that neither of our solutions should ever be exercised, so the relative merit is largely academic. BTW, I'm not claiming that I can defend every piece of code I've ever written. If I've got it wrong, I'm keen to hear about it, especially if accompanied by patches. Where I draw the line is with statements like "assertions are inherently bad". I'll also admit that my coding style is more biased towards defending against programmer error than attackers, but it is programmer errors that attackers exploit, of course. Cheers, Ben. -- Ben Laurie|Phone: +44 (181) 735 0686| Apache Group member Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/ and Technical Director|Email: [EMAIL PROTECTED] | A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/ London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/ __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [apache-ssl] Assertions considered bad!? (was: Re: [apache-ssl] Invalid method in request)
On Fri, Oct 30, 1998, Marc Slemko wrote: > On Fri, 30 Oct 1998, Ralf S. Engelschall wrote: > > > So on a typical system an attacker who gained access to _any_ account (not > > necessarily the UID of the httpd or the gcache process) can simply dropping > > down gcache and this way all httpds by just sending garbage to the gcache > > port. > > What does gcache do? What does someone gain by being able to gain > access to it? Can they do anything beyond DoS attacks? No, but the DoS attack is already a nasty enough problem. > > | rse@en1:/e/apache/SSL/SRC/mod_ssl-2.0/pkg.apache/src/modules/ssl > > | :> ./ssl_gcache rse 12346 & > > | [1] 29897 > > | [Fri Oct 30 22:35:43 1998] ssl_gcache: started > > | rse@en1:/e/apache/SSL/SRC/mod_ssl-2.0/pkg.apache/src/modules/ssl > > | :> ps -ax | grep ssl_gcache > > | 306 ?? I 0:00.03 ssl_gcache 65534 12345 > > | 29897 p0 S 0:00.02 ./ssl_gcache rse 12346 > > | rse@en1:/e/apache/SSL/SRC/mod_ssl-2.0/pkg.apache/src/modules/ssl > > | :> echo "hello" | socket en1 12346 > > | [Fri Oct 30 22:35:54 1998] ssl_gcache: unexpected connect from 192.76.162.40 - >ignored > > Actually, Ben's code does the exact same thing in this case. In > your previous example, you connected to localhost. Ops, sorry. My fault in cut & pasting. I pasted the wrong test. Nevertheless the fact is correct that ssl_gcache doesn't die. Here is the correct test: | :> echo "hello" | socket localhost 12346 | [Fri Oct 30 22:55:40 1998] ssl_gcache: invalid cache request | rse@en1:/e/apache/SSL/SRC/mod_ssl-2.0/pkg.apache/src/modules/ssl | :> echo "hello" | socket localhost 12346 | [Fri Oct 30 22:55:42 1998] ssl_gcache: invalid cache request | rse@en1:/e/apache/SSL/SRC/mod_ssl-2.0/pkg.apache/src/modules/ssl | :> echo "hello" | socket localhost 12346 | [Fri Oct 30 22:55:42 1998] ssl_gcache: invalid cache request | rse@en1:/e/apache/SSL/SRC/mod_ssl-2.0/pkg.apache/src/modules/ssl | :> echo "hello" | socket localhost 12346 | [Fri Oct 30 22:55:42 1998] ssl_gcache: invalid cache request | rse@en1:/e/apache/SSL/SRC/mod_ssl-2.0/pkg.apache/src/modules/ssl | :> echo "hello" | socket localhost 12346 | [Fri Oct 30 22:57:19 1998] ssl_gcache: invalid cache request | rse@en1:/e/apache/SSL/SRC/mod_ssl-2.0/pkg.apache/src/modules/ssl | :> echo "hello" | socket localhost 12346 | [Fri Oct 30 22:57:19 1998] ssl_gcache: invalid cache request | rse@en1:/e/apache/SSL/SRC/mod_ssl-2.0/pkg.apache/src/modules/ssl | :> Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [apache-ssl] Assertions considered bad!? (was: Re:[apache-ssl] Invalid method in request)
On Fri, 30 Oct 1998, Ralf S. Engelschall wrote: > So on a typical system an attacker who gained access to _any_ account (not > necessarily the UID of the httpd or the gcache process) can simply dropping > down gcache and this way all httpds by just sending garbage to the gcache > port. What does gcache do? What does someone gain by being able to gain access to it? Can they do anything beyond DoS attacks? > | rse@en1:/e/apache/SSL/SRC/mod_ssl-2.0/pkg.apache/src/modules/ssl > | :> ./ssl_gcache rse 12346 & > | [1] 29897 > | [Fri Oct 30 22:35:43 1998] ssl_gcache: started > | rse@en1:/e/apache/SSL/SRC/mod_ssl-2.0/pkg.apache/src/modules/ssl > | :> ps -ax | grep ssl_gcache > | 306 ?? I 0:00.03 ssl_gcache 65534 12345 > | 29897 p0 S 0:00.02 ./ssl_gcache rse 12346 > | rse@en1:/e/apache/SSL/SRC/mod_ssl-2.0/pkg.apache/src/modules/ssl > | :> echo "hello" | socket en1 12346 > | [Fri Oct 30 22:35:54 1998] ssl_gcache: unexpected connect from 192.76.162.40 - >ignored Actually, Ben's code does the exact same thing in this case. In your previous example, you connected to localhost. __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Assertions considered bad!? (was: Re: [apache-ssl] Invalid method in request)
In article <[EMAIL PROTECTED]> you wrote: >[...a interesting discussion on the apache-ssl list with >Ben Laurie whether assertions in server code are reasonable or not...] > > The discussion is pointless unless you can indicate a way in which it > makes Apache-SSL function incorrectly. How about this scenario: | rse@en1:/e/apache/RELEASES/apache_1.3.3/src/modules/ssl | :> ./gcache rse 12346 & | [Fri Oct 30 22:28:26 1998] ./gcache started | [1] 29497 | rse@en1:/e/apache/RELEASES/apache_1.3.3/src/modules/ssl | :> echo "hello" | socket localhost 12346 | request was 104 | assertion "!"Unknown request"" failed: file "gcache.c", line 166 | [1]+ Abort trap (core dumped) ./gcache rse 12346 | rse@en1:/e/apache/RELEASES/apache_1.3.3/src/modules/ssl | :> So on a typical system an attacker who gained access to _any_ account (not necessarily the UID of the httpd or the gcache process) can simply dropping down gcache and this way all httpds by just sending garbage to the gcache port. And although you don't want to hear this: With mod_ssl's ssl_gcache program this doesn't happen because all assertions are already replaced with check which pass error codes to the callers. | rse@en1:/e/apache/SSL/SRC/mod_ssl-2.0/pkg.apache/src/modules/ssl | :> ./ssl_gcache rse 12346 & | [1] 29897 | [Fri Oct 30 22:35:43 1998] ssl_gcache: started | rse@en1:/e/apache/SSL/SRC/mod_ssl-2.0/pkg.apache/src/modules/ssl | :> ps -ax | grep ssl_gcache | 306 ?? I 0:00.03 ssl_gcache 65534 12345 | 29897 p0 S 0:00.02 ./ssl_gcache rse 12346 | rse@en1:/e/apache/SSL/SRC/mod_ssl-2.0/pkg.apache/src/modules/ssl | :> echo "hello" | socket en1 12346 | [Fri Oct 30 22:35:54 1998] ssl_gcache: unexpected connect from 192.76.162.40 - |ignored | rse@en1:/e/apache/SSL/SRC/mod_ssl-2.0/pkg.apache/src/modules/ssl | :> echo "hello" | socket en1 12346 | [Fri Oct 30 22:35:55 1998] ssl_gcache: unexpected connect from 192.76.162.40 - |ignored | rse@en1:/e/apache/SSL/SRC/mod_ssl-2.0/pkg.apache/src/modules/ssl | :> echo "hello" | socket en1 12346 | [Fri Oct 30 22:35:55 1998] ssl_gcache: unexpected connect from 192.76.162.40 - |ignored | rse@en1:/e/apache/SSL/SRC/mod_ssl-2.0/pkg.apache/src/modules/ssl | :> echo "hello" | socket en1 12346 | [Fri Oct 30 22:35:56 1998] ssl_gcache: unexpected connect from 192.76.162.40 - |ignored | rse@en1:/e/apache/SSL/SRC/mod_ssl-2.0/pkg.apache/src/modules/ssl | :> echo "hello" | socket en1 12346 | [Fri Oct 30 22:35:56 1998] ssl_gcache: unexpected connect from 192.76.162.40 - |ignored | rse@en1:/e/apache/SSL/SRC/mod_ssl-2.0/pkg.apache/src/modules/ssl | :> ps -ax | grep ssl_gcache | 306 ?? I 0:00.03 ssl_gcache 65534 12345 | 29897 p0 S 0:00.02 ./ssl_gcache rse 12346 | rse@en1:/e/apache/SSL/SRC/mod_ssl-2.0/pkg.apache/src/modules/ssl | :> And now I ask me why _isn't_ this better? I don't understand it, Ben. IMHO this non-assertion way _is_ better, because it prevents the system from being dropped down (kind of DoS) by a local attacker Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/ Official Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
