1<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>HTTP Client Security</title><link rel="stylesheet" type="text/css" href="../manual.css"><meta name="generator" content="DocBook XSL Stylesheets V1.76.1"><link rel="home" href="index.html" title="neon HTTP/WebDAV client library"><link rel="up" href="intro.html" title="Chapter 1. Introduction"><link rel="prev" href="compliance.html" title="Standards compliance"><link rel="next" href="api.html" title="Chapter 2. The neon C language interface"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">HTTP Client Security</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="compliance.html">Prev</a> </td><th width="60%" align="center">Chapter 1. Introduction</th><td width="20%" align="right"> <a accesskey="n" href="api.html">Next</a></td></tr></table><hr></div><div class="sect1" title="HTTP Client Security"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="security"></a>HTTP Client Security</h2></div></div></div><p>neon is intended to be secure against a specific threat 2 model: use of a malicious HTTP server. Under this threat model, a 3 range of attacks are possible against a client when the user (or 4 application) can be tricked into accessing an HTTP server which is 5 controlled by an attacker. This section documents various types of 6 possible attack and describes what mitigation is used in 7 neon.</p><div class="sect2" title="CPU or memory consumption attacks"><div class="titlepage"><div><div><h3 class="title"><a name="id444512"></a>CPU or memory consumption attacks</h3></div></div></div><p>neon uses fixed resource limits to prevent the following 8 attacks:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>memory/CPU consumption attack using an unbounded number 9 of response header fields</p></li><li class="listitem"><p>memory consumption attack using an unbounded length of 10 individual response header lines (or continuation 11 headers)</p></li><li class="listitem"><p>memory consumption attack against the PROPFIND code 12 using an unbounded number of properties (propstat elements) 13 per resource</p></li><li class="listitem"><p>memory consumption attack against the PROPFIND code 14 using an unbounded CDATA element in a "flat property" 15 value</p></li></ul></div><p>Memory consumption attacks against applications based on 16 neon by use of unbounded response length are also possible, but 17 must be mitigated at application level. Memory consumption in 18 neon itself is fixed and is not proportional to the response 19 size.</p><p>Test cases for all the above attacks are present in the 20 neon test suite.</p></div><div class="sect2" title="SSL/TLS connection security"><div class="titlepage"><div><div><h3 class="title"><a name="id444586"></a>SSL/TLS connection security</h3></div></div></div><p>When using a connection secured by SSL/TLS, it is necessary 21 for clients to verify that the X.509 certificate presented by the 22 server matches the server's expected identity. The algorithm 23 required for this purpose is described in RFC 2818 and RFC 3280, 24 and is implemented by neon in the following manner:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>the hostname argument passed to <a class="xref" href="refsess.html#ne_session_create">ne_session_create</a> is the expected identity of the 25 server</p></li><li class="listitem"><p>the subjectAltName extension of the certificate is used 26 for comparision against the expected identity, in preference 27 to the Subject name's commonName attribute.</p></li><li class="listitem"><p>the dNSName, iPAddress, and uniformResourceIdentifier 28 classes of GeneralName are supported in subjectAltName 29 comparison.</p></li><li class="listitem"><p>if no subjectAltName is present in the certificate, the 30 most specific commonName attribute in the Subject name is used 31 for comparison instead.</p></li></ul></div><p>In the case where a server certificate is presented that 32 does not match the expected identity (or is otherwise not 33 trusted), neon will fail the request by default. This behaviour 34 can be overridden by the use of a callback installed using <a class="xref" href="refsslvfy.html#ne_ssl_set_verify">ne_ssl_set_verify</a>, which allows the application to 35 present the certificate details to a user for manual/off-line 36 verification, if possible.</p><p>Test cases for the correctness of the implementation of the 37 identity verification algorithm are present in the neon test 38 suite.</p></div><div class="sect2" title="Control character insertion in error messages"><div class="titlepage"><div><div><h3 class="title"><a name="id445137"></a>Control character insertion in error messages</h3></div></div></div><p>Where error messages (as returned by 39 (<a class="xref" href="referr.html#ne_get_error">ne_get_error</a>) contain data supplied by the 40 server, the untrusted data is sanitised to remove both control 41 characters and non-ASCII characters. This prevents any attacks 42 where such error messages are exposed to the user and can 43 potentially distort the presentation of the interface (for 44 example, through the use of a carriage return character in a text 45 user interface).</p></div><div class="sect2" title="Attacks against authentication credentials"><div class="titlepage"><div><div><h3 class="title"><a name="id445154"></a>Attacks against authentication credentials</h3></div></div></div><p>Authentication credentials can be compromised by a 46 "downgrade attack" by an active attacker; for example, where a 47 MITM presents a Basic authentication challenge in place of the 48 server's Digest challenge. neon mitigates these attacks by 49 allowing the application (and hence, user) to specify that only a 50 specific set of authentication protocols is permitted.</p><p>neon supports the Digest and Negotiate authentication 51 schemes, which both allow authentication of users without passing 52 credentials in cleartext over the wire. The "domain" parameter is 53 supported in Digest, allowing the server to restrict an 54 authentication session to a particular set of URIs.</p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="compliance.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="intro.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="api.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Standards compliance </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 2. The neon C language interface</td></tr></table></div></body></html> 55