Skip to content
This repository was archived by the owner on Jan 29, 2023. It is now read-only.

Commit 2ddc4c4

Browse files
khoih-progkhoih-prog
authored
v1.7.8 to Sync with SSLClient v1.6.11
### Releases v1.7.8 1. Sync with [SSLClient v1.6.11](https://github.com/OPEnSLab-OSU/SSLClient/releases/tag/v1.6.11). Check [Pull in OPEnSLab-OSU's SSLClient v1.6.11 #17](#17) 2. Add example [AWS_IoT](examples/AWS_IoT) 3. Change default SS pin for RP2040 using [ArduinoCore-mbed core](https://github.com/arduino/ArduinoCore-mbed) to 17 from 5 to be the same as [arduino-pico core](https://github.com/earlephilhower/arduino-pico) 4. Update `Packages' Patches`
1 parent 560c3f0 commit 2ddc4c4

18 files changed

+13828
-14026
lines changed

‎src/SSLClient/SSLClient.h‎

Lines changed: 14 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -396,6 +396,20 @@ class EthernetSSLClient : public Client
396396
{
397397
return m_timeout;
398398
}
399+
400+
/**
401+
@brief Change the time used during x509 verification to a different value.
402+
403+
This function directly calls br_x509_minimal_set_time to change the validation
404+
time used by the minimal verification engine. You can use this function if the default value
405+
of the compile time is causing issues. See https://bearssl.org/apidoc/bearssl__x509_8h.html#a7f3558b1999ce904084d578700b1002c
406+
for more information what this function does and how to use it.
407+
408+
@param days Days are counted in a proleptic Gregorian calendar since January 1st, 0 AD.
409+
@param seconds Seconds are counted since midnight, from 0 to 86400 (a count of 86400 is possible only if a leap second happened).
410+
*/
411+
412+
void setVerificationTime(uint32_t days, uint32_t seconds);
399413

400414
private:
401415
/** @brief Returns an instance of m_client that is polymorphic and can be used by EthernetSSLClient */

‎src/SSLClient/SSLClient_Impl.h‎

Lines changed: 19 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -121,11 +121,24 @@ size_t EthernetSSLClient::write(const uint8_t *buf, size_t size)
121121
// check if the socket is still open and such
122122
if (!m_soft_connected(func_name) || !buf || !size)
123123
return 0;
124+
125+
// wait until bearssl is ready to send
126+
if (m_run_until(BR_SSL_SENDAPP) < 0)
127+
{
128+
m_error("Failed while waiting for the engine to enter BR_SSL_SENDAPP", func_name);
129+
return 0;
130+
}
124131

125132
// add to the bearssl io buffer, simply appending whatever we want to write
126133
size_t alen;
127134
unsigned char *br_buf = br_ssl_engine_sendapp_buf(&m_sslctx.eng, &alen);
128135
size_t cur_idx = 0;
136+
137+
if (alen == 0)
138+
{
139+
m_error("BearSSL returned zero length buffer for sending, did an internal error occur?", func_name);
140+
return 0;
141+
}
129142

130143
// while there are still elements to write
131144
while (cur_idx < size)
@@ -389,6 +402,12 @@ void EthernetSSLClient::setMutualAuthParams(const SSLClientParameters& params)
389402
}
390403
}
391404

