- From: John Stracke <francis@ecal.com>
- Date: Sun, 27 Jun 1999 13:58:22 +0000
- 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 07:01:57 UTC