175 lines
33 KiB
HTML
175 lines
33 KiB
HTML
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
|
|
<meta http-equiv="X-UA-Compatible" content="IE=9"/>
|
|
<meta name="generator" content="Doxygen 1.8.15"/>
|
|
<meta name="viewport" content="width=device-width, initial-scale=1"/>
|
|
<title>SSLClient: SSLClient - Arduino Library For SSL</title>
|
|
<link href="tabs.css" rel="stylesheet" type="text/css"/>
|
|
<script type="text/javascript" src="jquery.js"></script>
|
|
<script type="text/javascript" src="dynsections.js"></script>
|
|
<link href="navtree.css" rel="stylesheet" type="text/css"/>
|
|
<script type="text/javascript" src="resize.js"></script>
|
|
<script type="text/javascript" src="navtreedata.js"></script>
|
|
<script type="text/javascript" src="navtree.js"></script>
|
|
<script type="text/javascript">
|
|
/* @license magnet:?xt=urn:btih:cf05388f2679ee054f2beb29a391d25f4e673ac3&dn=gpl-2.0.txt GPL-v2 */
|
|
$(document).ready(initResizable);
|
|
/* @license-end */</script>
|
|
<link href="search/search.css" rel="stylesheet" type="text/css"/>
|
|
<script type="text/javascript" src="search/searchdata.js"></script>
|
|
<script type="text/javascript" src="search/search.js"></script>
|
|
<link href="doxygen.css" rel="stylesheet" type="text/css" />
|
|
</head>
|
|
<body>
|
|
<div id="top"><!-- do not remove this div, it is closed by doxygen! -->
|
|
<div id="titlearea">
|
|
<table cellspacing="0" cellpadding="0">
|
|
<tbody>
|
|
<tr style="height: 56px;">
|
|
<td id="projectalign" style="padding-left: 0.5em;">
|
|
<div id="projectname">SSLClient
|
|
 <span id="projectnumber">v1.1.1</span>
