RE: ACTION-902 (Reprise) Summarise and prepare proposed resolutions on HTTPS link rewriting.

Hi Sean

Some comments in line

Jo

> -----Original Message-----
> From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org]
On
> Behalf Of Sean Patterson
> Sent: 19 March 2009 22:50
> To: Public MWBP
> Subject: RE: ACTION-902 (Reprise) Summarise and prepare proposed
> resolutions on HTTPS link rewriting.
> 
> I find that I am in agreement with Rob on these issues:
> 
> 1) PROPOSED RESOLUTION: Link rewriting is a form of transformation and
> at a minimum is subject to the same limitations as other forms of
> transformation
> 
> +1.  It is a transformation.
> 
> 2) PROPOSED RESOLUTION: In-network proxies MUST NOT rewrite links
> without explicit prior agreement from the Content Provider
> 
> -1.  It's not practical to get explicit permission from content
> providers to do transformations.  It is too much effort and doesn't
> scale.

Rob makes the point that link rewriting is needed in some circumstances
and that it is a somewhat bogus to make a distinction between value
added proxies and in network proxies.

> 
> PROPOSED RESOLUTION: Proxies MAY rewrite links, where content
> transformation is permitted, providing that content domain origin
> distinctions are preserved by the proxy.
> 
> -1.  I don't really think this would work.  For a CT proxy that is
> rewriting URLs so that traffic gets directed to it, the URIs need to
> point to the proxy or it won't work.

Well, yes. But the point is, surely, that if this causes the same origin
measures taken by the browser to be thwarted it needs to be shown that
you are left with a secure system. If you can't show that, it's an
unsafe system and can't be recommended. If you can show it then we need
to specify how it can be shown.


> 
> 3) PROPOSED RESOLUTION: Interception of HTTPS is not permissible
> without
> consent from the user on a case by case basis
> 
> +1.  As mentioned, this is already in the document.  I agree with
> Brian's point that it needs to be possible to keep persistent user
> preferences.  Otherwise the user experience isn't good.
> 
> 4) PROPOSED RESOLUTION: Interception of HTTPS is not permissible
> without
> explicit prior agreement from the Content Provider
> 
> -1.  As with general link rewriting, it isn't practical to get
explicit
> prior agreement with enough sites to make the feature useful.  There
is
> the option of no-transform for sites that don't want HTTPS links
> rewritten.  I know there has been some discussion of the fact that a
> site doesn't always have control over where its HTTPS requests come
> from--the user could type in an HTTPS URI or there could be an HTTPS
> link from another site.  However, I think it was Sean Owen that
pointed
> out that, from a practical standpoint, the first HTTPS request is
> almost
> always for a login page.  If the site makes the login page no-
> transform,
> then there really isn't any harm from a security standpoint.  (The CT
> proxy transformed the request for the login page and that's it.  The
> user will be redirected by the proxy to the untransformed login page.)

I'm not sure I understand the point you are making. I think the point is
that a lot of sites make their login page HTTPS but don't put
no-transform on. I think that's different to non HTTPS pages with no
no-transform on them. In the first case the site owner has made a
conscious effort to protect security and the users privacy. It seems
reasonable to infer that this includes preventing intervention by
well-meaning third parties. Or at least it's unsafe to infer that
irrespective the HTTPS being there intervention in the communication is
condoned for any reason.

> 
> Another thing to keep in mind in regard to general link rewriting: CT
> proxies that I am familiar with process the scripts and cookies
> themselves and don't pass them down to the user's browser.  So even if
> links are rewritten to all have the same domain, the security risk is
> mitigated significantly because no scripts get passed down to the
> client
> that can try to illegitimately access frames, iframes, or cookies from
> different domains.

So as above, having recognised that an existing security mechanism is
being subverted we need to say that link rewriting is subject to
testable provisos that demonstrate that the overall security is not
being harmed. What are those tests?



