RE: [HTTPS] Thoughts on HTTPS Links rewriting

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

Received on Monday, 17 November 2008 14:15:26 UTC