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 <[EMAIL PROTECTED]>