In `wolfSSL_EVP_CipherInit`, `ctx`'s `ivSz` field isn't being accounted for.
A common OpenSSL EVP AES-GCM flow looks like this:
- `EVP_CIPHER_CTX_new`
- `EVP_EncryptInit_ex`
- `EVP_CIPHER_CTX_ctrl` with command `EVP_CTRL_GCM_SET_IVLEN` to set the IV
length to 16 (AES block size) instead of the default 12
- `EVP_EncryptInit_ex` again to set the key and IV
- `EVP_EncryptUpdate` however many times
- `EVP_EncryptFinal`
In fact, we test this flow in our unit test `test_wolfssl_EVP_aes_gcm`. However,
in our implementation, the second call to `EVP_EncryptInit_ex` unconditionally
resets the IV length back to 12. This doesn't cause a test failure because
decryption has the same problem, so both sides of the equation have the same
wrong view of the IV.
The solution is to preserve the IV length in wolfSSL_EVP_CipherInit if ctx->ivSz
is non-zero. Otherwise, use the default of 12 (`GCM_NONCE_MID_SZ`).
This was discovered by a user migrating to the compatibility layer. As I
mentioned, it isn't exposed by our testing. It is exposed if you try to use the
same key and IV with OpenSSL and compare the resulting ciphertext with wolfSSL.
They won't be the same and thus won't interoperate.
At the start of this function, it attempts to find an ALPN extension in the
ssl object's extensions with `TLSX_Find`. If an ALPN select callback has been
set (i.e. via `wolfSSL_CTX_set_alpn_select_cb`), that gets called next. If that
callback finds a match, it removes all existing ALPN extensions found in the
ssl object. It then uses the new protocol name like this:
```
if (TLSX_UseALPN(&ssl->extensions, (char*)out, outLen, 0, ssl->heap)
== WOLFSSL_SUCCESS) {
if (extension == NULL) {
extension = TLSX_Find(ssl->extensions,
TLSX_APPLICATION_LAYER_PROTOCOL);
}
}
```
The bug is exposed if `extension` is not NULL, i.e. it was found on that initial
`TLSX_Find` call. `extension` is not NULL but it now points to garbage because
all the old ALPN extensions were just removed. It won't have it's value assigned
to the new extension that just got pushed via `TLSX_UseALPN` because of this
NULL check. This results in a segfault later in the function.
The solution is to remove the NULL check and always update `extension` after the
`TLSX_UseALPN` call.
This bug was discovered by a customer when using nginx + wolfSSL. I was able to
reproduce locally with curl acting as the client
Add `WOLFSSL_KEYGEN` option and override enable when `WOLFTPM` is
enabled
Also major reduction of variables for help messages. Override only
updates `VALUE`
* Fix for `EVP_CIPHER_CTX_flags`, which mapped to a missing function (broke openvpn)
* Added stack of name entries for ipsec/racoon support.
* Added `X509_STORE_CTX_set_flags` stub.
* Added PKCS7 NID types.
* Improved FIPS "SHA" logic in `test_wolfSSL_SHA`
* Added some uncommon NID type definitions.
* Expose the DH `DH_set_length` and `DH_set0_pqg` with OPENSSL_ALL
