Re: [HTTPS] Thoughts on HTTPS Links rewriting

Eduardo

Some thoughts:

On (a):

1. If the end-result of HTTPS rewriting is a poor user experience  
(thanks to broken scripts, missing variables) then I think that's no  
different from transcoding in general.

2. If the end-result of this writing is an absence of security where  
it could be presumed (by end-user and content provider) previously,  
then I think it's a different matter. Retaining some security through  
use of HTTPS sounds reasonable to me, when in combination with  
warnings and offering alternatives.

On (b), it seems this is no different to any proxy operation. A  
misbehaving cache might deliver content prepared for one user to  
another one; is this situation not analogous? If so, what can we learn  
from best practices for dealing with caches?

On (c), I agree, though can't see how (5) will be reached.

On (d), I can imagine a user case. Many sites use HTTPS on simple  
login forms as gateways to the rest of the service. I'd be personally  
happy to login to Amazon, for instance, using transcoded HTTPS. I'm  
not sure I agree with the argument that this is a contrived use case.


if HTTPS rewriting leads to crappy or broken experiences, then it sounds
On 17 Nov 2008, at 14:12, Eduardo Casais wrote:

>
> A clear and thorough answer at last -- but it only addresses point  
> (d) of my message, and ignores points (a) to (c). Again:
>
> 1. We only can make signalling amongst network entities and clients  
> work. The details about whether https links should be rewritten or  
> not, and whether they should be rewritten to https or not, and  
> whether invalid certificates should be detected or not, and whether  
> rewriting should happen when the enclosing resource domain is the  
> same as the URI's or not, etc, etc, are transformation  
> implementation considerations to be left to transcoding developers.  
> We keep finding cases that the current scheme does not properly  
> handle, and I doubt we will be able to nail them down in this forum.
>
> Transcoders can pretty much disturb things regarding character  
> encodings too; we do not deal with the details on how to make it  
> right -- and we agreed this after  discussing the matter. Ditto for  
> mapping transformations to terminal characteristics. We only make  
> sure end-users are warned and can choose, and that servers can  
> detect the situation and choose to serve or not, and to block  
> transformations or not (all of which are signalling issues, not  
> transformation issues).
>
> There is no point in following a different approach for https URI  
> rewriting... I believe we can agree on this.
>
> 2. The examples you give are clear, but do not entirely address  
> point (d). As the message from Thomas Roessler (cited by François)  
> indicates, the probability that a transformation on an HTTPS- 
> accessed link will fail is greater than over a normal URI because of  
> various technical reasons.
>
> The BA.com example is an interesting one, since BA has "mobilized"  
> its site through a special platform at www.ba.com/mobile. It works  
> relatively well (the BA.com site's structure seems fairly simple and  
> appropriate for such approaches), that is, until you click on "start  
> again" in the "arrival and departures" pages. I do not know about  
> its secure portion, nor can I determine how it would operate under  
> fully automatic transcoding.
>
> The fact that operators are specifically whitelisting secure sites  
> against transformations also demonstrates the issue I raised a while  
> ago: security involves two partners, and even if end-users might  
> accept the break in security, application providers might not. Hence  
> the need for robust signalling of the presence of a transformation  
> node in the HTTP flow, to give a server the possibility to deny the  
> point-to-point connection. This is the important point; tweaking  
> HTTPS URI rewriting depending on the circumstances or  assuming that  
> the no-transform directive is the right means just do not solve the  
> problem.
>
> 3. To sum up: if the end-user, whatever the circumstances, is  
> informed and warned, and has a choice to accept a transformation  
> (whichever it is, including transforming the security properties of  
> the connection), and if the server, whatever the circumstances, is  
> informed and has a possibility to deny the transformation (whichever  
> it is, including transformations of the security properties on the  
> connection), then things are manageable. If there is no robust  
> mechanism for clients and servers to detect that something is  
> happening, and to prevent it from happening, then that is troublesome.
>
>
> E.Casais
>
>
>
>
>
>
>

--
Future Platforms Ltd
e: Tom.Hume@futureplatforms.com
t: +44 (0) 1273 819038
m: +44 (0) 7971 781422
company: www.futureplatforms.com
personal: tomhume.org

Received on Monday, 1 December 2008 10:22:24 UTC