405+
/* see SSLClient.h */
406+
void EthernetSSLClient::setVerificationTime(uint32_t days, uint32_t seconds)
407+
{
408+
br_x509_minimal_set_time(&m_x509ctx, days, seconds);
409+
}
410+
392411
bool EthernetSSLClient::m_soft_connected(const char* func_name)
393412
{
394413
// check if the socket is still open and such

‎src/SSLClient/bearssl.h‎

Lines changed: 140 additions & 141 deletions
Original file line numberDiff line numberDiff line change
@@ -1,26 +1,26 @@
11
/*
2-
Copyright (c) 2016 Thomas Pornin <pornin@bolet.org>
3-
4-
Permission is hereby granted, free of charge, to any person obtaining
5-
a copy of this software and associated documentation files (the
6-
"Software"), to deal in the Software without restriction, including
7-
without limitation the rights to use, copy, modify, merge, publish,
8-
distribute, sublicense, and/or sell copies of the Software, and to
9-
permit persons to whom the Software is furnished to do so, subject to
10-
the following conditions:
11-
12-
The above copyright notice and this permission notice shall be
13-
included in all copies or substantial portions of the Software.
14-
15-
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
16-
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
17-
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
18-
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
19-
BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
20-
ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
21-
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
22-
SOFTWARE.
23-
*/
2+
* Copyright (c) 2016 Thomas Pornin <pornin@bolet.org>
3+
*
4+
* Permission is hereby granted, free of charge, to any person obtaining
5+
* a copy of this software and associated documentation files (the
6+
* "Software"), to deal in the Software without restriction, including
7+
* without limitation the rights to use, copy, modify, merge, publish,
8+
* distribute, sublicense, and/or sell copies of the Software, and to
9+
* permit persons to whom the Software is furnished to do so, subject to
10+
* the following conditions:
11+
*
12+
* The above copyright notice and this permission notice shall be
13+
* included in all copies or substantial portions of the Software.
14+
*
15+
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
16+
* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
17+
* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
18+
* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
19+
* BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
20+
* ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
21+
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
22+
* SOFTWARE.
23+
*/
2424

2525
#ifndef BR_BEARSSL_H__
2626
#define BR_BEARSSL_H__
@@ -29,100 +29,100 @@
2929
#include <stdint.h>
3030

3131
/** \mainpage BearSSL API
32-
33-
# API Layout
34-
35-
The functions and structures defined by the BearSSL API are located
36-
in various header files:
37-
38-
| Header file | Elements |
39-
| :-------------- | :------------------------------------------------ |
40-
| bearssl_hash.h | Hash functions |
41-
| bearssl_hmac.h | HMAC |
42-
| bearssl_kdf.h | Key Derivation Functions |
43-
| bearssl_rand.h | Pseudorandom byte generators |
44-
| bearssl_prf.h | PRF implementations (for SSL/TLS) |
45-
| bearssl_block.h | Symmetric encryption |
46-
| bearssl_aead.h | AEAD algorithms (combined encryption + MAC) |
47-
| bearssl_rsa.h | RSA encryption and signatures |
48-
| bearssl_ec.h | Elliptic curves support (including ECDSA) |
49-
| bearssl_ssl.h | SSL/TLS engine interface |
50-
| bearssl_x509.h | X.509 certificate decoding and validation |
51-
| bearssl_pem.h | Base64/PEM decoding support functions |
52-
53-
Applications using BearSSL are supposed to simply include `bearssl.h`
54-
as follows:
55-
56-
#include <bearssl.h>
57-
58-
The `bearssl.h` file itself includes all the other header files. It is
59-
possible to include specific header files, but it has no practical
60-
advantage for the application. The API is separated into separate
61-
header files only for documentation convenience.
62-
63-
64-
# Conventions
65-
66-
## MUST and SHALL
67-
68-
In all descriptions, the usual "MUST", "SHALL", "MAY",... terminology
69-
is used. Failure to meet requirements expressed with a "MUST" or
70-
"SHALL" implies undefined behaviour, which means that segmentation
71-
faults, buffer overflows, and other similar adverse events, may occur.
72-
73-
In general, BearSSL is not very forgiving of programming errors, and
74-
does not include much failsafes or error reporting when the problem
75-
does not arise from external transient conditions, and can be fixed
76-
only in the application code. This is done so in order to make the
77-
total code footprint lighter.
78-
79-
80-
## `NULL` values
81-
82-
Function parameters with a pointer type shall not be `NULL` unless
83-
explicitly authorised by the documentation. As an exception, when
84-
the pointer aims at a sequence of bytes and is accompanied with
85-
a length parameter, and the length is zero (meaning that there is
86-
no byte at all to retrieve), then the pointer may be `NULL` even if
87-
not explicitly allowed.
88-
89-
90-
## Memory Allocation
91-
92-
BearSSL does not perform dynamic memory allocation. This implies that
93-
for any functionality that requires a non-transient state, the caller
94-
is responsible for allocating the relevant context structure. Such
95-
allocation can be done in any appropriate area, including static data
96-
segments, the heap, and the stack, provided that proper alignment is
97-
respected. The header files define these context structures
98-
(including size and contents), so the C compiler should handle
99-
alignment automatically.
100-
101-
Since there is no dynamic resource allocation, there is also nothing to
102-
release. When the calling code is done with a BearSSL feature, it
103-
may simple release the context structures it allocated itself, with
104-
no "close function" to call. If the context structures were allocated
105-
on the stack (as local variables), then even that release operation is
106-
implicit.
107-
108-
109-
## Structure Contents
110-
111-
Except when explicitly indicated, structure contents are opaque: they
112-
are included in the header files so that calling code may know the
113-
structure sizes and alignment requirements, but callers SHALL NOT
114-
access individual fields directly. For fields that are supposed to
115-
be read from or written to, the API defines accessor functions (the
116-
simplest of these accessor functions are defined as `static inline`
117-
functions, and the C compiler will optimise them away).
118-
119-
120-
# API Usage
121-
122-
BearSSL usage for running a SSL/TLS client or server is described
123-
on the [BearSSL Web site](https://www.bearssl.org/api1.html). The
124-
BearSSL source archive also comes with sample code.
125-
*/
32+
*
33+
* # API Layout
34+
*
35+
* The functions and structures defined by the BearSSL API are located
36+
* in various header files:
37+
*
38+
* | Header file | Elements |
39+
* | :-------------- | :------------------------------------------------ |
40+
* | bearssl_hash.h | Hash functions |
41+
* | bearssl_hmac.h | HMAC |
42+
* | bearssl_kdf.h | Key Derivation Functions |
43+
* | bearssl_rand.h | Pseudorandom byte generators |
44+
* | bearssl_prf.h | PRF implementations (for SSL/TLS) |
45+
* | bearssl_block.h | Symmetric encryption |
46+
* | bearssl_aead.h | AEAD algorithms (combined encryption + MAC) |
47+
* | bearssl_rsa.h | RSA encryption and signatures |
48+
* | bearssl_ec.h | Elliptic curves support (including ECDSA) |
49+
* | bearssl_ssl.h | SSL/TLS engine interface |
50+
* | bearssl_x509.h | X.509 certificate decoding and validation |
51+
* | bearssl_pem.h | Base64/PEM decoding support functions |
52+
*
53+
* Applications using BearSSL are supposed to simply include `bearssl.h`
54+
* as follows:
55+
*
56+
* #include <bearssl.h>
57+
*
58+
* The `bearssl.h` file itself includes all the other header files. It is
59+
* possible to include specific header files, but it has no practical
60+
* advantage for the application. The API is separated into separate
61+
* header files only for documentation convenience.
62+
*
63+
*
64+
* # Conventions
65+
*
66+
* ## MUST and SHALL
67+
*
68+
* In all descriptions, the usual "MUST", "SHALL", "MAY",... terminology
69+
* is used. Failure to meet requirements expressed with a "MUST" or
70+
* "SHALL" implies undefined behaviour, which means that segmentation
71+
* faults, buffer overflows, and other similar adverse events, may occur.
72+
*
73+
* In general, BearSSL is not very forgiving of programming errors, and
74+
* does not include much failsafes or error reporting when the problem
75+
* does not arise from external transient conditions, and can be fixed
76+
* only in the application code. This is done so in order to make the
77+
* total code footprint lighter.
78+
*
79+
*
80+
* ## `NULL` values
81+
*
82+
* Function parameters with a pointer type shall not be `NULL` unless
83+
* explicitly authorised by the documentation. As an exception, when
84+
* the pointer aims at a sequence of bytes and is accompanied with
85+
* a length parameter, and the length is zero (meaning that there is
86+
* no byte at all to retrieve), then the pointer may be `NULL` even if
87+
* not explicitly allowed.
88+
*
89+
*
90+
* ## Memory Allocation
91+
*
92+
* BearSSL does not perform dynamic memory allocation. This implies that
93+
* for any functionality that requires a non-transient state, the caller
94+
* is responsible for allocating the relevant context structure. Such
95+
* allocation can be done in any appropriate area, including static data
96+
* segments, the heap, and the stack, provided that proper alignment is
97+
* respected. The header files define these context structures
98+
* (including size and contents), so the C compiler should handle
99+
* alignment automatically.
100+
*
101+
* Since there is no dynamic resource allocation, there is also nothing to
102+
* release. When the calling code is done with a BearSSL feature, it
103+
* may simple release the context structures it allocated itself, with
104+
* no "close function" to call. If the context structures were allocated
105+
* on the stack (as local variables), then even that release operation is
106+
* implicit.
107+
*
108+
*
109+
* ## Structure Contents
110+
*
111+
* Except when explicitly indicated, structure contents are opaque: they
112+
* are included in the header files so that calling code may know the
113+
* structure sizes and alignment requirements, but callers SHALL NOT
114+
* access individual fields directly. For fields that are supposed to
115+
* be read from or written to, the API defines accessor functions (the
116+
* simplest of these accessor functions are defined as `static inline`
117+
* functions, and the C compiler will optimise them away).
118+
*
119+
*
120+
* # API Usage
121+
*
122+
* BearSSL usage for running a SSL/TLS client or server is described
123+
* on the [BearSSL Web site](https://www.bearssl.org/api1.html). The
124+
* BearSSL source archive also comes with sample code.
125+
*/
126126

127127
#include "bearssl_hash.h"
128128
#include "bearssl_hmac.h"
@@ -138,34 +138,33 @@
138138
#include "bearssl_pem.h"
139139

140140
/** \brief Type for a configuration option.
141-
142-
A "configuration option" is a value that is selected when the BearSSL
143-
library itself is compiled. Most options are boolean; their value is
144-
then either 1 (option is enabled) or 0 (option is disabled). Some
145-
values have other integer values. Option names correspond to macro
146-
names. Some of the options can be explicitly set in the internal
147-
`"config.h"` file.
148-
*/
149-
typedef struct
150-
{
151-
/** \brief Configurable option name. */
152-
const char *name;
153-
/** \brief Configurable option value. */
154-
long value;
141+
*
142+
* A "configuration option" is a value that is selected when the BearSSL
143+
* library itself is compiled. Most options are boolean; their value is
144+
* then either 1 (option is enabled) or 0 (option is disabled). Some
145+
* values have other integer values. Option names correspond to macro
146+
* names. Some of the options can be explicitly set in the internal
147+
* `"config.h"` file.
148+
*/
149+
typedef struct {
150+
/** \brief Configurable option name. */
151+
const char *name;
152+
/** \brief Configurable option value. */
153+
long value;
155154
} br_config_option;
156155

157156
/** \brief Get configuration report.
158-
159-
This function returns compiled configuration options, each as a
160-
'long' value. Names match internal macro names, in particular those
161-
that can be set in the `"config.h"` inner file. For boolean options,
162-
the numerical value is 1 if enabled, 0 if disabled. For maximum
163-
key sizes, values are expressed in bits.
164-
165-
The returned array is terminated by an entry whose `name` is `NULL`.
166-
167-
\return the configuration report.
168-
*/
157+
*
158+
* This function returns compiled configuration options, each as a
159+
* 'long' value. Names match internal macro names, in particular those
160+
* that can be set in the `"config.h"` inner file. For boolean options,
161+
* the numerical value is 1 if enabled, 0 if disabled. For maximum
162+
* key sizes, values are expressed in bits.
163+
*
164+
* The returned array is terminated by an entry whose `name` is `NULL`.
165+
*
166+
* \return the configuration report.
167+
*/
169168
const br_config_option *br_get_config(void);
170169

171170
#endif

0 commit comments

Comments
 (0)