Re: [OpenWrt-Devel] [PATCH v3 0/3] ustream-ssl: support openssl 1.1.0, revised security

2018-06-16 Thread Rosen Penev
Tested-by: Rosen Penev 

On Fri, Jun 15, 2018 at 9:04 PM, Eneas U de Queiroz via openwrt-devel
 wrote:
> 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.
>
> -- Forwarded message --
> From: Eneas U de Queiroz 
> To: openwrt-devel@lists.openwrt.org
> Cc: Eneas U de Queiroz 
> Bcc:
> Date: Sat, 16 Jun 2018 01:03:40 -0300
> Subject: [PATCH v3 0/3] ustream-ssl: support openssl 1.1.0, revised security
> 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-gcm3759.88k   4280.96k   4415.66k4437.79k  4456.12k
> 4436.88k
> aes-256-gcm3408.83k   3738.10k   3838.52k3841.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
>
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/listinfo/openwrt-devel
>

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/listinfo/openwrt-devel


[OpenWrt-Devel] [PATCH v3 0/3] ustream-ssl: support openssl 1.1.0, revised security

2018-06-15 Thread Eneas U de Queiroz via openwrt-devel
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-gcm3759.88k   4280.96k   4415.66k4437.79k  4456.12k
4436.88k
aes-256-gcm3408.83k   3738.10k   3838.52k3841.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
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/listinfo/openwrt-devel