> 
> Sean
> 
> 
> 
> > -----Original Message-----
> > From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org]
> On
> > Behalf Of Jo Rabin
> > Sent: Thursday, March 19, 2009 4:25 AM
> > To: Public MWBP
> > Subject: RE: ACTION-902 (Reprise) Summarise and prepare proposed
> > resolutions on HTTPS link rewriting.
> >
> > I'd like to push this subject along in preparation for the F2F.
> >
> > To re-state the points:
> >
> > 1) PROPOSED RESOLUTION: Link rewriting is a form of transformation
> and
> > at a minimum is subject to the same limitations as other forms of
> > transformation
> >
> > So far we have consensus on this.
> >
> > 2) PROPOSED RESOLUTION: In-network proxies MUST NOT rewrite links
> > without explicit prior agreement from the Content Provider
> >
> > Rob makes the (to my mind reasonable) point that this makes a number
> of
> > important operations much more difficult, if not impossible to do.
> The
> > point remains, however, that link rewriting is dangerous primarily
> > because of the assumptions about "same domain" that browsers make. I
> > think we need clear cut conformance statement about how to do this.
I
> > also agree with the point that making the distinction between
> "search"
> > proxies and Inline proxies is too complicated and I think that if
the
> > perceived vulnerabilities are addressed then there is no need for
> that
> > distinction.
> >
> > So, I wonder if it would be sufficient for us to say
> >
> > PROPOSED RESOLUTION: Proxies MAY rewrite links, where content
> > transformation is permitted, providing that content domain origin
> > distinctions are preserved by the proxy.
> >
> > e.g. when accessing content derived from example1.mobi and
> > example2.mobi, from the browser perspective these are presented as
> > distinct domains e.g. xyz.transform.com and wxy.transform.com.
> >
> > I think we also need to be clear what this means in terms of IP
> > addressing too.
> >
> > 3) PROPOSED RESOLUTION: Interception of HTTPS is not permissible
> without
> > consent from the user on a case by case basis
> >
> > This is already part of the spec and doesn't seem contentious (aside
> > from perhaps needing to be clear whether we think that it's
> permissible
> > to allow the user to express a persistent preference for that
domain,
> > site or in general).
> >
> > 4) PROPOSED RESOLUTION: Interception of HTTPS is not permissible
> without
> > explicit prior agreement from the Content Provider
> >
> > I take the point that it's impractical to gain agreement from "the
> long
> > tail". There is clearly room for a broader vocabulary of preference
> > expression on the part of Content Providers. However, such a
> vocabulary
> > does not exist today.
> >
> > Either way, I believe that absent any clear indication from a
content
> > provider that they permit rewriting of HTTPS links it is unsafe and
> > can't be described as "best practice" to do so.
> >
> > It remains an open question as to what explicit prior agreement
> consists
> > of absent any signalling mechanism. There is an associated
> conformance
> > question on this point.
> >
> > Jo
> >
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: public-bpwg-request@w3.org [mailto:public-bpwg-
> request@w3.org]
> > On
> > > Behalf Of Jo Rabin
> > > Sent: 11 March 2009 09:40
> > > To: Robert Finean
> > > Cc: Public MWBP
> > > Subject: Re: ACTION-902 Summarise and prepare proposed resolutions
> on
> > > HTTPS link rewriting.
> > >
> > > Thanks Rob
> > >
> > > Comments in-line ...
> > >
> > > Jo
> > >
> > > On 10/03/2009 16:16, Robert Finean wrote:
> > > >> Jo Rabin wrote:
> > > >>> a. PROPOSED RESOLUTION: Link rewriting is a form of
> transformation
> > > > and
> > > >>> at a minimum is subject to the same limitations as other forms
> of
> > > >>> transformation
> > > >
> > > > +1 from me too
> > > >
> > > >
> > > >>> b. PROPOSED RESOLUTION: In-network proxies MUST NOT rewrite
> links
> > > >>> without explicit prior agreement from the Content Provider
> > > >
> > > > -1 because explicit prior agreement from 50M long-tail Content
> > > Providers
> > > > won't happen. Link rewriting (HTTP and/or HTTPS) is part of
> > > adaptation
> > > > because:
> > > >  - URIs must be invented to represent browsing actions within a
> > > single
> > > > Content-Provider's URI (eg view a different sub-page; trigger a
> > > > javascript event; move from one part of a form to another where
a
> > > form
> > > > is split across sub-pages)
> > > >  - Tokenising URIs is a very effective data-compression trick
for
> > > > adapted content that dramatically improves end-user usability
> > > >
> > > > There are security implications that need to be laid out and
> > > addressed.
> > > > Those security implications are the vital issue here, not link
> > > > rewriting. Even flattening a frameset into one page for display
> on
> > an
> > > > XHTML/MP phone can raise these security questions so link
> rewriting
> > > > isn't the crux of the matter.
> > > >
> > > That seems fair enough. What I was trying to avoid, and the
crucial
> > > point to my mind, is then specifying how the security implications
> can
> > > be fixed up and how one could assess compliance with them. Ref
your
> > > earlier work on this [1], under ACTION-893, you make a number of
> > > excellent suggestions. However, I think that if compliance with
the
> > > security provisions attached to this can only be achieved through
> > > software and physical audit then we have a problem of
> normativeness,
> > > unless we are going to build such an audit into the compliance
> > > provisions. While I'd prefer to avoid this, I wouldn't personally
> rule
> > > it out. It's much preferable for compliance to be assessed by
> "opaque
> > > box" testing. I also think that Eduardo's comment at [2] 1) about
> the
> > > vulnerabilities shared by CT proxies and browsers is particularly
> > > material to this point.
> > >
> > > [1]
> http://lists.w3.org/Archives/Public/public-bpwg/2009Jan/0023.html
> > > [2]
> http://lists.w3.org/Archives/Public/public-bpwg/2009Jan/0045.html
> > >
> > > Incidentally, I am aware of an inconsistency between the "opaque
> box"
> > > normativeness and the carve out in my PROPOSED RESOLUTION relating
> to
> > > explicit prior consent from the CP, which would be hard to assess
> by
> > > such techniques.
> > >
> > > > I'm uncomfortable about one stinging rule for mobile networks
> > > > (in-network adaptation) vs out-of-scope for search partners and
> > > > distributed browsers (hosted adaptation).
> > > >
> > >
> > > I'm uncomfortable with that too. I agree with the point about
> search
> > > related transformation, but distributed browsers (which are a
> > different
> > > case, to my mind) have always been out of scope.
> > >
> > > >
> > > >>> c. PROPOSED RESOLUTION: Interception of HTTPS is not
> permissible
> > > >>> without  explicit prior agreement from the Content Provider
and
> > > >>> consent from the user on a case by case basis
> > > >
> > > > I'd suggest this resolution is split into its 2 clauses:
> > > >
> > > >  c1. PROPOSED RESOLUTION: Interception of HTTPS is not
> permissible
> > > >  without explicit prior agreement from the Content Provider
> > > >
> > > > -1 because explicit prior agreement from even 10K long-tail
> Content
> > > > Providers that use HTTPS to log in won't happen. Sean gave a few
> > > > examples that are just the tip of this iceberg.
> > >
> > > I think that's unfortunate but unavoidable. If I get Rigo's
> argument
> > > correctly, it is that when you put stuff on the Web you must
expect
> > Web
> > > like stuff to happen. So it seems to me that in the case of
> "general,
> > > non HTTPS, transformation", a content provider must expect that
> normal
> > > Web paradigms will apply, including selective display etc. etc.
> etc.
> > as
> > > discussed at length on this list. By the same argument, when you
> make
> > > content available under HTTPS your expectation is that there will
> be
> > an
> > > end-to-end connection, and so the burden of contradicting the
> > > expectation falls upon those who wish to intercept the
connections.
> > >
> > > Please note that I am invoking Rigo's point in a way that he may
> not
> > > have intended it so it would be prudent to ask him to opine on
> whether
> > > the argument is sound or not.
> > >
> > > >
> > > >  c2. PROPOSED RESOLUTION: Interception of HTTPS is not
> permissible
> > > >  without consent from the user on a case by case basis
> > > >
> > > > +1 to this clause
> > > >
> > > >
> > >
> >
>

Received on Friday, 20 March 2009 08:37:02 UTC