Re: ISSUE-123 - Safe Form Bar: HTTP assumptions in "no TLS" section

Phrasing a useful issue and sending it to their mailing list.
However, I suspect that, in framing that issue, we might find
ourselves answering that question.  So maybe there's some useful
discussion to be had before we go to the TAG with it.

So...  The text in question:

>The editor bar MUST NOT be enabled for exchanges that are not
>protected by TLS. If the user hits the editor bar attention key when
>visiting a site not protected by SSL, the user agent MUST present a
>message warning the user that data entered in the current form may
>be seen, or tampered with, by attackers. The user agent MUST offer
>an interaction to attempt navigating to a secure version of the
>current page. Exercising that interaction MUST navigate the browser
>to a URL constructed by changing the current page's URL scheme to a
>corresponding one that uses TLS. For example, an http: URL is
>converted to an https: URL.

Specific issues with this one:

- This phrasing is agnostic of the HTTP method that was used to
  retrieve the "current page".  If the "current page" was the result
  of an HTTP GET, then it's by definition safe to try going to the
  "equivalent" https URI.  If the "current page" was the result of a
  POST, however, then it's probably a bad idea to simply do another
  POST to a somewhat similar URI, as POST is permitted to have
  side-effects.

- There is an assumption that for any URI scheme there are
  TLS-bearing and non-TLS-bearing variants.  However, even for HTTP,
  an in-protocol upgrade mechanism has been specified.  While that
  isn't deployed, the proposed spec text is clearly at odds with
  design decisions that could be made in the design of new URI
  schemes.

- There is an assumption here that swapping the URI scheme will
  cause dereferencing of a resource which is effectively the same as
  the "current page", i.e., the URI space is assumed to be the same
  for https and http versions of the server, both running on the
  default port.

  That assumption might simply not hold: There might be multiple
  HTTPs servers listening to different ports (and responding with
  certificates for different domain names); the HTTPS server might
  run on a non-default port; the HTTP server might run on a
  non-standard port (e.g., it could be the print server on port
  631); or the server instances' path space might be different.

I'll confess to having run all of the above corner cases on a
personal web server at some point.

In short: I think this part of the proposal makes far too many
assumptions about the ways in which HTTPS-driven web servers might
be set up.

Regards,
-- 
Thomas Roessler, W3C  <tlr@w3.org>







On 2007-12-19 12:32:20 -0500, Mary Ellen Zurko wrote:
> From: Mary Ellen Zurko <Mary_Ellen_Zurko@notesdev.ibm.com>
> To: Thomas Roessler <tlr@w3.org>
> Cc: public-wsc-wg@w3.org
> Date: Wed, 19 Dec 2007 12:32:20 -0500
> Subject: ISSUE-123 - Safe Form Bar: HTTP assumptions in "no TLS" section
> X-Spam-Level: 
> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.6
> 
> > > 9) ISSUE-123 - Safe Form Bar: HTTP assumptions in "no TLS" section
> > > http://www.w3.org/2006/WSC/track/issues/123
> > > No obvious next steps. We'll figure out what they are. 
> > 
> > Probably getting some appropriate review, like, from the TAG.  It's
> > not at all clear that "simply" swapping URI schemes is a sound
> > practice to recommend.
> 
> I'd love to "save" meeting time and get to next steps asynchronously in 
> email. If a TAG review is the right next step, what's the process for 
> getting one? 
> 
>

Received on Wednesday, 19 December 2007 18:40:48 UTC