- From: Julien Pierre <jpierre@netscape.com>
- Date: Thu, 04 May 2000 18:35:14 -0700
- To: Scott Lawrence <lawrence@agranat.com>
- Cc: Rohit Khare <rohit@uci.edu>, IETF HTTP List <http-wg@hplb.hpl.hp.com>
- Message-ID: <39122552.AE0CAA7B@netscape.com>
Hi, Scott Lawrence wrote: > > From: Julien Pierre > > > I don't think users will waste their time filling forms > > if they are not ahead of > > time certain that it will be transmitted securely. > > If they are that concerned about it, then they should not fill out > forms that were not delivered securely. If the form was delivered > over an unsecured connection, it may have been modified in any > number of ways to subvert the apparent intent of the form. Browsers > don't normally expose the ACTION attribute of a form - an attacker > may have changed that, or modified field names - the possibilities > are endless. Encrypting one exchange in a multiple exchange > transaction is no security at all. OK, assume the form was delivered on a secure server. Then it gets submitted to somebody else - a virtual host on a payment processing server - to actually process the transaction. This is very common. The action URL will use regular http . How does the security upgrade get triggered ? One more thing to consider : Let's say you are browsing a site and the connection got upgraded to TLS . Then you sit idle for a while, and your keep-alive connection times out. You are on a different part of the site now, filled with normal http:// links. You click on one. The client has to reconnect. How does the security get restored ? > > > The duplicate TCP port number issue is IMHO less of a > > problem because it is rare > > to exhaust all 2**16 possible TCP ports on a server. > > The concern is with the well-known ports - a much much smaller > space. > > -- > Scott Lawrence Director of R & D <lawrence@agranat.com> > Agranat Systems Embedded Web Technology http://www.agranat.com/ -- for a good time, try kill -9 -1
Received on Thursday, 4 May 2000 18:37:39 UTC