* Allow cipher specification for BearSSL
BearSSL has many more ciphers than axTLS, but they are more compute intensive
and slower. Add an option to use only the same, limited security, axTLS ciphers
as well as allow users to specify any suite of ciphers they want using standard
BearSSL formats.
Fixes#5110
* Rename methods to avoid axtls references.
* Allow std::vector to set a list of allowed ciphers
For C++ afficionados, allow std::vectors to be passed in to the setCipher()
routine.
The BearSSL object will now keep a copy of any set ciphers and free on object
destruction. These custom lists should normally only be 1-4 entries long, so it
is not expected to be a memory hog having this extra copy.
As part of the "clear connection configuration for reused objects"
patch, a ::stop would reset the self-signed, trust anchors, etc.
WiFiClient, unfortunately, calls ::stop as part of the connection
process, so all of these settings were lost.
Now only clear the connection settings on ::stop if we've already
been connected.
Also update the github public key which changed yet again.
Fixes#5086
* Add information about the max_connection constructor argument.
* Correct information about max soft-AP connections.
* Add information about what happens when max_connection is reached.
* Correct terminology
* - Correct the valid range of max_connection to 1 - 8.
- Include reference.
According to the GCC man page, __section__ attributes should only be used
for global variables. However, the PROGMEM and ICACHE_RODATA macros use
this variable decorator even for local variables. Most of the time it works,
but when a static or inlined function tries to use a PROGMEM/PSTR/etc.
variable the compiler can throw an error like:
error: XXX causes a section type conflict with YYY
Change the PROGMEM macro to emit a section name that is unique (a combo
of the file, line, and counter variables to ensure uniqueness). The
standard linker script will place them properly in .IROM without
any changes.
Fixes#5036 and others.
Fixes#4882 and updates GitHub certificate fingerprint to the current one
in BearSSL_Validation example.
When setting a authentication mode or stopping, clear all others out in case
the object is being re-used.
Add in a yield during the SSL handshake to allow a graceful timeout and not
a WDT error when the remote server hiccups. Thanks to @Jeroen88 for
finding and testing this.
Several users have been worried that they need to generate the IDX file,
but don't know how. The CertStore code actually writes this file on object
creation, and the user never needs to explicitly generate or upload it.
Add a comment to the example explicitly noting this.
Due to popular demand, remove the hardcoded dependency on SPIFFS
or SD from the CertStore by factoring out the file interface into
a new class (CertStoreFile) that the user will need to implement
as a thin wrapper around either a SPIFFS.file or a SD.file
Combine the downloaded certificates into a UNIX "ar" archive
and parse that on-the-fly to allow easy inspection and creation
of the Cert Store database.
Examples updated with a new certificate downloader that creates
the certs.ar archive and with a single sample that can be built
for either SPIFFS or SD with a #define. Users can copy the
implementation of the CertStoreFile they need to their own code
as it is self-contained.
Also move the CertStore to the BearSSL namespace and remove the
suffix and separate SPIFFS/SD sources.
Remove the "deep+" change from the CI build as well (no special
options needed on any PIO or makefile build).
We'll revisit the filesystem wrapper for 2.5.0, hopefully having a
unified template for both filesystem usage at a global level. For
current users, be aware the interface may change (simplify!) in
release 2.5.0.
Fixes#4740
When a message is sent by the app that is larger than the SSL buffer,
it will take multiple TLS fragments to transfer. Writes will loop
through and not return until either all data is transferred or there
is an error.
When the TCP socket is closed there may be some data left in the
BearSSL internal buffers which can be read by the application.
The BearSSL pump, however, would always return no data available
in the case the socket was disconnected before checking if the
SSL was in a state where the app could possibly read.
Fix by returning if the state is available, even if the connection
is gone. Eventually no more data will become available to read
and the original -1 will be returned.
This should match the existing axTLS ::connected() behavior.
The SSL pipeline is multi-stage, and the TCP connection can go down
even though there is still data waiting to be decrypted or in the
decryption buffer.
Explicitly check that there if there can be any data made available
to the app, and if so report that we are still connected(). When
there is no data and there is no TCP connection, report disconnected.
BearSSL (https://www.bearssl.org) is a TLS(SSL) library written by
Thomas Pornin that is optimized for lower-memory embedded systems
like the ESP8266. It supports a wide variety of modern ciphers and
is unique in that it doesn't perform any memory allocations during
operation (which is the unfortunate bane of the current axTLS).
BearSSL is also absolutely focused on security and by default performs
all its security checks on x.509 certificates during the connection
phase (but if you want to be insecure and dangerous, that's possible
too).
While it does support unidirectional SSL buffers, like axTLS,
as implemented the ESP8266 wrappers only support bidirectional
buffers. These bidirectional buffers avoid deadlocks in protocols
which don't have well separated receive and transmit periods.
This patch adds several classes which allow connecting to TLS servers
using this library in almost the same way as axTLS:
BearSSL::WiFiClientSecure - WiFiClient that supports TLS
BearSSL::WiFiServerSecure - WiFiServer supporting TLS and client certs
It also introduces objects for PEM/DER encoded keys and certificates:
BearSSLX509List - x.509 Certificate (list) for general use
BearSSLPrivateKey - RSA or EC private key
BearSSLPublicKey - RSA or EC public key (i.e. from a public website)
Finally, it adds a Certificate Authority store object which lets
BearSSL access a set of trusted CA certificates on SPIFFS to allow it
to verify the identity of any remote site on the Internet, without
requiring RAM except for the single matching certificate.
CertStoreSPIFFSBearSSL - Certificate store utility
Client certificates are supported for the BearSSL::WiFiClientSecure, and
what's more the BearSSL::WiFiServerSecure can also *require* remote clients
to have a trusted certificate signed by a specific CA (or yourself with
self-signing CAs).
Maximum Fragment Length Negotiation probing and usage are supported, but
be aware that most sites on the Internet don't support it yet. When
available, you can reduce the memory footprint of the SSL client or server
dramatically (i.e. down to 2-8KB vs. the ~22KB required for a full 16K
receive fragment and 512b send fragment). You can also manually set a
smaller fragment size and guarantee at your protocol level all data will
fit within it.
Examples are included to show the usage of these new features.
axTLS has been moved to its own namespace, "axtls". A default "using"
clause allows existing apps to run using axTLS without any changes.
The BearSSL::WiFi{client,server}Secure implements the axTLS
client/server API which lets many end user applications take advantage
of BearSSL with few or no changes.
The BearSSL static library used presently is stored at
https://github.com/earlephilhower/bearssl-esp8266 and can be built
using the standard ESP8266 toolchain.
* Added channel, ssid scan
Overloaded scanNetworks so scan can occur on a single channel and/or for a particular ssid.
* Added parameters to scanNetworks
channel number and ssid have been added as optional parameters to the orginal scanNetworks()
* fix connection reset by peer case where pcb is set to null in ClientContext::_error but not reported to WiFiClient
* ClientContext: rename functions *_sent to *_acked (:sent to :ack in debug)
* use nullptr instead of 0
* Fix WebServerSecure streamFile()
ESP8266WebServerSecure's streamFile was using the base class' method
which did not use SSL encrypt before transmitting, leading to failure.
Add a new template method and required support for
WiFiClientSecure::write(Stream&) (using a local temp buffer since the
SSL libs do not grok Arduino Streams at all).
Fixes#4544
* Match ClientContext buffer and yield() behavior
ClientContext sends out 256 bytes at a time and gives a yield after
each chunk to ensure the WDT doesn't fire. Mimic that behavior in
WiFiClientSecure::write(Stream&).
Reported in https://github.com/esp8266/Arduino/issues/4078.
WiFiClient::stopAll, called from a WiFi disconnected event handler,
could be called while WiFiClient::connect was in progress. This issue
was initially fixed in #4194, by testing `this` pointer for being
non-null in ClientContext::connect.
This change delegates deletion of ClientContext to WiFiClient
destructor. WiFiClient::stop only calls ClientContext::stop, which
closes/aborts the connection.
Use platform.local.txt to add -Werror to GCC for the build of all
code. Any warnings on a submitted patch will cause an error.
Several examples and libraries had warnings/errors (missing returns
on functions, types, etc.). Clean those up with this commit as well.
* Fix leak on multiple SSL server connections
Fixes#4302
The refcnt setup for the WiFiClientSecure's SSLContext and ClientContext
had issues in certain conditions, causing a massive memory leak on each
SSL server connection. Depending on the state of the machine, after two or
three connections it would OOM and crash.
This patch replaces most of the refcnt operations with C++11 shared_ptr
operations, cleaning up the code substantially and removing the leakage.
Also fixes a race condition where ClientContext was free'd before the SSLContext
was stopped/shutdown. When the SSLContext tried to do ssl_free, axtls would
attempt to send out the real SSL disconnect bits over the wire, however by
this time the ClientContext is invalid and it would fault.
* Separate client and server SSL_CTX, support both
Refactor to use a separate client SSL_CTX and server SSL_CTX. This
allows for separate certificates to be installed on each, and means
that you can now have both a *single* client and a *single* server
running in parallel at the same time, as they'll have separate memory
areas.
Tested using mqtt_esp8266 SSL client with a client certificate and a
WebServerSecure with its own custom certificate and key in parallel.
* Add brackets around a couple if-else clauses
The server needs to load an X509 and RSA key, but instead of using
the existing loadObject() calls implemented its own. Remove them and
use the standard ones instead.
The DEBUG_OUTPUT macro was undefined in the SSL Web server. Add it
in do that when you compile with DEBUG=HTTP_SERVER it actually compiles.
The certificate fingerprint included with the HTTPSRequest example seems
to be for an expired api.github.com certificate. Replace with the current
one to avoid reporting "certificate mismatch" errors when running.
When building using the new NDEBUG option recently added, the assert()
macro is defined to nothing. This leaves a few variables unused in the
WiFi stack causing compiler warnings. Add in empty casts to remove
these warnings. Does not affect actual assert use when NDEBUG is not
defined.
Adds SSL server mode for WiFiServerSecure, for plain SSL connections,
ESP8266WebServerSecure, for HTTPS web serving, and SecureHTTPSUpdater for
encrypted OTA updates.
Example code is provided for all new options, as well as a BASH script for
generating their own, self-signed certificates.
Both ESP8266WebServerSecure and SecureHTTPSUpdater are important for secure
password-based authentication. HTTP Basic Authentication, the only supported
model presently, sends the username and password in *cleartext* and therefore
should *never* be used in any un-SSL encrypted channel unless you don't mind
sharing your login and password with anyone else on the internet. Even if the
ESP8266 is not safety critical, this cleartext broadcast could expose you should
you reuse this password elsewhere on your network or the internet.
