lmoskala/SSLClient
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Deploying to gh-pages from @ a2708d0b54d0bcb8877ca05e83f872ad26ab651e 🚀

Browse source
This commit is contained in:
prototypicalpro 2021-03-22 17:58:18 +00:00
parent f5b385bfb5
commit 3f44340431
1 changed files with 61 additions and 27 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

88
index.html
View file

@ -88,12 +88,12 @@ $(document).ready(function(){initNavTree('index.html',''); initResizable(); });
<div class="contents"> <div class="contents">
<div class="textblock"><p><a class="anchor" id="md_README"></a> <img src="https://github.com/OPEnSLab-OSU/SSLClient/workflows/CI/badge.svg" alt="CI" style="pointer-events: none;" class="inline"/></p> <div class="textblock"><p><a class="anchor" id="md_README"></a> <img src="https://github.com/OPEnSLab-OSU/SSLClient/workflows/CI/badge.svg" alt="CI" style="pointer-events: none;" class="inline"/></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> adds <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. <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 TLS seamlessly with the Arduino infrastructure using <a href="https://bearssl.org/">BearSSL</a> as an underlying TLS engine. Unlike <a href="https://github.com/arduino-libraries/ArduinoBearSSL">ArduinoBearSSL</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 completly self-contained, and does not require any additional hardware (other than a network connection).</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> adds <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. <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 TLS seamlessly with the Arduino infrastructure using <a href="https://bearssl.org/">BearSSL</a> as an underlying TLS engine. Unlike <a href="https://github.com/arduino-libraries/ArduinoBearSSL">ArduinoBearSSL</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 completly self-contained, and does not require any additional hardware (other than a network connection).</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> officially supports SAMD21, SAM3X, ESP32, TIVA C, STM32F7, and Teensy &gt;= 3.0; but it should work on any board with at least 110kb flash and 7kb RAM. SSClient does not currently support ESP8266 (see <a href="https://github.com/OPEnSLab-OSU/SSLClient/issues/5#issuecomment-569968546">this issue</a>) or AVR due to memory constraints on both platforms.</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> officially supports SAMD21, SAM3X, ESP32, TIVA C, STM32F7, and Teensy &gt;= 3.0; but it should work on any board with at least 110kB flash and 7kB RAM. SSClient does not currently support ESP8266 (see <a href="https://github.com/OPEnSLab-OSU/SSLClient/issues/5#issuecomment-569968546">this issue</a>) or AVR due to memory constraints on both platforms.</p>
<p>You can also view this README in <a href="https://openslab-osu.github.io/SSLClient/index.html">doxygen</a>.</p> <p>You can also view this README in <a href="https://openslab-osu.github.io/SSLClient/index.html">doxygen</a>.</p>
<h1>Overview</h1> <h1>Overview</h1>
<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> is similar to using any other Arduino-based Client class, as 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> <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> is similar to using any other Arduino-based Client class, as 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"> <ol type="1">
<li><b>Board and Network Peripheral</b> - Your board should have a lot of resources (&gt;110kb flash and &gt;7kb RAM), and your network peripheral should have a large internal buffer (&gt;7kb). 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><b>Board and Network Peripheral</b> - Your board should have a lot of resources (&gt;110kB flash and &gt;7kB RAM), and your network peripheral should have a large internal buffer (&gt;7kB). 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><b>Trust Anchors</b> - You will need a header containing array of trust anchors (<a href="./readme/cert.h">example</a>), which are used to verify the SSL connection later on. <b>This file must generated for every project.</b> Check out <a href="./TrustAnchors.md#generating-trust-anchors">TrustAnchors.md</a> on how to generate this file for your project, and for more information about what a trust anchor is.</li> <li><b>Trust Anchors</b> - You will need a header containing array of trust anchors (<a href="./readme/cert.h">example</a>), which are used to verify the SSL connection later on. <b>This file must generated for every project.</b> Check out <a href="./TrustAnchors.md#generating-trust-anchors">TrustAnchors.md</a> on how to generate this file for your project, and for more information about what a trust anchor is.</li>
<li><b>Network Peripheral Driver Implementing <code>Client</code></b> - Examples include <code>EthernetClient</code>, <code>WiFiClient</code>, and so on—SSLClient will run on top of any network driver exposing the <code>Client</code> interface.</li> <li><b>Network Peripheral Driver Implementing <code>Client</code></b> - Examples include <code>EthernetClient</code>, <code>WiFiClient</code>, and so on—SSLClient will run on top of any network driver exposing the <code>Client</code> interface.</li>
<li><b>Analog Pin</b> - Used for generating random data at the start of the connection (see the <a href="#implementation-gotchas">Implementation Gotchas</a>).</li> <li><b>Analog Pin</b> - Used for generating random data at the start of the connection (see the <a href="#implementation-gotchas">Implementation Gotchas</a>).</li>
@ -150,7 +150,7 @@ $(document).ready(function(){initNavTree('index.html',''); initResizable(); });
<div class="line">// wait for response</div> <div class="line">// wait for response</div>
<div class="line">while (!client.available()) { /* ... */ }</div> <div class="line">while (!client.available()) { /* ... */ }</div>
<div class="line">// ...</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#a03c7926938acd57cfc3b982edf725a86" title="Write some bytes to the SSL connection.">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#a0e775669b4a040fbd3f281dcbcd2de78" 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><!-- fragment --><p> Notice that every single <code>client.write()</code> call immediately writes to the network. This behavior is fine for most network clients; with SSL, however, it results in many small encryption tasks that consume resources. To reduce the overhead of an SSL connection, <a class="el" href="class_s_s_l_client.html#a03c7926938acd57cfc3b982edf725a86" title="Write some bytes to the SSL connection.">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#a0e775669b4a040fbd3f281dcbcd2de78" 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="fragment"><div class="line"> {C++}</div>
<div class="line">EthernetClient baseClient;</div> <div class="line">EthernetClient baseClient;</div>
<div class="line">SSLClient client(baseClient, TAs, (size_t)2, A7);</div> <div class="line">SSLClient client(baseClient, TAs, (size_t)2, A7);</div>
@ -167,15 +167,17 @@ $(document).ready(function(){initNavTree('index.html',''); initResizable(); });
<div class="line">// ...</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#a0e775669b4a040fbd3f281dcbcd2de78" 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#aaf2192a6621fdf2f89cc26a9a1584f8c" 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> </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#a0e775669b4a040fbd3f281dcbcd2de78" 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#aaf2192a6621fdf2f89cc26a9a1584f8c" 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>
<h2>Session Caching</h2> <h2>Session Caching</h2>
<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>As detailed in the <a href="#resources">resources section</a>, SSL handshakes take an extended period (1-4sec) to negotiate. 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 which can drastically reduce this time: if BearSSL successfully resumes an SSL session, connection time is typically 100-500ms.</p>
<p>In order to use SSL session resumption:</p><ul> <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>The website you are connecting to must support it. Support is widespread, and you can verify it using <a href="https://www.ssllabs.com/ssltest/">SSLLabs</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 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> <li>You must reconnect to the exact same server (detailed below).</li>
</ul> </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 the SSL session with that hostname. 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> <blockquote class="doxtable">
<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>NOTE: <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 the same SSL session for that hostname. Unfortunately some websites have multiple servers on a single IP address (github.com being an example), so you may find that even if you are connecting to the same host the connection will 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 resolved here.</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> <p>SSL sessions can also expire based on server criteria (ex. timeout), which will result in a standard 4-10 second connection. </p>
</blockquote>
<p>SSL sessions take 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">EthernetClient baseClient;</div> <div class="line">EthernetClient baseClient;</div>
<div class="line">SSLClient client(baseClient, TAs, (size_t)2, A7, SomeNumber);</div> <div class="line">SSLClient client(baseClient, TAs, (size_t)2, A7, SomeNumber);</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><!-- 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>
@ -184,7 +186,7 @@ $(document).ready(function(){initNavTree('index.html',''); initResizable(); });
</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> </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> <p>If you need to clear a session, you can do so using the SSLSession::removeSession function.</p>
<h2>mTLS</h2> <h2>mTLS</h2>
<p>As of <code>v1.6.0</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> supports <a href="https://developers.cloudflare.com/access/service-auth/mtls/">mutual TLS authentication</a>. mTLS is a varient of TLS that verifys both the server and device identities before a connection, and is commonly used in IoT protocols as a secure layer (MQTT over TLS, HTTPS over TLS, etc.).</p> <p>As of <code>v1.6.0</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> supports <a href="https://developers.cloudflare.com/access/service-auth/mtls/">mutual TLS authentication</a>. mTLS is a varient of TLS that verifies both the server and device identities before a connection, and is commonly used in IoT protocols as a secure layer (MQTT over TLS, HTTP over TLS, etc.).</p>
<p>To use mTLS with <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> you will need to a client certificate and client private key associated with the server you are attempting to connect to. Depending on your use case, you will either generate these yourself (ex. <a href="http://www.steves-internet-guide.com/creating-and-using-client-certificates-with-mqtt-and-mosquitto/">Mosquito MQTT setup</a>), or have them generated for you (ex. <a href="https://docs.aws.amazon.com/iot/latest/developerguide/create-device-certificate.html">AWS IoT Certificate Generation</a>). Given this cryptographic information, you can modify the standard <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> connection sketch to enable mTLS authentication: </p><div class="fragment"><div class="line"> {C++}</div> <p>To use mTLS with <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> you will need to a client certificate and client private key associated with the server you are attempting to connect to. Depending on your use case, you will either generate these yourself (ex. <a href="http://www.steves-internet-guide.com/creating-and-using-client-certificates-with-mqtt-and-mosquitto/">Mosquito MQTT setup</a>), or have them generated for you (ex. <a href="https://docs.aws.amazon.com/iot/latest/developerguide/create-device-certificate.html">AWS IoT Certificate Generation</a>). Given this cryptographic information, you can modify the standard <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> connection sketch to enable mTLS authentication: </p><div class="fragment"><div class="line"> {C++}</div>
<div class="line">...</div> <div class="line">...</div>
<div class="line">/* Somewhere above setup() */</div> <div class="line">/* Somewhere above setup() */</div>
@ -226,7 +228,7 @@ $(document).ready(function(){initNavTree('index.html',''); initResizable(); });
<h1>Implementation Gotchas</h1> <h1>Implementation Gotchas</h1>
<p>Some ideas that didn't quite fit in the API documentation.</p> <p>Some ideas that didn't quite fit in the API documentation.</p>
<h2><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</h2> <h2><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</h2>
<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> <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: download a zipped copy of the fork through GiThub, use the "add a .zip library" button in Arduino to install the library, 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 manually using the instructions below.</p>
<h3>Manual Modification</h3> <h3>Manual Modification</h3>
<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> <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">...</div>
@ -273,19 +275,52 @@ $(document).ready(function(){initNavTree('index.html',''); initResizable(); });
<h3>Time</h3> <h3>Time</h3>
<p>The minimal x509 verification engine requires an accurate source of time to properly verify the creation and expiration dates of a certificate. As most embedded devices do not have a reliable source of time, 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> opts to use the compilation timestamp (<a href="https://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html"><code>__DATE__</code> and <code>__TIME__</code></a>) as the "current time" during the verification process. While this approach reduces the complexity of 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>, it is inherently insecure, and can cause errors if certificates are redeployed (see <a href="https://github.com/OPEnSLab-OSU/SSLClient/issues/27">#27</a>): to accommodate these edge cases, <a class="el" href="class_s_s_l_client.html#ab285c2f5a03124558ef7f74b9f3d12ad" title="Change the time used during x509 verification to a different value.">SSLClient::setVerificationTime</a> can be used to update the timestamp before connecting, resolving the above issues.</p> <p>The minimal x509 verification engine requires an accurate source of time to properly verify the creation and expiration dates of a certificate. As most embedded devices do not have a reliable source of time, 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> opts to use the compilation timestamp (<a href="https://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html"><code>__DATE__</code> and <code>__TIME__</code></a>) as the "current time" during the verification process. While this approach reduces the complexity of 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>, it is inherently insecure, and can cause errors if certificates are redeployed (see <a href="https://github.com/OPEnSLab-OSU/SSLClient/issues/27">#27</a>): to accommodate these edge cases, <a class="el" href="class_s_s_l_client.html#ab285c2f5a03124558ef7f74b9f3d12ad" title="Change the time used during x509 verification to a different value.">SSLClient::setVerificationTime</a> can be used to update the timestamp before connecting, resolving the above issues.</p>
<h2>Resources</h2> <h2>Resources</h2>
<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>The SSL/TLS protocol recommends a device support many different encryption and handshake algorithms. The complexity of these components results in many medium-footprint algorithms forming an extremely large whole. Compilation size of the <a href="examples/EthernetHTTPS/EthernetHTTPS.ino">EthernetHTTPS</a> example in <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> <code>v1.6.11</code> for various boards is shown below:</p>
<p>To illustrate this, I will run some tests on various domains below. I haven't yet, but I will.</p> <table class="markdownTable">
<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>SSLClientImpl.h</code>, and <code>SSLClientImpl.cpp</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> <tr class="markdownTableHead">
<th class="markdownTableHeadLeft">Board </th><th class="markdownTableHeadLeft">Size </th></tr>
<tr class="markdownTableRowOdd">
<td class="markdownTableBodyLeft">Arduino Zero </td><td class="markdownTableBodyLeft"><pre>`RAM: [=== ] 33.7% (used 11052 bytes from 32768 bytes)`<br />
`Flash: [=== ] 34.7% (used 90988 bytes from 262144 bytes)`</pre> </td></tr>
<tr class="markdownTableRowEven">
<td class="markdownTableBodyLeft">Arduino Due </td><td class="markdownTableBodyLeft"><pre>`RAM: [= ] 11.7% (used 11548 bytes from 98304 bytes)`<br />
`Flash: [== ] 16.7% (used 87572 bytes from 524288 bytes)`</pre> </td></tr>
<tr class="markdownTableRowOdd">
<td class="markdownTableBodyLeft">Adafruit Feather M0 </td><td class="markdownTableBodyLeft"><pre>`RAM: [==== ] 40.4% (used 13240 bytes from 32768 bytes)`<br />
`Flash: [==== ] 40.0% (used 104800 bytes from 262144 bytes)`</pre> </td></tr>
<tr class="markdownTableRowEven">
<td class="markdownTableBodyLeft">ESP32 (Lolin32) </td><td class="markdownTableBodyLeft"><pre>`RAM: [= ] 6.9% (used 22476 bytes from 327680 bytes)`<br />
`Flash: [== ] 24.0% (used 314956 bytes from 1310720 bytes)`</pre> </td></tr>
<tr class="markdownTableRowOdd">
<td class="markdownTableBodyLeft">Teensy 3.0 </td><td class="markdownTableBodyLeft"><pre>`RAM: [======== ] 78.2% (used 12812 bytes from 16384 bytes)`<br />
`Flash: [======== ] 79.8% (used 104532 bytes from 131072 bytes)`</pre> </td></tr>
<tr class="markdownTableRowEven">
<td class="markdownTableBodyLeft">Teensy 3.1 </td><td class="markdownTableBodyLeft"><pre>`RAM: [== ] 19.9% (used 13020 bytes from 65536 bytes)`<br />
`Flash: [==== ] 40.6% (used 106332 bytes from 262144 bytes)`</pre> </td></tr>
<tr class="markdownTableRowOdd">
<td class="markdownTableBodyLeft">Teensy 3.5 </td><td class="markdownTableBodyLeft"><pre>`RAM: [ ] 5.0% (used 12996 bytes from 262136 bytes)`<br />
`Flash: [== ] 20.1% (used 105476 bytes from 524288 bytes)`</pre> </td></tr>
<tr class="markdownTableRowEven">
<td class="markdownTableBodyLeft">Teensy 3.6 </td><td class="markdownTableBodyLeft"><pre>`RAM: [ ] 5.0% (used 13060 bytes from 262144 bytes)`<br />
`Flash: [= ] 10.2% (used 106828 bytes from 1048576 bytes)`</pre> </td></tr>
<tr class="markdownTableRowOdd">
<td class="markdownTableBodyLeft">Teensy 4.0 </td><td class="markdownTableBodyLeft"><pre>`RAM: [=== ] 25.9% (used 135860 bytes from 524288 bytes)`<br />
`Flash: [= ] 5.7% (used 115344 bytes from 2031616 bytes)`</pre> </td></tr>
</table>
<p>In addition to the above, most embedded processors lack the sophisticated math hardware commonly found in a modern CPU, which results in slow and memory intensive execution of these algorithms. Because of this, it is recommended 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> have 8kb of memory available on the stack during a connection, and 4-10 seconds should be allowed for the connection to complete. Note that this requirement is based on the SAMD21—more powerful processors (such as the ESP32) will see faster connection times.</p>
<blockquote class="doxtable">
<p>NOTE: 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>SSLClientImpl.h</code>, and <code>SSLClientImpl.cpp</code>. Unfortunately 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>
</blockquote>
<h2>Read Buffer Overflow</h2> <h2>Read Buffer Overflow</h2>
<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>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> <p>In order to remedy this problem, the device must be able to read the data faster than it is being received or have a cache large enough to store the entire payload. Since the device is typically already reading as fast as it can, we must increase the cache size in order to resolve this issue. 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>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 <code>MAX_SOCK_NUM</code> and <code>ETHERNET_LARGE_BUFFERS</code> macros show <a href="#manual-modification">here</a>), but mileage may vary with other drivers.</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 SSLClient::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><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 SSLClient::m_iobuf which can be expanded. Unfortunately, BearSSL limits the amount of data that can be put into the buffer based on the stage in the SSL handshake, and so increasing the buffer 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>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. 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> <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 implementation would require in-depth knowledge of communication shield you are working with and a microcontroller with a significant amount of RAM, but would be the most robust solution available.</li>
</ul> </ul>
<h2>Cipher Support</h2> <h2>Cipher Support</h2>
<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/ssl_client_full.c">alternate one with support for older protocols</a>. To do this, edit <code>SSLClientImpl::SSLClientImpl</code> to change these lines: </p><div class="fragment"><div class="line"> {C++}</div> <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/ssl_client_full.c">alternate one with support for older protocols</a>. To do this, edit <code>SSLClientImpl::SSLClientImpl</code> to change these lines: </p><div class="fragment"><div class="line"> {C++}</div>
<div class="line">br_client_init_TLS12_only(&amp;m_sslctx, &amp;m_x509ctx, m_trust_anchors, m_trust_anchors_num);</div> <div class="line">br_client_init_TLS12_only(&amp;m_sslctx, &amp;m_x509ctx, m_trust_anchors, m_trust_anchors_num);</div>
<div class="line">// comment the above line and uncomment the line below if you&#39;re having trouble connecting over SSL</div> <div class="line">// comment the above line and uncomment the line below if you&#39;re having trouble connecting over SSL</div>
<div class="line">// br_ssl_client_init_full(&amp;m_sslctx, &amp;m_x509ctx, m_trust_anchors, m_trust_anchors_num);</div> <div class="line">// br_ssl_client_init_full(&amp;m_sslctx, &amp;m_x509ctx, m_trust_anchors, m_trust_anchors_num);</div>
@ -295,15 +330,14 @@ $(document).ready(function(){initNavTree('index.html',''); initResizable(); });
<div class="line">br_ssl_client_init_full(&amp;m_sslctx, &amp;m_x509ctx, m_trust_anchors, m_trust_anchors_num);</div> <div class="line">br_ssl_client_init_full(&amp;m_sslctx, &amp;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><!-- 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>
<h2>Security</h2> <h2>Security</h2>
<p>Unlike BearSSL, <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 not rigorously vetted to be secure. If your project has security requirements, I recommend you utilize BearSSL directly.</p> <p>Unlike BearSSL, <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 not rigorously vetted to be secure. If your project has security requirements I recommend you utilize BearSSL directly.</p>
<h2>Known Issues</h2> <h2>Known Issues</h2>
<ul> <ul>
<li>In some drivers (Ethernet), calls to <code>Client::flush</code> will hang if internet is available but there is no route to the destination. Unfortunately <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> cannot correct for this without modifying the driver itself, and as a result the recommended solution is ensuring you choose a driver with built-in timeouts to prevent freezing. <a href="https://github.com/OPEnSLab-OSU/SSLClient/issues/13#issuecomment-643855923">More information here</a>.</li> <li>In some drivers (Ethernet), calls to <code>Client::flush</code> will hang if internet is available but there is no route to the destination. Unfortunately <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> cannot correct for this without modifying the driver itself, and as a result the recommended solution is ensuring you choose a driver with built-in timeouts to prevent freezing. <a href="https://github.com/OPEnSLab-OSU/SSLClient/issues/13#issuecomment-643855923">More information here</a>.</li>
<li>When using PubSubClient on the ESP32, a stack overflow will occur if the user does not flush the buffer immediately after writing. The cause of this issue is under active investigation. More information in issue <a href="https://github.com/OPEnSLab-OSU/SSLClient/issues/9">https://github.com/OPEnSLab-OSU/SSLClient/issues/9</a>.</li> <li>Previous to <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> <code>v1.6.7</code>, calls to <code><a class="el" href="class_s_s_l_client.html#ad8ed697371748e31e01c3f697bc36cbe" title="Close the connection.">SSLClient::stop</a></code> would sometimes hang the device. More information in issue <a href="https://github.com/OPEnSLab-OSU/SSLClient/issues/13">https://github.com/OPEnSLab-OSU/SSLClient/issues/13</a>.</li>
<li>Previous to <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> v1.6.7, calls to <code><a class="el" href="class_s_s_l_client.html#ad8ed697371748e31e01c3f697bc36cbe" title="Close the connection.">SSLClient::stop</a></code> would sometimes hang the device. More information in issue <a href="https://github.com/OPEnSLab-OSU/SSLClient/issues/13">https://github.com/OPEnSLab-OSU/SSLClient/issues/13</a>.</li> <li>Previous to <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> <code>v1.6.6</code>, calls to <code><a class="el" href="class_s_s_l_client.html#ab97c0745f65a6c6009ac938b3b9912c3" title="Connect over SSL to a host specified by an IP address.">SSLClient::connect</a></code> would fail if the driver indicated that a socket was already opened (<code>Client::connected</code> returned true). This behavior created unintentional permanent failures when <code>Client::stop</code> would fail to close the socket, and as a result was downgraded to a warning in v1.6.6.</li>
<li>Previous to <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> v1.6.6, calls to <code><a class="el" href="class_s_s_l_client.html#ab97c0745f65a6c6009ac938b3b9912c3" title="Connect over SSL to a host specified by an IP address.">SSLClient::connect</a></code> would fail if the driver indicated that a socket was already opened (<code>Client::connected</code> returned true). This behavior created unintentional permanent failures when <code>Client::stop</code> would fail to close the socket, and as a result was downgraded to a warning in v1.6.6.</li> <li>Previous to <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> <code>v1.6.3</code>, calling <code><a class="el" href="class_s_s_l_client.html#a03c7926938acd57cfc3b982edf725a86" title="Write some bytes to the SSL connection.">SSLClient::write</a></code> with more than 2kB of total data before flushing the write buffer would cause a buffer overflow.</li>
<li>Previous to <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> v1.6.3, calling <code><a class="el" href="class_s_s_l_client.html#a03c7926938acd57cfc3b982edf725a86" title="Write some bytes to the SSL connection.">SSLClient::write</a></code> with more than 2Kb of total data before flushing the write buffer would cause a buffer overflow.</li> <li>Previous to <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> <code>v1.6.11</code>, <code><a class="el" href="class_s_s_l_client.html#a03c7926938acd57cfc3b982edf725a86" title="Write some bytes to the SSL connection.">SSLClient::write</a></code> would sometimes call <code>br_ssl_engine_sendapp_ack</code> with zero bytes, which resulted in a variety of issues including (but not limited to) and infinite recursion loop on the esp32 (<a href="https://github.com/OPEnSLab-OSU/SSLClient/issues/9">#9</a>, <a href="https://github.com/OPEnSLab-OSU/SSLClient/issues/30">#30</a>). </li>
<li>Previous to <a class="el" href="class_s_s_l_client.html" title="The main SSLClient class. Check out README.md for more info.">SSLClient</a> v1.6.11, <code><a class="el" href="class_s_s_l_client.html#a03c7926938acd57cfc3b982edf725a86" title="Write some bytes to the SSL connection.">SSLClient::write</a></code> would sometimes call <code>br_ssl_engine_sendapp_ack</code> with zero bytes, which resulted in a variety of issues including (but not limited to) and infinite recursion loop on the esp32 ( <a href="https://github.com/OPEnSLab-OSU/SSLClient/issues/9">#9</a>, <a href="https://github.com/OPEnSLab-OSU/SSLClient/issues/30">#30</a>). </li>
</ul> </ul>
</div></div><!-- PageDoc --> </div></div><!-- PageDoc -->
</div><!-- contents --> </div><!-- contents -->