W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1999

Re: Upgrading to TLS Within HTTP/1.1 draft available

From: John Stracke <francis@ecal.com>
Date: Sun, 27 Jun 1999 13:58:22 +0000
Message-ID: <37762DFE.B338733D@ecal.com>
To: "Http-Wg@Hplb. Hpl. Hp. Com" <http-wg@hplb.hpl.hp.com>
Scott Lawrence wrote:

> Rohit Khare and I have revised an updated his draft on how to use the 1.1
> Upgrade header to signal a change to HTTP over TLS on the current
> connection, allowing secured operation without using a separate port.

Is this necessary? Can you use the CONNECT method instead? (I know it's not
actually defined in RFC2616--it's just reserved--but it is implemented, and
it'd be easier to codify existing practice than to come up with a new
mechanism.)

The CONNECT implementation in Apache's mod_proxy (at least, the one I'm
running, version 1.2.4) takes a host:port specifier as the Request-URI and
opens up a connection to that host:port.  (I assume that at least Netscape's
proxy server does the same thing, since Netscape Communicator works through
this proxy.) This does require a separate port on the destination machine; but,
if the destination machine is the machine processing the CONNECT, then you
don't have to worry about firewalls in the way.

Furthermore, if the server processing the CONNECT is the same process as the
secure server, it doesn't even actually have to use a loopback connection; it
can just pass the incoming connection to its TLS code.   Of course, making the
secure server a separate process is likely to be safer, since there's less
chance of information leaking across connections; in that case, the insecure
server may be able to transfer the connection to the secure server process (if
the OS allows, and if they're implemented so as to cooperate).

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
|francis@ecal.com|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/
Received on Sunday, 27 June 1999 14:59:01 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:31 EDT