It is impossible for a non-SSL client to speak with Apache/mod_ssl over an
SSL-enabled port.  This means that it's impossible, as well, for the
client to get the "401 Authorization Required" message, since SSL must be
established for the actual httpd to even -see- the request.

Here's the procedure:

1) Non-SSL client talks to server on SSL port, sending "GET
/ultrasecure/filename.html HTTP/1.0" or 1.1 or whatever.
2) Server expects SSL handshake, never gets it, doesn't accept the data
as a command (or, more specifically, it never counts the connection as
actually being 'open').
3) Connection hangs open until client resets it.  [Note: This could be a
Denial of Service opportunity.]

Here's what happens with an SSL-enabled client:

1) SSL client talks to server on SSL port, sends SSL handshake.
2) Server recognizes handshake, and initiates SSL.
3) After SSL is initialized, client sends "GET /ultrasecure/filename.html
HTTP/1.0".
4) Server has completed SSL initialization, counts the connection as being
'open', and accepts the command, passing it through the lower levels.
5) httpd's lower layers send output back through the secure descriptor,
going back through SSL to the client.  This can include "401 Authorization
Required" responses.
6) Client prompts user for password, submits it back to the server on
another SSL connection.
7) Server receives data, including authorization, and sends the requested
resource back to the client, also through SSL.

The problem you're describing only occurs on systems that don't require a
secure handshake to accept a connection to the lower layers that process
the request.

---
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 Tue, 18 Apr 2000 [EMAIL PROTECTED] wrote:

> Full_Name: Piet Ruyssinck
> Version: 2.6.3-1.3.12
> OS: Solaris
> Submission from: (NULL) (157.193.44.18)
> 
> 
> I have an apache 1.3.12 webserver running over SSL (via mod_ssl).  SSL,
> of course, because I'm doing Basic Authentication and I dont want my
> users' passwords to be eavesdropped upon.
> 
> Let the URL to some protected page be
> https://myhost.my.domain/topsecret/index.html
> 
> The security issue/hole here is that when you would direct your browser
> to http://myhost.my.domain:433/topsecret/index.html you will be asked
> for your credentials, which are then transmitted unencrypted (i.e. not
> over SSL).  At this point, the apache httpd will return some protocol
> mismatch error message, but this is AFTER you have sent you cleartext
> credentials.
> 
> Why would I go to this wrong URL ? I wouldn't of course.  But someone
> else (someone with the means to eavesdrop on the communication) might
> try to lure people into using this wrong URL by setting up a web page
> containing such a phony link to my site.
> 
> If I understand correctly what the software is doing, the
> server answers the regular http request with a regular http reply
> containing a 401 error.  The browser sends the basic authentication
> credentials in a second http request, again to port 443.  At that
> point the server delivers a protocol-mismatch error.
> 
> If that's what's happening, then it seems to me that it's clearly a
> bug in the server, which should have delivered the protocol-mismatch
> error on the first request, instead of demanding credentials.
> 
> 
> ______________________________________________________________________
> 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]

Reply via email to