- From: Thomas Roessler <tlr@w3.org>
- Date: Fri, 16 May 2008 11:54:14 +0200
- To: Anne van Kesteren <annevk@opera.com>
- Cc: public-webapi@w3.org, public-wsc-wg@w3.org
On 2008-05-16 10:56:50 +0200, Anne van Kesteren wrote: >> We notice that the XMLHttpRequest Last Call Working Draft >> specifies that XMLHttpRequest can be used over both HTTP and >> HTTPS, but does not specify behavior if TLS negotiation fails >> for an HTTPS URI. > This would only be the case during a man in the middle attack or > in case the server randomly generates certificates, but I suppose > it deserves a mention nonetheless :-) A server randomly generating certificates would be a neat test case for a bunch of these things. Man in the middle attacks or, for that matter, badly done captive portals, are the more likely scenarios, though. >> We can see several reasonable choices for this case: >> - XMLHttpRequest specifies that this case is treated as a generic >> network failure, and handled by the invoking script. No user >> interaction occurs, and certificate validity errors are treated as >> hard herror conditions. > I've specified this by mentioning "TLS negotiation failure" under "In case > of network errors" as per our brief F2F discussion on this matter: > http://dev.w3.org/2006/webapi/XMLHttpRequest/ >> (ACTION-444 in Web Security Context.) I would suggest to explicitly say that a failure of the server identity check (section 3.1 of RFC 2818) MUST cause the client to terminate the connection. (RFC 2818 gives a choice of either giving the user a choice or terminating the connection.) -- Thomas Roessler, W3C <tlr@w3.org>
Received on Friday, 16 May 2008 09:54:55 UTC