- From: Willy Tarreau <w@1wt.eu>
- Date: Thu, 19 Jul 2012 22:23:49 +0200
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: Mike Belshe <mike@belshe.com>, httpbis mailing list <ietf-http-wg@w3.org>
On Thu, Jul 19, 2012 at 08:01:35PM +0000, Poul-Henning Kamp wrote: > In message <20120719184924.GM16208@1wt.eu>, Willy Tarreau writes: > > >As usual, Adam gave a nice description there, and I'm sure many of us are > >aware of the issues he describes. I'm among those who consider that having > >only some pages of a site secured is dangerous. Either the site is clear or > >it's not. > > What about sites that are HTTP until you log in, then switch to HTTPS ? > > That's a perfectly fair & sensible way to avoid spending resources > on non-paying visitors. You got one point here. I'm used to banking environments where this behaviour is not desirable at all. However, the points made by Adam are perfectly valid in your example. The risk of loading insecure JS code during the HTTP phase which sets known cookies for the HTTPS phase for instance exists. In 1999 I was suggesting that only the POST of a login page was made HTTPS. Then I realized that the page handling the form had to be secured too, and I was OK with this for a long time, until I discovered the mess some developers are facing when trying to support multiple browsers (including old ones), resulting in overly complex cookie or JS policies which commonly leads to cookies slipping between secure/ non-secure or loading http contents from https. In the end, for moderately complex sites, better be either all clear or all secure. Note that in your example, you can have a dedicated https host for the login phase, if you have an SSO relying on a token exchanged as a URI parameter using a redirect, there is no problem. And I agree it's sometimes the only solution for some of the environments where our respective products are used together to push pixels at wire speed. Regards, Willy
Received on Thursday, 19 July 2012 20:30:46 UTC