The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped automatically by the mailing list software.
--- Begin Message ---I've fixed a bug in the handling of BIO flags. I've made some changes to the security options used in the library, and made them more uniform across all supported libraries (mbedtls, wolfssl, openssl 1.0.2 & openssl 1.1.0). The biggest, and probably most controversial change is in the ciphersuite ordering. Here's my reasoning: The first priority was key exchange, to provide forward-security. Then comes encryption algorithm. AEAD ciphers are chosen first. They are chacha20-poly1305 (256 bits), and aes-gcm (128 & 256 bits variants). Among the three, I've selected chacha20-poly1305 because of higher performance and strength. Here's a table generated by openssl speed on ramips: ((openssl speed -evp chacha20-poly1305 | egrep "^(type|chacha)") && \ (openssl speed -evp aes-128-gcm && openssl speed -evp aes-256-gcm) | \ egrep "^aes") 2>/dev/null type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes chacha20-poly1305 6873.30k 10734.22k 12217.75k 12613.07k 12769.39k 12665.00k aes-128-gcm 3759.88k 4280.96k 4415.66k 4437.79k 4456.12k 4436.88k aes-256-gcm 3408.83k 3738.10k 3838.52k 3841.90k 3864.31k 3882.17k I'm assuming most routers running openwrt are not going to have AES-capable chips. If we were to run the benchmark in a newer server, I'd bump AES-256 to the top. This is what it looks like in my x86_64: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes chacha20-poly1305 206412.13k 400740.77k 788942.85k 869130.38k 899400.83k 893596.97k aes-128-gcm 283449.15k 730408.60k 1074886.58k 1176372.95k 1232831.03k 1245781.87k aes-256-gcm 238760.79k 660843.45k 967903.44k 1071756.62k 1089887.49k 1089552.89k This could be added as an option, or selected automatically depending on architecture. The difference is more dramatic for the lesser capable chips anyway. You can check your "grade" at https://www.ssllabs.com/ssltest/. You'll get an A on openssl and mbedtls, and an A- with wolfssl--the minus is due to lack of secure renegotiation. There's an option to enable it, but wolfssl does not recommend using it.I've made some changes to the security options used in the library, and made them more uniform across all supported libraries (mbedtls, wolfssl, openssl 1.0.2 & openssl 1.1.0) The mbedtls patch can be applied on its own, independent of the openssl patch. Eneas U de Queiroz (3): ustream-ssl: add openssl-1.1.0 compatibility ustream-ssl: Revised security on openssl/wolfssl ustream-ssl: Revised security on mbedtls openssl_bio_compat.h | 33 ++++++++++++++++++++++ ustream-io-openssl.c | 46 +++++++++++++++--------------- ustream-mbedtls.c | 49 +++++++++++++++----------------- ustream-openssl.c | 80 ++++++++++++++++++++++++++++++++++++++++++++-------- 4 files changed, 146 insertions(+), 62 deletions(-) create mode 100644 openssl_bio_compat.h -- 2.16.4
--- End Message ---
_______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/listinfo/openwrt-devel
