Re: A proposal of https certificate assignment system for luci
20. 10. 6. 오전 1:29에 Michael Richardson 이(가) 쓴 글:
abnoeh wrote:
> Openwrt as project get a CA certificate with name constrained to only
> able to sign subdomains of [luci.openwrt.org]. this makes we
> Technically Constrained Subordinate CA, (from let's encrypt or
> digicert), let's call it the Openwrt CA here (CA ) this makes we don't
> create too much load to normal CA like let's encrypt, and as we have
> complete control of this zone we can give subdomains as we want like,
> and don't need full audit like fully pledged CA and handled like a
> wildcard cert for them, but the CA system can be hosted by us and
> request won't offloaded to upper CA's server. (except OCSP request, but
> it can be cashed)
While this is a technically correct solution, it may be politically impossible.
The CABForum insists that any Subordinate CA that we might get has to be
constrained by the CABForum rules.
If we don't comply, then Mozilla/Google/Apple will force whatever root CA
that signs us to revoke the subCA. (I think that this really really sucks)
actually making our CA to Technically Constrained as CA/B 7.1.5 will
make we exempted from most of those audit requirements, just section 8.7
which is just we and our parent CA should check we are adhere to our own
CPS. and most root program take same approach, you should be name locked
or be public and audited.
form 8.1 Frequency or circumstances of assessmentCertificates that are
capable of being used to issue new certificates MUST either be
Technically Constrained in line with section 7.1.5 and audited in line
with section 8.7 only
That's essentially why Enterprise subordinate CAs have gone away.
The CAs now offer to host Enterprise CAs in their cloud, where they can do
all the right things to remain compliant. Most enterprises find that
annoying and expensive, and so they go the way of generating their own
private CA.
If we can live with the constraints, and can find a CA willing to delegate a
subordinate CA to us, then let's try.
> {everything below will be done on https or otherwise encrypted channel}
> 1. on first boot, router want to get it's luci certificate send its ssh
> host key to Openwrt CA reserve subdomain base32(hash of public
> key).luci.openwrt.org (like onion v3 addressed does)
> 2. Openwrt CA sends nonce to our router
> 3. router signs nonce+timestamp+[hash of CSR] with sent ssh host key,
> and send back to openwrt CA send this signed message with CSR
> 4. Openwrt CA verify other end controls host key match
> with hash and confirmed the CSR, sign the certificate with (key from
> CSR/SAN with domain we derived from host key) and sent back to router
> 5. router now has valid cerfiticate, redirect 192.168.1.1 or openwrt
> lan to https version of signed subdomain
This an interesting process, leveraging the SSH key as part of the unique part.
I prefer to use ULA, and to find a way to store ULA in eeprom.
using ssh key as unique part was to solve problem of 'Are you sure you
are looking at right page even at worst state (like dns hijack or remote
management over the internet) so I wanted to make domain something can
be cryptically connected to the device we connect, and ssh key was first
and only key we have.
maybe enforce cert's pubkey == ssh pubkey == domain kind of way be
better, but browsers don't support ed25519, or CA/B allow to make one,
so it need ssh-keescan to see key if device check ed25519 key by default.
However, I think you are assuming a RA/DHCP-based WAN connection.
For PPPoE (which is still a thing in a lot of places, including developing
world, where last mile is often wifi), this won't work that well.
at the end entire reason we need certificate is we having a webserver,
and all luci will do at the backend is running uci conmmand, can we run
luci on client side, and send uci command to ssh, wrap it all under the
name of "easy-installer"?
if we don't have webserver we don't need a certificate. or uhttpd, in fact.
___
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
[PATCH] mvebu: enable the vDSO
The vDSO is used to accelerate some syscalls. It's working fine on other ARM targets (e.g. sunxi), let's also enable it on mvebu. Signed-off-by: Rui Salvaterra --- target/linux/mvebu/config-5.4 | 1 + 1 file changed, 1 insertion(+) diff --git a/target/linux/mvebu/config-5.4 b/target/linux/mvebu/config-5.4 index a13cb8d9e5..7e44c79089 100644 --- a/target/linux/mvebu/config-5.4 +++ b/target/linux/mvebu/config-5.4 @@ -489,6 +489,7 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_MVEBU=y CONFIG_USB_XHCI_PLATFORM=y CONFIG_USE_OF=y +CONFIG_VDSO=y CONFIG_VFP=y CONFIG_VFPv3=y CONFIG_WATCHDOG_CORE=y -- 2.28.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] generic: platform/mikrotik: implement multi caldata
On Fri, 25 Sep 2020 21:09:26 +0200 Thibaut wrote: > Ping? LGTM. What's in the "$wdata/data_0" file? Is it the BDF? Best, lynxis -- Alexander Couzens mail: lyn...@fe80.eu jabber: lyn...@fe80.eu gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604 pgpbyv_G_1yGj.pgp Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[no subject]
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 --- > >>> # For exponential module: > >>> -#CONFIG_AUTOSCAN_EXPONENTIAL=y > >>> +CONFIG_AUTOSCAN_EXPONENTIAL=y > >>> # For periodic module: > >>> -#CONFIG_AUTOSCAN_PERIODIC=y > >>> # operations for roaming within an ESS (same SSID). See the bgscan > >>> parameter in > >>> # the wpa_supplicant.conf file for more details. > >>> # Periodic background scans based on signal strength > >>> -#CONFIG_BGSCAN_SIMPLE=y > >>> +CONFIG_BGSCAN_SIMPLE=y > >>> # Learn channels used by the network and try to avoid bgscans on other > >>> # channels (experimental) > >>> #CONFIG_BGSCAN_LEARN=y This change enables the config options CONFIG_BGSCAN_* and CONFIG_AUTOSCAN_* But we only configure CONFIG_BGSCAN_* via hostapd.sh with the uci option *roam_rssi_threshold* in this change. But should we not als make CONFIG_AUTOSCAN configurable via hostapd.sh? #autoscan=: Kind regards Florian --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: A proposal of https certificate assignment system for luci
On 07/10/20 04:01, Daniel Golle wrote: Hi Alberto, Hi Michael, Hi everyone else, I don't understand how your argument is related to that pretty nice suggestion regarding a fairly complex and (unfortunately) relevant problem. It is relevant because it's asking how big of a problem it actually is to maintain the current status quo of accepting the warnings with the buttons. In my opinion, until the browsers start blocking the connection to sites with self-signed certificates, this is a non-issue because the userbase is tech-savyy enough to read the wiki and follow a tutorial, since they are already following a tutorial to install OpenWrt to begin with. Apart from it being hard to proof that people wanting to access the configuration (and status!) interface of a device running OpenWrt (or something based on it) are all prosumers or developers, for future users this assumption even has the taste of a self fullfilling prophecy. Hard to proof? I thought it was obvious enough. Is the following situation different where you live? Where I live (Italy), the devices from all ISPs have always been pre-configured since ages ago, wifi is always enabled and the device-specific wifi key is on a sticker under the device, also WPS functionality is commonly available with a button. They never ever have to open its configuration panels to do anything, just connect the cables and power plug. A few ISPs don't even provide passwords for their device web interface and their tech support people will remote-control them to enable or disable features (open ports and add rules and whatnot) as requested by the customer on the phone. For devices that aren't provided by the ISPs, basic stuff like setting up a guest wifi or sharing a USB device are one-button wizards that just ask the network name and password, or what is the USB device you want to share. All devices with a SIM card slot and modem are plug-and-play aka you just insert a SIM without the PIN and power on, and everything works. Also most devices have a selector in the web interface that allows to turn them into three modes: wifi AP, wifi repeater, router and reconfigures a bunch of stuff under the hood. On OpenWrt the user experience is very different from that, and I don't think it's a stretch to assume that it is filtering the userbase. We start by installing a custom firmware on a device, sometimes easy sometimes hard. The entire concept of doing that already filters out many non-tech-savyy people. If we talk of OpenWrt used on ISP-provided devices, it's usually a pre-configured plug-and-play system that the end user never looks at again. Then you must set up the wifi network, no wizard. It's assumed you know how to do it or read the wiki. Changing "mode" of the device require multiple steps of configuration on OpenWrt, sometimes can only be done from commandline. Again, it's assumed you know how to do it or have RTFM. Many features require to copy-paste console commands and/or follow a tutorial from the wiki to do this or that. Even basic stuff like setting up a guest wifi require multiple steps of configuration setting new interfaces, new firewall rules and whatnot. Connecting and sharing a USB drive? Yay, more steps to connect it, install drivers, mount it, set up Samba on the folder it is mounted on. Using devices that have an integrated 3G/LTE modem? More configuration. You want to set up a RAID on a NAS device? commandline only, baby. All proposals for making a default wifi with device-specific passwords have been shot down, and wifi isn't enabled even in devices where there are no other interfaces, forcing you to use serial for first configuration, which is even funnier for the poor souls that install OpenWrt in such devices. So, please explain how clicking on two buttons on the browser when connecting the first time matters for people that can deal with the above on their own (and therefore know stuff) or are already 100% following and trusting a wiki tutorial to install OpenWrt and set up their device. As I already said, just add a couple screenshots and instructions in the install guide and it's fine. A truely good solution to the actual problem imho doesn't exist (because https://youbroketheinternet.org/ ) The only decent solution, and also more user-friendly and easy to expand imho is Android/iOS apps. With that you can bypass all the certificate mafia bs and do your own thing. It does not need a backend on the devices either as it can just rely on a simple ssh interface to actually talk to the device and send direct commands. That's what most manufacturers are moving towards, like for example GL.Inet https://www.gl-inet.com/solutions/app/ but also TP-link with "TP-link Tether" Netgear with "Netgear Genie" and "Nighthawk" and "Orbi" and so on and so forth. -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.o
Re: A proposal of https certificate assignment system for luci
On 07/10/20 15:34, abnoeh wrote: However, I think you are assuming a RA/DHCP-based WAN connection. For PPPoE (which is still a thing in a lot of places, including developing world, where last mile is often wifi), this won't work that well. at the end entire reason we need certificate is we having a webserver, and all luci will do at the backend is running uci conmmand, can we run luci on client side, and send uci command to ssh, wrap it all under the name of "easy-installer"? if we don't have webserver we don't need a certificate. or uhttpd, in fact. Yeah, this is why Android/iOS apps should be considered as a way to approach this issue. -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
UBI "not enough PEBs" sysupgrading Mikrotik RB493G from 19.07.04 -> latest
Hi, I just tried sysupgrading a new head build for a Mikrotik 493G device (ar71xx 19.07.4 initramfs -> ath79 head) however I get the below "not enough PEBs" UBI failure and panic: If I sysupgrade from an earlier git build (e.g. b7a8a5454226f34256c5d76480dda5abb1308395 ath79 initramfs -> ath79 head) it works fine, and I see it fixes the PEBs issue Any thoughts or ideas why flashing from ar71xx to ath79 blows this up? I ask as this would make migration from 19.07 to 20.xx painful for many. Thanks, Chris 19.07.04 sysupgrade log: root@OpenWrt:/# sysupgrade -F -v /tmp/openwrt-ath79-mikrotik-mikrotik_routerboard-493g-squashfs-sysupgrade.bin Invalid sysupgrade file. Image check failed but --force given - will update anyway! Cannot save config while running from ramdisk. Commencing upgrade. Closing all shell sessions. Watchdog handover: fd=3 - watchdog - killall: telnetd: no process killed Sending TERM to remaining processes ... odhcpd uhttpd ntpd udhcpc odhcp6c dnsmasq ubusd urngd logd rpcd netifd Sending KILL to remaining processes ... Performing system upgrade... Unlocking kernel ... Erasing kernel ... Writing data to block 0 at offset 0x0 Writing data to block 1 at offset 0x2 Writing data to block 2 at offset 0x4 Writing data to block 3 at offset 0x6 Writing data to block 4 at offset 0x8 Writing data to block 5 at offset 0xa Writing data to block 6 at offset 0xc Writing data to block 7 at offset 0xe Writing data to block 8 at offset 0x10 Writing data to block 9 at offset 0x12 Writing data to block 10 at offset 0x14 Writing data to block 11 at offset 0x16 Writing data to block 12 at offset 0x18 Writing data to block 13 at offset 0x1a Writing data to block 14 at offset 0x1c Writing data to block 15 at offset 0x1e Writing data to block 16 at offset 0x20 Writing data to block 17 at offset 0x22 removing ubiblock0_1 [ 116.299696] block ubiblock0_1: released Volume ID 0, size 19 LEBs (2412544 bytes, 2.3 MiB), LEB size 126976 bytes (124.0 KiB), dynamic, name "none", alignment 1 Volume ID 1, size 23 LEBs (2920448 bytes, 2.7 MiB), LEB size 126976 bytes (124.0 KiB), dynamic, name "rootfs", alignment 1 Set volume size to 117579776 Volume ID 2, size 926 LEBs (117579776 bytes, 112.1 MiB), LEB size 126976 bytes (124.0 KiB), dynamic, name "rootfs_data", alignment 1 sysupgrade successful Tail of subsequent latest kernel boot log: [ 1.887155] UBI: auto-attach mtd2 [ 1.890554] ubi0: attaching mtd2 [ 3.037225] ubi0: scanning is finished [ 3.104023] ubi0 error: ubi_read_volume_table: not enough PEBs, required 970, available 958 [ 3.112648] ubi0 error: ubi_attach_mtd_dev: failed to attach mtd2, error -28 [ 3.119770] UBI error: cannot attach mtd2 [ 3.124398] /dev/root: Can't open blockdev [ 3.128559] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6 [ 3.136035] Please append a correct "root=" boot option; here are the available partitions: [ 3.144384] 1f00 256 mtdblock0 [ 3.144387] (driver?) [ 3.150932] 1f01 8192 mtdblock1 [ 3.150934] (driver?) [ 3.157476] 1f02 122624 mtdblock2 [ 3.157478] (driver?) [ 3.164004] 1f03 64 mtdblock3 [ 3.164006] (driver?) [ 3.170542] 1f04 44 mtdblock4 [ 3.170544] (driver?) [ 3.177070] 1f05 4 mtdblock5 [ 3.177072] (driver?) [ 3.183608] 1f06 4 mtdblock6 [ 3.183610] (driver?) [ 3.190146] 1f07 8 mtdblock7 [ 3.190148] (driver?) [ 3.196674] 1f08 4 mtdblock8 [ 3.196676] (driver?) [ 3.203212] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [ 3.211454] Rebooting in 1 seconds.. Same sections on a good install (where volume 2 now reports different sizes) removing ubiblock0_1 [ 1438.275670] block ubiblock0_1: released Volume ID 0, size 19 LEBs (2412544 bytes, 2.3 MiB), LEB size 126976 bytes (124.0 KiB), dynamic, name "none", alignment 1 Volume ID 1, size 23 LEBs (2920448 bytes, 2.7 MiB), LEB size 126976 bytes (124.0 KiB), dynamic, name "rootfs", alignment 1 Set volume size to 113262592 Volume ID 2, size 892 LEBs (113262592 bytes, 108.0 MiB), LEB size 126976 bytes (124.0 KiB), dynamic, name "rootfs_data", alignment 1 [ 1443.243449] UBIFS (ubi0:2): default file-system created [ 1443.260078] UBIFS (ubi0:2): background thread "ubifs_bgt0_2" started, PID 2341 [ 1443.790864] UBIFS (ubi0:2): UBIFS: mounted UBI device 0, volume 2, name "rootfs_data" [ 1443.798728] UBIFS (ubi0:2): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes [ 1443.808634] UBIFS (ubi0:2): FS size: 111865856 bytes (106 MiB, 881 LEBs), journal size 5586944 bytes (5 MiB, 44 LEBs) [ 1443.819240] UBIFS (ubi0:2): reserved for root: 4952683 bytes (4836 KiB) [ 1443.825859] UBIFS (ubi0:2): media format: w4/r0 (latest is w5/r0), UUID A2702902-BDC0-4788-9F46-4DABF752DFE6, small LPT model [ 144
Re: [PATCH] hostapd: Add cell_density data rates option
Hi Nick, On 10/2/20 5:26 PM, Nick Lowe wrote: > Hi all, > > Please may I request any thoughts and feedback on this proposed patch > to the hostapd config generation shell script to add a new > cell_density configuration option? > > This would subsequently allow for a LuCI-exposed option to then be > added via a follow up patch for easy, less error prone configuration > of data rates for normal, high and very high density deployments. As briefly mentioned on IRC, I have concerns that this might interfere with clients using buggy wireless implementations. I've noticed 802.11g clients not connecting / listing networks which do not offer a 6 Mbit/s basic rate. On the other hand, these kind of clients also show frequent issues when used with FT or (god forbid) PSK2-SAE mixed mode. Therefore I'm in favor of adding a brief notice to this option to LuCI, that tampering with this setting might lead to issues with some clients. That said, the proposed settings and rate sets look sensible to me, given they are abstracted from easily explained toggles. Best wishes David > > Currently, it is both easy to misunderstand basic/mandatory and > optional rates and to misconfigure these, and the current basic_rate > and supported_rates options are not exposed in Luci and are therefore > not easily discoverable or accessible. > I feel that the basic_rate and supported_rates options are best > abstracted via a new setting for general use cases before being > exposed to LuCI. > > Where specified, the basic_rate and supported_rates options would > override both the cell_density and legacy_rates options. > > Cheers, > > Nick > > ___ > 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
