| Message ID | 20200724142940.5264-1-ynezz@true.cz |
|---|---|
| Headers | show |
| Series | Support TLS/SSL and WPA3-Personal/SAE by default | expand |
On 7/24/20 4:29 PM, Petr Štetiar wrote: > Hi, > > it has been discussed several times and some of core developers would like to > include SSL/TLS and WPA3-Personal/SAE support in the next release as we've > dropped support for 4/32M devices officialy with 19.07 and it's time to move > on and improve the default security features in official images. > > wolfSSL and mbed TLS were pre-selected as possible crypto libraries due to the > size. mbed TLS currently lacks support in hostapd so I went with wolfSSL for > the start. > > In order to keep the size as small as possible I've created > `wpad-basic-wolfssl` variant of currently shipped `wpad-basic` package which > just adds support for SAE. > > I've tested the patchset on my Rambutan board with `sae` and `sae-mixed` > encryption settings against my Android 10 phone and installed random package > with opkg over HTTPS. > > Size comparison of openwrt-ath79-nand-8dev_rambutan-squashfs-factory.bin: > > 5373952 bytes for wolfSSL enabled image > 5111808 bytes for current image as of r13926-f94b09867d > ------- > 262144 bytes is difference > > I think, that those numbers are not that bad if you consider that the > following patchset adds ca-certificates, libustream-wolfssl, libwolfssl and > wpad-basic-wolfssl into default packages. > > Cheers, > > Petr > > Petr Štetiar (3): > hostapd: add wpad-basic-wolfssl variant > treewide: use wpad-basic-wolfssl as default > treewide: switch to HTTPS by default This looks good to me. How stable is the ABI of wolfssl? We probably have to update it to new versions in the lifetime and then it would be nice if we only have to update the wolfssl package. Is this also enough to make LUCI work with https when just luci is activated? Hauke
> On Jul 26, 2020, at 10:19 AM, Hauke Mehrtens <hauke@hauke-m.de> wrote: > > On 7/24/20 4:29 PM, Petr Štetiar wrote: >> Hi, >> >> it has been discussed several times and some of core developers would like to >> include SSL/TLS and WPA3-Personal/SAE support in the next release as we've >> dropped support for 4/32M devices officialy with 19.07 and it's time to move >> on and improve the default security features in official images. >> >> wolfSSL and mbed TLS were pre-selected as possible crypto libraries due to the >> size. mbed TLS currently lacks support in hostapd so I went with wolfSSL for >> the start. >> >> In order to keep the size as small as possible I've created >> `wpad-basic-wolfssl` variant of currently shipped `wpad-basic` package which >> just adds support for SAE. >> >> I've tested the patchset on my Rambutan board with `sae` and `sae-mixed` >> encryption settings against my Android 10 phone and installed random package >> with opkg over HTTPS. >> >> Size comparison of openwrt-ath79-nand-8dev_rambutan-squashfs-factory.bin: >> >> 5373952 bytes for wolfSSL enabled image >> 5111808 bytes for current image as of r13926-f94b09867d >> ------- >> 262144 bytes is difference >> >> I think, that those numbers are not that bad if you consider that the >> following patchset adds ca-certificates, libustream-wolfssl, libwolfssl and >> wpad-basic-wolfssl into default packages. >> >> Cheers, >> >> Petr >> >> Petr Štetiar (3): >> hostapd: add wpad-basic-wolfssl variant >> treewide: use wpad-basic-wolfssl as default >> treewide: switch to HTTPS by default > > This looks good to me. > > How stable is the ABI of wolfssl? > > We probably have to update it to new versions in the lifetime and then > it would be nice if we only have to update the wolfssl package. > > Is this also enough to make LUCI work with https when just luci is > activated? Note that wolfSSL only exposes TLS 1.2 and 1.3 by default. 1.1 and below are compile time disabled. Probably not too big of a problem by now. > > Hauke > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
On 26.07.20 19:29, Rosen Penev wrote: > > >> On Jul 26, 2020, at 10:19 AM, Hauke Mehrtens <hauke@hauke-m.de> wrote: >> >> On 7/24/20 4:29 PM, Petr Štetiar wrote: >>> Hi, >>> >>> it has been discussed several times and some of core developers would like to >>> include SSL/TLS and WPA3-Personal/SAE support in the next release as we've >>> dropped support for 4/32M devices officialy with 19.07 and it's time to move >>> on and improve the default security features in official images. >>> >>> wolfSSL and mbed TLS were pre-selected as possible crypto libraries due to the >>> size. mbed TLS currently lacks support in hostapd so I went with wolfSSL for >>> the start. >>> >>> In order to keep the size as small as possible I've created >>> `wpad-basic-wolfssl` variant of currently shipped `wpad-basic` package which >>> just adds support for SAE. >>> >>> I've tested the patchset on my Rambutan board with `sae` and `sae-mixed` >>> encryption settings against my Android 10 phone and installed random package >>> with opkg over HTTPS. >>> >>> Size comparison of openwrt-ath79-nand-8dev_rambutan-squashfs-factory.bin: >>> >>> 5373952 bytes for wolfSSL enabled image >>> 5111808 bytes for current image as of r13926-f94b09867d >>> ------- >>> 262144 bytes is difference >>> >>> I think, that those numbers are not that bad if you consider that the >>> following patchset adds ca-certificates, libustream-wolfssl, libwolfssl and >>> wpad-basic-wolfssl into default packages. >>> >>> Cheers, >>> >>> Petr >>> >>> Petr Štetiar (3): >>> hostapd: add wpad-basic-wolfssl variant >>> treewide: use wpad-basic-wolfssl as default >>> treewide: switch to HTTPS by default >> >> This looks good to me. >> >> How stable is the ABI of wolfssl? >> >> We probably have to update it to new versions in the lifetime and then >> it would be nice if we only have to update the wolfssl package. >> >> Is this also enough to make LUCI work with https when just luci is >> activated? > Note that wolfSSL only exposes TLS 1.2 and 1.3 by default. 1.1 and below are compile time disabled. Probably not too big of a problem by now. Not an issue since browsers have moved to disable TLS 1.0 and 1.1 quite recently. > We have disabled TLS 1.0 and TLS 1.1 to improve your website connections. Sites that don't support TLS version 1.2 will now show an error page. https://www.mozilla.org/en-US/firefox/78.0/releasenotes/ >> >> Hauke >> >> _______________________________________________ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel >
Hauke Mehrtens <hauke@hauke-m.de> [2020-07-26 19:15:59]: > How stable is the ABI of wolfssl? I assume, that we're going to find the answer in the upcoming years :-) Anyway, by looking purely at the Git log of hostapd it seems stable. $ git log --pretty="%ci %s" src/crypto/*wolfssl* 2020-05-16 21:02:17 +0300 wolfssl: Fix crypto_bignum_rand() implementation 2020-05-16 21:01:51 +0300 wolfssl: Fix compiler warnings on size_t printf format use 2020-02-29 23:26:26 +0200 crypto: Add a function to get the ECDH prime length 2019-10-25 19:29:53 +0300 crypto: Remove unused crypto_bignum_sqrtmod() 2019-10-14 19:38:41 +0300 wolfSSL: Fix crypto_bignum_sub() 2019-10-14 19:38:41 +0300 crypto: Add more bignum/EC helper functions 2019-08-06 13:12:37 +0300 wolfssl: Avoid void pointer arithmetic 2019-05-26 16:11:56 +0300 More forceful clearing of stack memory with keys 2019-04-26 17:43:45 +0300 Remove unused crypto_bignum_bits() 2019-04-13 18:28:05 +0300 Remove the unused crypto_ec_cofactor() function 2019-04-09 16:24:38 +0300 Extend domain_match and domain_suffix_match to allow list of values 2019-04-09 16:24:38 +0300 wolfSSL: Fix dNSName matching with domain_match and domain_suffix_match 2019-03-16 18:52:09 +0200 Add support for an optional context parameter to TLS exporter 2019-03-11 14:09:45 +0200 OpenSSL: Add 'check_cert_subject' support for TLS server 2019-03-05 17:05:03 +0200 Add explicit checks for peer's DH public key 2018-12-31 12:51:51 +0200 hostapd: Add configuration option check_crl_strict 2018-12-30 17:21:55 +0200 OpenSSL: Add openssl_ecdh_curves parameter 2018-10-11 12:12:30 +0300 TLS: Add tls_connection_peer_serial_num() 2018-05-17 22:02:02 +0300 wolfSSL: Fix crypto_bignum_rshift() wrapper 2018-05-17 20:08:22 +0300 wolfSSL: DH initialization to call TEST_FAIL() for error tests 2018-05-17 20:08:15 +0300 wolfSSL: Fix ECDH set peer to use the index when importing point 2018-05-02 13:32:51 +0300 wolfSSL: Fix EAP-FAST key derivation 2018-05-02 13:32:51 +0300 wolfSSL: Do not free cert store after setting it 2018-05-02 13:32:51 +0300 wolfSSL: Fix OCSP ifdefs 2018-05-02 13:32:51 +0300 wolfSSL: Fix altSubjectName handling 2018-05-02 13:32:51 +0300 wolfSSL: Use defines from wolfssl/options.h 2018-05-02 13:32:51 +0300 wolfSSL: Use wolfSSL memory allocation in dh5_init() 2018-05-02 13:32:51 +0300 wolfSSL: Load certificates using 'chain' APIs 2018-05-02 13:32:51 +0300 wolfSSL: Changes for memory allocation failure testing 2018-05-02 13:32:51 +0300 wolfSSL: Fix crypto_hash_init() memory clearing 2018-05-02 13:32:51 +0300 wolfSSL: Fix crypto_ec_point_y_sqr() 2018-05-02 13:32:51 +0300 wolfSSL: Fix crypto_ec_point_solve_y_coord() 2018-05-02 13:32:49 +0300 wolfSSL: Add crypto_ecdh_*() 2018-05-02 12:04:46 +0300 wolfSSL: Use new digest namespace 2018-05-02 00:37:57 +0300 wolfSSL: Fix conditional EAP-FAST compilation issue 2018-03-03 11:52:40 +0200 Add support for wolfSSL cryptographic library > We probably have to update it to new versions in the lifetime and then > it would be nice if we only have to update the wolfssl package. We're using stable release, so this should be doable. > Is this also enough to make LUCI work with https when just luci is > activated? I didn't tried it yet, but I assume, that uhttpd uses libustream-wolfssl for the TLS so it should work out of the box. As Daniel already pointed out, the "only" missing bit is px5g-wolfssl for self-signed certificate generation. -- ynezz
Hi, >> How stable is the ABI of wolfssl? > > I assume, that we're going to find the answer in the upcoming years :-) see https://abi-laboratory.pro/index.php?view=timeline&l=wolfssl for the historic track record. Compared to OpenSSL here: https://abi-laboratory.pro/index.php?view=timeline&l=openssl it looks rather dynamic and not stable at all. However it appears that the ABI reamins stable through minor versions. From some cursory browsing over the wolfSSL site, I couldn't find information about release support timeframes, seems to me that only the latest version is supported and backporting security fixes to a given minor version is up to the maintainers. ~ Jo
On 7/27/20 10:50 AM, Petr Štetiar wrote: > Hauke Mehrtens <hauke@hauke-m.de> [2020-07-26 19:15:59]: > >> How stable is the ABI of wolfssl? > > I assume, that we're going to find the answer in the upcoming years :-) > > Anyway, by looking purely at the Git log of hostapd it seems stable. The API is probably stable or only gets extended in a backwards compatible way, I am more interested in the ABI. Can we just replace the .so file without recompiling the users. >> We probably have to update it to new versions in the lifetime and then >> it would be nice if we only have to update the wolfssl package. > > We're using stable release, so this should be doable. Currently wolfssl only releases new major releases when they find security problems as far as I understood it. Hauke