|
|
</div>
|
|
<div id="projectbrief">Add TLS 1.2 functionality to any network library.</div>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
<!-- end header part -->
|
|
<!-- Generated by Doxygen 1.8.15 -->
|
|
<script type="text/javascript">
|
|
/* @license magnet:?xt=urn:btih:cf05388f2679ee054f2beb29a391d25f4e673ac3&dn=gpl-2.0.txt GPL-v2 */
|
|
var searchBox = new SearchBox("searchBox", "search",false,'Search');
|
|
/* @license-end */
|
|
</script>
|
|
<script type="text/javascript" src="menudata.js"></script>
|
|
<script type="text/javascript" src="menu.js"></script>
|
|
<script type="text/javascript">
|
|
/* @license magnet:?xt=urn:btih:cf05388f2679ee054f2beb29a391d25f4e673ac3&dn=gpl-2.0.txt GPL-v2 */
|
|
$(function() {
|
|
initMenu('',true,false,'search.php','Search');
|
|
$(document).ready(function() { init_search(); });
|
|
});
|
|
/* @license-end */</script>
|
|
<div id="main-nav"></div>
|
|
</div><!-- top -->
|
|
<div id="side-nav" class="ui-resizable side-nav-resizable">
|
|
<div id="nav-tree">
|
|
<div id="nav-tree-contents">
|
|
<div id="nav-sync" class="sync"></div>
|
|
</div>
|
|
</div>
|
|
<div id="splitbar" style="-moz-user-select:none;"
|
|
class="ui-resizable-handle">
|
|
</div>
|
|
</div>
|
|
<script type="text/javascript">
|
|
/* @license magnet:?xt=urn:btih:cf05388f2679ee054f2beb29a391d25f4e673ac3&dn=gpl-2.0.txt GPL-v2 */
|
|
$(document).ready(function(){initNavTree('index.html','');});
|
|
/* @license-end */
|
|
</script>
|
|
<div id="doc-content">
|
|
<!-- window showing the filter options -->
|
|
<div id="MSearchSelectWindow"
|
|
onmouseover="return searchBox.OnSearchSelectShow()"
|
|
onmouseout="return searchBox.OnSearchSelectHide()"
|
|
onkeydown="return searchBox.OnSearchSelectKey(event)">
|
|
</div>
|
|
|
|
<!-- iframe showing the search results (closed by default) -->
|
|
<div id="MSearchResultsWindow">
|
|
<iframe src="javascript:void(0)" frameborder="0"
|
|
name="MSearchResults" id="MSearchResults">
|
|
</iframe>
|
|
</div>
|
|
|
|
<div class="PageDoc"><div class="header">
|
|
<div class="headertitle">
|
|
<div class="title"><a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> - Arduino Library For SSL </div> </div>
|
|
</div><!--header-->
|
|
<div class="contents">
|
|
<div class="textblock"><p><b><a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> requires at least 110kb flash and 8kb RAM, and will not compile otherwise. This means that most Arduino boards are not supported. Check your board's specifications before attempting to use this library.</b></p>
|
|
<p>You can also view this README in <a href="https://openslab-osu.github.io/SSLClient/html/index.html">doxygen</a>.</p>
|
|
<p><a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> is a simple library to add <a href="https://www.websecurity.symantec.com/security-topics/what-is-ssl-tls-https">TLS 1.2</a> functionality to any network library implementing the <a href="https://www.arduino.cc/en/Reference/ClientConstructor">Arduino Client interface</a>, including the Arduino <a href="https://www.arduino.cc/en/Reference/EthernetClient">EthernetClient</a> and <a href="https://www.arduino.cc/en/Reference/WiFiClient">WiFiClient</a> classes (though it is better to prefer WiFClient.connectSSL if implemented). In other words, <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> implements encrypted communication through SSL on devices that do not otherwise support it.</p>
|
|
<h2>Overview</h2>
|
|
<p>Using <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> should be similar to using any other Arduino-based Client class, since this library was developed around compatibility with <a href="https://www.arduino.cc/en/Reference/EthernetClient">EthernetClient</a>. There are a few extra things, however, that you will need to get started:</p>
|
|
<ol type="1">
|
|
<li>A board with a lot of resources (>110kb flash and >8kb RAM), and a network peripheral with a large internal buffer (>8kb). This library was tested with the <a href="https://www.adafruit.com/product/2772">Adafruit Feather M0</a> (256K flash, 32K RAM) and the <a href="https://www.adafruit.com/product/3201">Adafruit Ethernet Featherwing</a> (16kb Buffer), and we still had to modify the Arduino Ethernet library to support larger internal buffers per socket (see the <a href="#sslclient-with-ethernet">Implementation Gotchas</a>).</li>
|
|
<li>A header containing array of trust anchors, which will look like <a href="./readme/cert.h">this file</a>. These are used to verify the SSL connection later on, and without them you will be unable to use this library. Check out <a class="el" href="_trust_anchors_8md.html">this document</a> on how to generate this file for your project, and for more information about what a trust anchor is.</li>
|
|
<li>A Client class associated with a network interface. We tested this library using <a href="https://www.arduino.cc/en/Reference/EthernetClient">EthernetClient</a>, however in theory it will work for any class implementing Client.</li>
|
|
<li>An analog pin, used for generating random data at the start of the connection (see the <a href="#implementation-gotchas">Implementation Gotchas</a>).</li>
|
|
</ol>
|
|
<p>Once all those are ready, you can create a simple <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> object like this: </p><div class="fragment"><div class="line"> {C++}</div><div class="line">SSLClient<BaseClientType> client(BaseClientInstance, TAs, (size_t)TAs_NUM, AnalogPin);</div></div><!-- fragment --><p> Where:</p><ul>
|
|
<li>BaseClientType - The type of BaseClientInstance</li>
|
|
<li>BaseClientInstance - An instance of the class you are using for <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> (the class associated with the network interface, from step 3)</li>
|
|
<li>TAs - The name of the trust anchor array created in step 2. If you generated a header using the tutorial this will probably be <code>TAs</code>.</li>
|
|
<li>TAs_NUM - The number of trust anchors in TAs. If you generated a header using the tutorial this will probably be <code>TAs_NUM</code>.</li>
|
|
<li><p class="startli">AnalogPin - The analog pin to pull random data from (step 4).</p>
|
|
<p class="startli">For example, if I am using EthernetClient, a generated array of 2 trust anchors, and the analog pin A7, I would declare an <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> instance using: </p><div class="fragment"><div class="line"> {C++}</div><div class="line">SSLClient<EthernetClient> client(EthernetClient(), TAs, 2, A7);</div></div><!-- fragment --><p> Once that is setup, simply use <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> as you would the base client class: </p><div class="fragment"><div class="line"> {C++}</div><div class="line">// connect to ardiuino.cc over ssl (port 443 for websites)</div><div class="line">client.connect("www.arduino.cc", 443);</div><div class="line">// Make a HTTP request</div><div class="line">client.println("GET /asciilogo.txt HTTP/1.1");</div><div class="line">client.println("User-Agent: AdafruitFeatherM0WiFi");</div><div class="line">client.print("Host: ");</div><div class="line">client.println(server);</div><div class="line">client.println("Connection: close");</div><div class="line">client.println();</div><div class="line">client.flush();</div><div class="line">// read and print the data</div><div class="line">...</div></div><!-- fragment --><p> <b>Note</b>: <code>client.connect("www.arduino.cc", 443)</code> can take 5-15 seconds to finish. This an unavoidable consequence of the SSL protocol, and is detailed in <a href="#resources">Implementation Notes</a>.</p>
|
|
</li>
|
|
</ul>
|
|
<p>For more information on <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a>, check out the <a href="./examples">examples</a>, <a href="https://openslab-osu.github.io/SSLClient/html/index.html">API documentation</a>, or the rest of this README.</p>
|
|
<h2>How It Works</h2>
|
|
<p><a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> was created to integrate SSL seamlessly with the Arduino infrastructure, and so it does just that: implementing the brilliant <a href="https://bearssl.org/">BearSSL</a> as a proxy in front of any Arduino socket library. BearSSL is designed with low flash footprint in mind, and as a result does little verification of improper programming, relying on the developer to ensure the code is correct. Since <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> is built specifically for the Arduino ecosystem, most of the code adds those programming checks back in, making debugging a fast and simple process. The rest manages the state of BearSSL, and ensures a manageable memory footprint.</p>
|
|
<p>Additionally, the bulk of <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> is split into two components: a template class <a href="./src/SSLClient.h">SSLClient</a>, and an implementation class <a href="./src/SSLClientImpl.h">SSLClientImpl</a>. The template class serves to abstract some functions not implemented in the Arduino Client interface (such as EthernetClient::remoteIP), and the implementation class is the rest of the <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> library.</p>
|
|
<h2>Other Features</h2>
|
|
<h3>Logging</h3>
|
|
<p><a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> also allows for changing the debugging level by adding an additional parameter to the constructor: </p><div class="fragment"><div class="line"> {C++}</div><div class="line">SSLClient<EthernetClient> client(EthernetClient(), TAs, (size_t)2, A7, SSL_INFO);</div></div><!-- fragment --><p> Logging is always outputted through the <a href="https://www.arduino.cc/reference/en/language/functions/communication/serial/">Arduino Serial interface</a>, so you'll need to setup Serial before you can view the SSL logs. Log levels are enumerated in <a class="el" href="_s_s_l_client_impl_8h.html#ab658e6d84759440dbf3c890446075395" title="Level of verbosity used in logging for SSLClient.">DebugLevel</a>. The log level is set to <code>SSL_WARN</code> by default.</p>
|
|
<h3>Errors</h3>
|
|
<p>When <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> encounters an error, it will attempt to terminate the SSL session gracefully if possible, and then close the socket. Simple error information can be found from SSLClient::getWriteError(), which will return a value from the <a class="el" href="_s_s_l_client_impl_8h.html#a2c3e4bb40f36b262a5214e2da2bca9c5" title="Static constants defining the possible errors encountered.">Error</a> enum. For more detailed diagnostics, you can look at the serial logs, which will be displayed if the log level is at <code>SSL_ERROR</code> or lower.</p>
|
|
<h3>Write Buffering</h3>
|
|
<p>As you may have noticed in the documentation for <a class="el" href="class_s_s_l_client.html#a6b8ff53c10fe34aab1dc2561410f70bb">SSLClient::write</a>, calling this function does not actually write to the network. Instead, you must call <a class="el" href="class_s_s_l_client.html#a5d13fd2f32ee2ea65a1f3820f758e77e" title="Returns the number of bytes available to read from the data that has been received and decrypted.">SSLClient::available</a> or <a class="el" href="class_s_s_l_client.html#a2ee6a3134d07ca09cf61ee04d32c3d44" title="Force writing the buffered bytes from SSLClient::write to the network.">SSLClient::flush</a>, which will detect that the buffer is ready and write to the network (see <a class="el" href="class_s_s_l_client.html#a6b8ff53c10fe34aab1dc2561410f70bb">SSLClient::write</a> for details).</p>
|
|
<p>This was implemented as a buffered function because examples in Arduino libraries will often write to the network like so: </p><div class="fragment"><div class="line"> {C++}</div><div class="line">EthernetClient client;</div><div class="line">// ...</div><div class="line">// connect to ardiuino.cc over ssl (port 443 for websites)</div><div class="line">client.connect("www.arduino.cc", 443);</div><div class="line">// ...</div><div class="line">// write an http request to the network</div><div class="line">client.write("GET /asciilogo.txt HTTP/1.1\r\n");</div><div class="line">client.write("Host: arduino.cc\r\n");</div><div class="line">client.write("Connection: close\r\n");</div><div class="line">// wait for response</div><div class="line">while (!client.available()) { /* ... */ }</div><div class="line">// ...</div></div><!-- fragment --><p> Notice that every single write() call immediately writes to the network, which is fine with most network clients. With SSL, however, if we are encrypting and writing to the network every write() call, this will result in a lot of small encryption tasks. Encryption takes a lot of time and code, so to reduce the overhead of an SSL connection, <a class="el" href="class_s_s_l_client.html#a6b8ff53c10fe34aab1dc2561410f70bb">SSLClient::write</a> implicitly buffers until the developer states that they are waiting for data to be received with <a class="el" href="class_s_s_l_client.html#a5d13fd2f32ee2ea65a1f3820f758e77e" title="Returns the number of bytes available to read from the data that has been received and decrypted.">SSLClient::available</a>. A simple example can be found below:</p>
|
|
<div class="fragment"><div class="line"> {C++}</div><div class="line">SSLClient<EthernetClient> client(EthernetClient(), TAs, 2, A7);</div><div class="line">// ...</div><div class="line">// connect to ardiuino.cc over ssl (port 443 for websites)</div><div class="line">client.connect("www.arduino.cc", 443);</div><div class="line">// ...</div><div class="line">// add http request to the buffer</div><div class="line">client.write("GET /asciilogo.txt HTTP/1.1\r\n");</div><div class="line">client.write("Host: arduino.cc\r\n");</div><div class="line">client.write("Connection: close\r\n");</div><div class="line">// write the bytes to the network, then wait for response</div><div class="line">while (!client.available()) { /* ... */ }</div><div class="line">// ...</div></div><!-- fragment --><p>If you would like to trigger a network write manually without using the <a class="el" href="class_s_s_l_client.html#a5d13fd2f32ee2ea65a1f3820f758e77e" title="Returns the number of bytes available to read from the data that has been received and decrypted.">SSLClient::available</a>, you can also call <a class="el" href="class_s_s_l_client.html#a2ee6a3134d07ca09cf61ee04d32c3d44" title="Force writing the buffered bytes from SSLClient::write to the network.">SSLClient::flush</a>, which will write all data and return when finished.</p>
|
|
<h3>Session Caching</h3>
|
|
<p>As detailed in the <a href="#resources">resources section</a>, SSL handshakes take an extended period (1-4sec) to negotiate. To remedy this problem, BearSSL is able to keep a <a href="https://bearssl.org/api1.html#session-cache">SSL session cache</a> of the clients it has connected to. If BearSSL successfully resumes an SSL session, it can reduce connection time to 100-500ms.</p>
|
|
<p>In order to use SSL session resumption:</p><ul>
|
|
<li>The website you are connecting to must support it. Support is widespread, but you can verify easily using the <a href="https://www.ssllabs.com/ssltest/">SSLLabs tool</a>.</li>
|
|
<li>You must reuse the same <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> object (SSL Sessions are stored in the object itself).</li>
|
|
<li>You must reconnect to the exact same server.</li>
|
|
</ul>
|
|
<p><a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> automatically stores an IP address and hostname in each session, ensuring that if you call <code>connect("www.google.com")</code> <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> will use a IP address that recognizes the SSL session instead of another IP address associated with <code>"www.google.com"</code>. However, because some websites have multiple servers on a single IP address (github.com being an example), you may find that even if you are connecting to the same host the connection does not resume. This is a flaw in the SSL session protocol — though it has been resolved in TLS 1.3, the lack of widespread adoption of the new protocol prevents it from being used here. SSL sessions can also expire based on server criteria, which will result in a standard 4-10 second connection.</p>
|
|
<p>You can test whether or not a website can resume SSL Sessions using the <a href="./examples/Session_Example/Session_Example.ino">Session Example</a> included with this library. Because of all the confounding factors of SSL Sessions, it is generally prudent while programming to assume the session will always fail to resume.</p>
|
|
<p>SSL sessions take a lot of memory to store, so by default <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> will only store one at a time. You can change this behavior by adding the following to your <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> declaration: </p><div class="fragment"><div class="line"> {C++}</div><div class="line">SSLClient<EthernetClient, SomeNumber> client(EthernetClient(), TAs, 2, A7);</div></div><!-- fragment --><p> Where <code>SomeNumber</code> is the number of sessions you would like to store. For example this declaration can store 3 sessions: </p><div class="fragment"><div class="line"> {C++}</div><div class="line">SSLClient<EthernetClient, 3> client(EthernetClient(), TAs, 2, A7);</div></div><!-- fragment --><p> Sessions are managed internally using the SSLSession::getSession function. This function will cycle through sessions in a rotating order, allowing the session cache to continually overwrite old sessions. In general, it is a good idea to use a SessionCache size equal to the number of domains you plan on connecting to.</p>
|
|
<p>If you need to clear a session, you can do so using the SSLSession::removeSession function.</p>
|
|
<h2>Implementation Gotchas</h2>
|
|
<p>Some ideas that didn't quite fit in the API documentation.</p>
|
|
<h3><a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> with Ethernet</h3>
|
|
<p>If you are using the <a href="https://github.com/arduino-libraries/Ethernet">Arduino Ethernet library</a>, you will need to modify the library to support the large buffer sizes required by SSL (detailed in <a href="#resources">resources</a>). You can either modify the library yourself, or use <a href="https://github.com/OPEnSLab-OSU/EthernetLarge">this fork of the Ethernet library with the modification</a>. To use the fork, simply install the library using the "add a .zip library" button in Arduino, and replace <code>#include "Ethernet.h"</code> with <code>#include "EthernetLarge.h"</code> in your sketch. Alternatively if for some reason this solution does not work, you can apply the modification using the instructions below.</p>
|
|
<h4>Manual Modification</h4>
|
|
<p>First find the location of the library in the directory where Arduino is installed (<code>C:\Program Files (x86)\Arduino</code> on Windows). Inside of this directory, navigate to <code>libraries\Ethernet\src</code> (<code>C:\Program Files (x86)\Arduino\libraries\Ethernet\src</code> on Windows). Modify <code>Ethernet.h</code> to replace these lines: </p><div class="fragment"><div class="line"> {C++}</div><div class="line">...</div><div class="line">// Configure the maximum number of sockets to support. W5100 chips can have</div><div class="line">// up to 4 sockets. W5200 & W5500 can have up to 8 sockets. Several bytes</div><div class="line">// of RAM are used for each socket. Reducing the maximum can save RAM, but</div><div class="line">// you are limited to fewer simultaneous connections.</div><div class="line">#if defined(RAMEND) && defined(RAMSTART) && ((RAMEND - RAMSTART) <= 2048)</div><div class="line">#define MAX_SOCK_NUM 4</div><div class="line">#else</div><div class="line">#define MAX_SOCK_NUM 8</div><div class="line">#endif</div><div class="line"></div><div class="line">// By default, each socket uses 2K buffers inside the Wiznet chip. If</div><div class="line">// MAX_SOCK_NUM is set to fewer than the chip's maximum, uncommenting</div><div class="line">// this will use larger buffers within the Wiznet chip. Large buffers</div><div class="line">// can really help with UDP protocols like Artnet. In theory larger</div><div class="line">// buffers should allow faster TCP over high-latency links, but this</div><div class="line">// does not always seem to work in practice (maybe Wiznet bugs?)</div><div class="line">//#define ETHERNET_LARGE_BUFFERS</div><div class="line">...</div></div><!-- fragment --><p> With this: </p><div class="fragment"><div class="line"> {C++}</div><div class="line">...</div><div class="line">// Configure the maximum number of sockets to support. W5100 chips can have</div><div class="line">// up to 4 sockets. W5200 & W5500 can have up to 8 sockets. Several bytes</div><div class="line">// of RAM are used for each socket. Reducing the maximum can save RAM, but</div><div class="line">// you are limited to fewer simultaneous connections.</div><div class="line">#define MAX_SOCK_NUM 2</div><div class="line"></div><div class="line">// By default, each socket uses 2K buffers inside the Wiznet chip. If</div><div class="line">// MAX_SOCK_NUM is set to fewer than the chip's maximum, uncommenting</div><div class="line">// this will use larger buffers within the Wiznet chip. Large buffers</div><div class="line">// can really help with UDP protocols like Artnet. In theory larger</div><div class="line">// buffers should allow faster TCP over high-latency links, but this</div><div class="line">// does not always seem to work in practice (maybe Wiznet bugs?)</div><div class="line">#define ETHERNET_LARGE_BUFFERS</div><div class="line">...</div></div><!-- fragment --><p> You may need to use <code>sudo</code> or administrator permissions to make this modification. We change <code>MAX_SOCK_NUM</code> and <code>ETHERNET_LARGE_BUFFERS</code> so the Ethernet hardware can allocate a larger space for <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a>, however a downside of this modification is we are now only able to have two sockets concurrently. As most microprocessors barely have enough memory for one SSL connection, this limitation will rarely be encountered in practice.</p>
|
|
<h3>Random Data</h3>
|
|
<p>The SSL protocol requires that <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> generate some random bits before connecting with a server. BearSSL provides a random number generator but requires a <a href="https://bearssl.org/apidoc/bearssl__ssl_8h.html#a7d8e8de2afd49d6794eae02f56f81152">some entropy for a seed</a>. Normally this seed is generated by taking the microsecond time using the internal clock, however since most microcontrollers are not build with this feature another source must be found. As a simple solution, <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> uses a floating analog pin as an external source of random data, passed through to the constructor in the <code>analog_pin</code> argument. Before every connection, <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> will take the bottom byte from 16 analog reads on <code>analog_pin</code>, and combine these bytes into a 16 byte random number, which is used as a seed for BearSSL. To ensure the most random data, it is recommended that this analog pin be either floating or connected to a location not modifiable by the microcontroller (i.e. a battery voltage readout).</p>
|
|
<h3>Certificate Verification</h3>
|
|
<p><a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> uses BearSSL's <a href="https://bearssl.org/x509.html#the-minimal-engine">minimal x509 verification engine</a> to verify the certificate of an SSL connection. This engine requires the developer create a trust anchor array using values stored in trusted root certificates. Check out <a class="el" href="_trust_anchors_8md.html">this document</a> for more details on this component of <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a>.</p>
|
|
<p>BearSSL also features a <a href="https://bearssl.org/x509.html#the-known-key-engine">known certificate validation engine</a>, which only allows for a single domain in exchange for a significantly reduced resource usage (flash and CPU time). This functionality is planned to be implemented in the future.</p>
|
|
<h3>Resources</h3>
|
|
<p>The SSL protocol recommends a device support many different encryption algorithms, as well as protocols for SSL itself. The complexity of both of those components results in many medium sized components forming an extremely large whole. Additionally, most embedded processors lack the sophisticated math hardware commonly found in a modern CPU, and as a result require more instructions to create the encryption algorithms SSL requires. This not only increases size but makes the algorithms slow and memory intensive.</p>
|
|
<p>To illustrate this, I will run some tests on various domains below. I haven't yet, but I will.</p>
|
|
<p>If flash footprint is becoming a problem, there are numerous debugging strings (~3kb estimated) that can be removed from <code><a class="el" href="_s_s_l_client_8h.html">SSLClient.h</a></code>, <code><a class="el" href="_s_s_l_client_impl_8h.html">SSLClientImpl.h</a></code>, and <code><a class="el" href="_s_s_l_client_impl_8cpp.html">SSLClientImpl.cpp</a></code>. I have not figured out a way to configure compilation of these strings, so you will need to modify the library to remove them yourself.</p>
|
|
<h3>Read Buffer Overflow</h3>
|
|
<p>SSL is a buffered protocol, and since most microcontrollers have limited resources (see <a href="#resources">Resources</a>), <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> is limited in the size of its buffers. A common problem I encountered with SSL connections is buffer overflow, caused by the server sending too much data at once. This problem is caused by the microcontroller being unable to copy and decrypt data faster than it is being received, forcing some data to be discarded. This usually puts BearSSL in an unrecoverable state, forcing <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> to close the connection with a write error. If you are experiencing frequent timeout problems, this could be the reason why.</p>
|
|
<p>In order to remedy this problem, the device must be able to read the data faster than it is being received, or alternatively have a cache large enough to store the entire payload. Since SSL's encryption forces the device to read slowly, this means we must increase the cache size. Depending on your platform, there are a number of ways this can be done:</p><ul>
|
|
<li>Sometimes your communication shield will have an internal buffer, which can be expanded through the driver code. This is the case with the Arduino Ethernet library (in the form of the MAX_SOCK_NUM and ETHERNET_LARGE_BUFFERS macros), however the library must be modified for the change to take effect.</li>
|
|
<li><a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> has an internal buffer SSLClientImpl::m_iobuf, which can be expanded. BearSSL limits the amount of data that can be processed based on the stage in the SSL handshake, and so this will change will have limited usefulness.</li>
|
|
<li>In some cases, a website will send so much data that even with the above solutions, <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> will be unable to keep up (a website with a lot of HTML is an example). In these cases you will have to find another method of retrieving the data you need.</li>
|
|
<li>If none of the above are viable, it is possible to implement your own Client class which has an internal buffer much larger than both the driver and BearSSL. This would require in-depth knowledge of programming and the communication shield you are working with, as well as a microcontroller with a significant amount of RAM.</li>
|
|
</ul>
|
|
<h3>Cipher Support</h3>
|
|
<p>By default, <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> supports only TLS1.2 and the ciphers listed in <a href="./src/TLS12_only_profile.c">this file</a> under <code>suites[]</code>, and the list is relatively small to keep the connection secure and the flash footprint down. These ciphers should work for most applications, however if for some reason you would like to use an older version of TLS or a different cipher, you can change the BearSSL profile being used by <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> to an <a href="./src/bearssl/src/ssl">alternate one with support for older protocols</a>. To do this, edit <code><a class="el" href="class_s_s_l_client_impl.html#a2b0b9043c8252871272bf6ba199ab67b">SSLClientImpl::SSLClientImpl</a></code> to change these lines: </p><div class="fragment"><div class="line"> {C++}</div><div class="line">br_client_init_TLS12_only(&m_sslctx, &m_x509ctx, m_trust_anchors, m_trust_anchors_num);</div><div class="line">// comment the above line and uncomment the line below if you're having trouble connecting over SSL</div><div class="line">// br_ssl_client_init_full(&m_sslctx, &m_x509ctx, m_trust_anchors, m_trust_anchors_num);</div></div><!-- fragment --><p> to this: </p><div class="fragment"><div class="line"> {C++}</div><div class="line">// br_client_init_TLS12_only(&m_sslctx, &m_x509ctx, m_trust_anchors, m_trust_anchors_num);</div><div class="line">// comment the above line and uncomment the line below if you're having trouble connecting over SSL</div><div class="line">br_ssl_client_init_full(&m_sslctx, &m_x509ctx, m_trust_anchors, m_trust_anchors_num);</div></div><!-- fragment --><p> If for some unfortunate reason you need SSL 3.0 or SSL 2.0, you will need to modify the BearSSL profile to enable support. Check out the <a href="https://bearssl.org/api1.html#profiles">BearSSL profiles documentation</a> and I wish you the best of luck. </p>
|
|
</div></div><!-- PageDoc -->
|
|
</div><!-- contents -->
|
|
</div><!-- doc-content -->
|
|
<!-- start footer part -->
|
|
<div id="nav-path" class="navpath"><!-- id is needed for treeview function! -->
|
|
<ul>
|
|
<li class="footer">Generated by
|
|
<a href="http://www.doxygen.org/index.html">
|
|
<img class="footer" src="doxygen.png" alt="doxygen"/></a> 1.8.15 </li>
|
|
</ul>
|
|
</div>
|
|
</body>
|
|
</html>
|