I never understood why domains used to NTP and Package mirrors depend on external, commercial, certificate authorities.
It could be a fallback, with a red big warning to manually check the certs are alright when you need it (e.g too long without synching your root certificates package). But for most cases there is no excuse not having it local at all times.
I mean MITM a domain essential for the "distro" should be at least just a little bit harder than regular MITM.
I've always wondered a similar thing... why is reputation-based TLD network security limited to a single verification entity (CA w/ revocation policy)? Seems obvious to me certs should be signed (and thus revokable) from multiple entities by default. I've implemented this before in clients ad-hoc, but why isn't it default?
Don't get me started on authoritative DNS security.
I installed newest version OpenWRT on a popular brand, recently manufactured wireless router last week.
The OpenWRT firmware couldn't access https sites without installing multiple packages first. Then they had me install all the root certs over an unencrypted connection. The opkg repos and install files are all downloaded over http.
With full seriousness, I really hope nobody expects operational security using these routers.
>The opkg repos and install files are all downloaded over http.
This was a problem because of the bug. But now it isn't one anymore. 'opkg update' updates the package lists. The lists contain information about the packages: name, file size, architecture, description etc., and also the SHA256sum. When you install a package opkg will compare the SHA256sums.
For those who are using the Turris OS OpenWrt derivative: fixed in 5.0-rc0, for 4.0.x there is a bigger problem they are working on, for 3.x it might not have been introduced yet
Tangentially related: I want to run OpenWRT but need at least 500Mbps WAN/LAN filtered routing capacity; my old tp-link 4300 barely manages 150mbps; can anyone recommend a modern home WiFi/router that can run OpenWRT and do line speed packet filtering between WAN and LAN?
I’ve considered getting the new Linksys. It’s been hard to justify its price tag though next to another router I would also highly recommend, the GL.iNet B1300. I have bought three of those so far and will buy one or two more when they go on sale again.
I forget which ARM chip it ships with, but it’s capable of pushing almost 200Mbps on WireGuard, and it’s a significant bargain over the Linksys. Its antennas probably won’t cover same distance as the Linksys though—that works in my small apartment or if you use a couple of them in a mesh network. For a bigger house and if you like to keep things simple, the Linksys or the Turris are probably the best options.
I use OpenWRT on a Linksys WRT3200ACM. It has a dual core ARMv7 cpu running at 1.8GHz, with 512MB of memory. It does very well, in my opinion.
My PC with an Intel Wireless-AC 9260 has the following network connection, reported by the OpenWRT interface: "400.0 Mbit/s, 40MHz, VHT-MCS 9, VHT-NSS 2, Short GI 400.0 Mbit/s, 40MHz, VHT-MCS 9, VHT-NSS 2, Short GI"
My work 2018 Macbook Pro gets the following: "540.0 Mbit/s, 40MHz, VHT-MCS 9, VHT-NSS 3 600.0 Mbit/s, 40MHz, VHT-MCS 9, VHT-NSS 3, Short GI"
Mine and my wife's LG V40 Android phones get this reported speed: "400.0 Mbit/s, 40MHz, VHT-MCS 9, VHT-NSS 2, Short GI 6.0 Mbit/s, 40MHz"
Not sure if there's any extra information I can provide. I'm not affiliated with Linksys.
Thanks. I should have made this more explicit, but I care less about the WLAN performance (as long as it's ok) - I care more about the wired one.
Most OpenWRT ports don't offload the LAN/WAN routing, and doing it on a lowly ARM CPU often effectively limits this to a few hundred megabits - e.g. 150mbps on my WDR4300 (which does manage 800Mbps for the same task with the original closed firmware which does do some hardware offloading)
Get a Xiaomi Router 3G. It is more difficult to do an initial flash, but is well worth it with an awesome $40 price tag on Aliexpress.
Only downside is that it only has 3 GigE ports.
"The bug has been introduced with commit https://git.openwrt.org/54cc7e3 which
failed to advance the proper string pointer when skipping the leading white-
space portition of the checksum string, causing the subsequent hex decoding
loop to return early with a zero length checksum."
I can't believe someone messed up something so simple! ( Sarcasm )
Yeah, yuck, this definitely could have been avoided if they did some proper lexing/parsing before dealing with the line, instead of manually separating things apart after matching on the beginning of the string...
That said, perhaps it's just too early in the morning but I don't think that commit introduced the error. The math/logic looks to be identical and I think the bug is `line + strlen("SHA256sum") + 1` which was already there before and doesn't increment past any spaces which might come after the (implied I guess?) colon. Though considering the colon isn't checked for in `SHA256sum`, you could put any character there and it'll work. Yay...
Nice catch I think. I’ll be damned if I can see a difference. Looks like the old code will also skip the checksum in the case of any non hexdigit padding.
It could be a fallback, with a red big warning to manually check the certs are alright when you need it (e.g too long without synching your root certificates package). But for most cases there is no excuse not having it local at all times.
I mean MITM a domain essential for the "distro" should be at least just a little bit harder than regular MITM.