This document:Public document·View comments·Disposition of Comments·
Nearby:Mobile Web Best Practices Working Group Other specs in this tool Mobile Web Best Practices Working Group's Issue tracker
Quick access to LC-1995 LC-1996 LC-1997 LC-1998 LC-1999 LC-2000 LC-2001 LC-2002 LC-2003 LC-2004 LC-2005 LC-2006 LC-2007 LC-2008 LC-2009 LC-2010 LC-2011 LC-2012 LC-2013 LC-2014 LC-2015 LC-2016 LC-2017 LC-2018 LC-2019 LC-2020 LC-2021 LC-2022 LC-2023 LC-2024 LC-2025 LC-2026 LC-2027 LC-2028 LC-2029 LC-2030 LC-2031 LC-2032 LC-2033 LC-2034 LC-2036 LC-2037 LC-2038 LC-2039 LC-2040 LC-2041 LC-2042 LC-2043 LC-2044 LC-2045 LC-2046 LC-2047 LC-2048 LC-2049 LC-2050 LC-2051 LC-2052 LC-2053 LC-2054 LC-2064 LC-2065 LC-2066 LC-2067 LC-2068 LC-2069 LC-2070 LC-2071 LC-2072 LC-2073 LC-2074 LC-2075 LC-2076 LC-2077 LC-2078 LC-2079 LC-2080 LC-2081 LC-2082 LC-2083 LC-2084 LC-2085 LC-2089 LC-2090 LC-2091 LC-2097
Previous: LC-2085 Next: LC-2033
g) The guidelines rely upon a fundamentally flawed assumption: in the HTTPS connection, the client is the only party concerned with security, and which must take a decision as to whether to access resources over a point-to-point or end-to-end link. This is incorrect: there are actually two parties to the secure connection, client and server, both with legitimate security concerns. The server has thus as much a right to determine whether it wants to provide services over a point-to-point connection as the client. I can very well imagine that for instance banking, electronic commerce or social networking application servers may decide to sever point-to-point connections rather than providing services over them, and inform the end-user about the reasons. Unfortunately, because of the flawed assumption of the guidelines, there is strictly no way a server may reliably detect whether it is communicating over a point-to-point link or not. Consider: i. The proxy rewrites links but the replacement links must have HTTPS; hence for the server communication obviously takes place over HTTPS. ii. If the proxy preserves the HTTP header fields (such as user-agent, accept, accept-charset, etc), which is actually encouraged by the guidelines, then the proxy cannot detect that transformations may be taking place. iii. Further, the "via" HTTP header field does not constitute a proper mechanism to detect the presence of a transformation proxy, and whether HTTPS is point-to-point or end-to-end. First, the comment "http://www.w3.org/ns/ct" indicating the presence of a transformation proxy is not mandatory, as per the guidelines. Secondly, RFC2616 authorizes proxies to use a pseudonym instead of a domain name for the "received-by" part of their hop, which does not necessarily have a meaning for servers. The server is therefore not in a position to take educated decisions as to its secure communications with clients through a transformation proxy.