Re: TLS error handling in XMLHttpRequest

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