W3C home > Mailing lists > Public > public-webapi@w3.org > May 2008

Re: TLS error handling in XMLHttpRequest

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
Message-ID: <20080516095414.GV181@iCoaster.does-not-exist.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:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:26 UTC