Re: [Cerowrt-devel] wired article about bleed and bloat and underfunded critical infrastructure
On Fri, Apr 11, 2014 at 12:43 PM, wrote: > I'm afraid it's not *just* underfunded. I reviewed the details of the code > involved and the fixes, and my conclusion is that even programmers of > security software have not learned how to think about design, testing, etc. > Especially the continuing use of C in a large shared process address space > for writing protocols that are by definition in the "security kernel" > (according to the original definition) of applications on which the public > depends. > > > > Ever since I was part of the Multics Security Project (which was part of the > effort that produced the Orange Book > http://csrc.nist.gov/publications/history/dod85.pdf) Which I incidentally have read... and fail to see how it applies well to networked systems. > in the 80's, we've > known that security-based code should not be exposed to user code and vice > versa. Yet the SSL libraries are linked in, in userspace, with the > application code. I note that I am glad that they are mostly dynamically linked in - something that wasn't the case for some other crypto libs - because finding applications that linked statically would be even more difficult. And I have seen some reports of people using heavily patched openssl doing smarter things with memory allocation - why weren't those patches pushed back into openssl? Well, because they were held private and not publicly reviewed... and don't appear to actually work, according to this: http://lekkertech.net/akamai.txt > Also, upgrades/changes to protocols related to security (which always should > have been in place on every end-to-end connection) should be reviewed *both > at the protocol design level* and also at the *implementation level* because > change creates risk. They should not be adopted blindly without serious > examination and pen-testing, yet this change just was casually thrown in in > a patch release. Yes, change creates risk. Change also breeds change. Without change there would be no progress. Should there be an "office of critical infrastructure" or an underwriters labratory examining and blessing each piece of software that runs as root or handles money? Should some governmental or intergovernmental group be putting a floor under (or a roof over) the people working on code deemed as critical infrastructure? heartbleed was not detected by a coverity scan either. > I suspect that even if it were well funded, the folks who deploy the > technology would be slapdash at best. I agree. Recently I was asked to come up with an "phone-home inside your business embedded device architecture" that would scale to millions of users. I don't want the responsibility, nor do I think any but hundreds of people working together could come up with something that would let me sleep well at night - yet the market demand is there for something, anything, that even barely works. If I don't do the work, someone less qualified will. > Remember the Y2K issue I do. I also remember the response to it. http://www.taht.net/~mtaht/uncle_bills_helicopter.html The response to heartbleed has been incredibly heartening as to the swiftness of repair - something that could not have happened in anything other than the open source world. I have friends, however, that just went days without sleep, fixing it. I've outlined my major concerns with TLS across our critical infrastructure going forward on my g+. > and the cost of > lazy thinking about dates. (I feel a little superior because in 1968 Multics > standardized on a 72-bit hardware microsecond-resolution hardware clock > because the designers actually thought about long-lived systems (actually I agree that was far-thinking. I too worry about Y2036 and Y2038, and do my best to make sure those aren't problems. it seems likely some software will last even longer than that. > only 56 bits of the original clock worked, but the hardware was not expected > to last until the remaining bits could be added)). Multics died. It would not have scaled to the internet. And crypto development and public deployment COULD have gone more hand in hand if it weren't basically illegal until 1994, and maybe before then, some reasonable security could have been embedded deep into more protocols. It would have been nice to have had a secured X11 protocol, or kerberos made globally deployable, or things like mosh, in the 80s. In terms of more recent events, I happen to have liked HIP. We don't know how to build secured network systems to this day, that can survive an exposure to hundreds of millions of potential attackers. > > > The open source movement, unfortunately, made a monoculture of the SSL > source code, so it's much more dangerous and the vulnerable attack surface > of deployments is enormous. No it didn't. Alternatives to openssl exist - gnutls, cyassl, and polarssl are also open source. Libraries that merely implement primitives well like nettle, gmp, and libsodium - all developed later - also exist. I
Re: [Cerowrt-devel] Full blown DNSSEC by default?
On Sun, Apr 13, 2014 at 10:59 AM, Chuck Anderson wrote: > On Sun, Apr 13, 2014 at 12:05:19PM +0200, Toke Høiland-Jørgensen wrote: >> >> > Is there a "D"? >> >> Running a full resolver in cerowrt? I've been running a dnssec-enabled bind >> for some time on my boxes (prior to dnssec support in dnsmasq). > > How do these proposals compare with unbound+dnssec-trigger in the > Fedora world? I stirred up a rats nest: > > https://lists.fedoraproject.org/pipermail/devel/2014-April/197755.html Oh, did you! I'm reluctant to join that enormous thread, but there have been couple things stated that aren't quite correct. 0) I agree that dnsmasq needs to be tested a lot more before it's dnssec implementation can be as trusted as much as unbound's or bind's. 1) dnsmasq is used by ubuntu by default (at least), and it's at least semi-integrated with network manager in that case over the dbus. So far as I know the caching functionality in dnsmasq in that instance is disabled due to fears about cache poisoning, that I don't fully understand. My half understood fear translates into equivalent fears for other local dns daemons. 2) Benchmarks like namebench can show the value of the local cache, shaving milliseconds off of local queries across the network. I have generally had servers have their own bind daemon for about 16 years - it helps, especially if you like to do reverse lookups. 3) I heartily approve of alternate dns servers like unbound or bind being used by various distros of choice - a monoculture is not what is needed here! Support and integration into NM for all of them would be great. 4) dnsmasq is now fully capable of obsoleting resolv.conf.auto cleverly and dealing with at least some vagaries of vpns. > I realize these are slightly different use cases, but it may be > helpful to learn from the different implementations, if for no other > reason than to be sure they interoperate. I'm going to turn on > unbound+dnssec-trigger on my laptop and try it behind Cerowrt w/DNSSEC > turned on to see what happens... I was unaware of the dnssec-trigger stuff, which makes sense especially on mobiles transiting captive-portal environments. I would also like openwrt's captive portal stuff to work better. I was also unaware of unbound's clever suspend resume support for clearing the local cache. > ___ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Full blown DNSSEC by default?
On Sun, Apr 13, 2014 at 12:05:19PM +0200, Toke Høiland-Jørgensen wrote: > > > Is there a "D"? > > Running a full resolver in cerowrt? I've been running a dnssec-enabled bind > for some time on my boxes (prior to dnssec support in dnsmasq). How do these proposals compare with unbound+dnssec-trigger in the Fedora world? I stirred up a rats nest: https://lists.fedoraproject.org/pipermail/devel/2014-April/197755.html I realize these are slightly different use cases, but it may be helpful to learn from the different implementations, if for no other reason than to be sure they interoperate. I'm going to turn on unbound+dnssec-trigger on my laptop and try it behind Cerowrt w/DNSSEC turned on to see what happens... ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] dnssec on dankaminsky.com?
Dave Taht writes: > I get a red flag from firefox's dnssec-validator on: > > http://dankaminsky.com/ > > on admittedly a much older version of dnsmasq. Well it resolves for me with dnssec-check-unsigned turned on. > (this is also my sneaky way of coaxing y'all to read his last two articles) Will do :P -Toke signature.asc Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Full blown DNSSEC by default?
Dave Taht writes: > Boingo has sent out a mail to all customers saying they were not > affected, but I do worry a lot about the overall security of > enterprise wifi and 802.1x ethernet networks in general. FWIW the 802.1x authentication usually works in one of two modes: MSCHAPv2 which is Microsoft's challenge/response protocol that never ships passwords over the wire (setups that authenticate against an Active Directory, or people who want to support windows clients natively will run in this mode), or EAP-TTLS which has a second end-to-end TLS tunnel from the wireless client all the way back to the authentication server. Presumably the latter will also be vulnerable to heartbleed until updated, but at least there's another layer of turtles there. -Toke signature.asc Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Full blown DNSSEC by default?
On Sun, Apr 13, 2014 at 9:16 AM, wrote: > I'd be for A. Or C with a very, very strong warning that would encourage > users to pressure their broken upstream. Users in China will never not have > a broken upstream, of course, but they know that already... :-) I'd be very much for A except that I'd like somehow a failure to resolve due to a dnssec problem to return a pointer to something, somehow that informs the user as to what went wrong and what to do about it. > Similarly, I hope we don't have Heartbleed in our SSL. All versions of cerowrt prior to 3.10.36-3 potentially had heartbleed in the https admin interface, and also possibly hostapd (though I don't know how to exploit it). The optional wpa_supplicant, openvpn, strongswan, authsae packages also were affected and a few others I forget. More scarily - from a large deployment perspective, things like the radsec radius backend also use TLS security to carry authentication info back to a radius server. All of openwrt, dd-wrt, etc from Attitude Adjustment to trunk to about 12 hours after the disclosure were vulnerable. Patches went into the relevant repositories but it's going to be very hard to push updates out to the field, since no update mechanism exists for most embedded products. Boingo has sent out a mail to all customers saying they were not affected, but I do worry a lot about the overall security of enterprise wifi and 802.1x ethernet networks in general. > Maybe we should put > a probe in Cero's SSL that tests clients to see if they have Heartbleed > fixed on their side, and warns them. I'd like more probes and defenses in general, notably things that detect dns amplification attempts and send them somewhere to be collected, some sort of universal moon worm attempt detector/reporter, and the equivalent of a rbl database for attacks and potential attackers. > Any DNS provider that doesn't do DNSSEC should be deprecated strongly (I'm > pretty sure OpenDNS cannot do so, since it deliberately fakes its lookups, > redirecting to "man in the middle" sites that it runs). Concur. On the one hand I was happy with the idea of dnscrypt, but not happy that the backend couldn't do dnssec right. > On Sunday, April 13, 2014 12:26am, "Dave Taht" said: > >> I am delighted that we have the capability now to do dnssec. >> >> I am not surprised that various domain name holders are doing it >> wrong, nor that some ISPs and registrars don't support doing it >> either. We are first past the post here, and kind of have to expect >> some bugs... >> >> but is the overall sense here: >> >> A) we should do full dnssec by default, and encourage users to use >> open dns resolvers like google dns that support it when their ISPs >> don't? >> >> B) or should we fall back to the previous partial dnssec >> implementation that didn't break as hard, and encourage folk to turn >> it up full blast if supported correctly by the upstream ISP? >> >> C) or come up with a way of detecting a broken upstream and falling >> back to a public open resolver? >> >> Is there a "D"? >> >> -- >> Dave Täht >> >> NSFW: >> >> https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article >> ___ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >> -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Full blown DNSSEC by default?
I'd be for A. Or C with a very, very strong warning that would encourage users to pressure their broken upstream. Users in China will never not have a broken upstream, of course, but they know that already... :-) Similarly, I hope we don't have Heartbleed in our SSL. Maybe we should put a probe in Cero's SSL that tests clients to see if they have Heartbleed fixed on their side, and warns them. Any DNS provider that doesn't do DNSSEC should be deprecated strongly (I'm pretty sure OpenDNS cannot do so, since it deliberately fakes its lookups, redirecting to "man in the middle" sites that it runs). On Sunday, April 13, 2014 12:26am, "Dave Taht" said: > I am delighted that we have the capability now to do dnssec. > > I am not surprised that various domain name holders are doing it > wrong, nor that some ISPs and registrars don't support doing it > either. We are first past the post here, and kind of have to expect > some bugs... > > but is the overall sense here: > > A) we should do full dnssec by default, and encourage users to use > open dns resolvers like google dns that support it when their ISPs > don't? > > B) or should we fall back to the previous partial dnssec > implementation that didn't break as hard, and encourage folk to turn > it up full blast if supported correctly by the upstream ISP? > > C) or come up with a way of detecting a broken upstream and falling > back to a public open resolver? > > Is there a "D"? > > -- > Dave Täht > > NSFW: > https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article > ___ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel >___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
[Cerowrt-devel] dnssec on dankaminsky.com?
I get a red flag from firefox's dnssec-validator on: http://dankaminsky.com/ on admittedly a much older version of dnsmasq. (this is also my sneaky way of coaxing y'all to read his last two articles) -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Full blown DNSSEC by default?
On Sun, Apr 13, 2014 at 12:51 AM, Török Edwin wrote: > On 04/13/2014 07:26 AM, Dave Taht wrote: >> I am delighted that we have the capability now to do dnssec. >> >> I am not surprised that various domain name holders are doing it >> wrong, nor that some ISPs and registrars don't support doing it >> either. We are first past the post here, and kind of have to expect >> some bugs... >> >> but is the overall sense here: >> >> A) we should do full dnssec by default, and encourage users to use >> open dns resolvers like google dns that support it when their ISPs >> don't? > > There are people who don't use Google DNS due to privacy concerns. > Given the choice between not using DNSSEC, and using Google's DNS they might > prefer not having DNSSEC. Good point. Well there is also dnscrypt and opendns. There's a (broken) dnscrypt packaging attempt in ceropackages. > >> >> B) or should we fall back to the previous partial dnssec >> implementation that didn't break as hard, and encourage folk to turn >> it up full blast if supported correctly by the upstream ISP? >> >> C) or come up with a way of detecting a broken upstream and falling >> back to a public open resolver? >> >> Is there a "D"? > > There are some tests described here, and a 'dynamic fallback' technique in > section 5: > http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-roadblock-avoidance-00 > > I think the 'dynamic fallback' can be described in short as: try to use > upstream DNS resolver, > and if you don't get the DNSSEC metadata that you expected, *then* eventually > fallback to iterating from Root for that metadata. Which only works for a full blown local resolver. In the dnsmasq case the switch would have to be another open dns resolver. We could iterate over a list of open dns resolvers to find the best one. > So then A//TXT/NS/etc. records would be answered by upstream, and only > for the DNSSEC metadata you would need to iterate > (and you could cache that, or stop iterating if you realize the zone is > unsigned as per section 5.1.1) Maybe there could be a "dnssec-fallback-resolver" setting in dnsmasq, that it could fall back to if a known-not-to-resolve-properly domain can't do a proof of non-existence properly? bork.bork.bork.bork.example.org > Best regards, > --Edwin > > > ___ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Full blown DNSSEC by default?
On Sun, Apr 13, 2014 at 3:05 AM, Toke Høiland-Jørgensen wrote: > >> Is there a "D"? > > Running a full resolver in cerowrt? I've been running a dnssec-enabled bind > for some time on my boxes (prior to dnssec support in dnsmasq). I had done quite a few optimizations to make running a full blown bind9 resolver at home pretty performant (caching the roots, for example). I also liked being able to do full split dns, etc. But: I got fed up with doing bind for a variety of reasons: A) 4 CERT alerts in a year, including a couple nasty ones B) Too hard to configure even for a wizard C) Too hard to configure via a web interface D) People blocking the roots E) Would run out of flash easily with the jnl file So I pursued finding something (e.g. dnsmasq) that was smaller, more integrated, easier to configure, and easy on ram and flash. so that's dnsmasq today. It seems more plausible to continue to improve dnsmasq than it is to dumb down bind. I do not mind continuing to support and improve optional bind and unbound support for those that want to use them. > -Toke > > -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Having issue upgrading to latest image 3.10.36-4
On Sun, Apr 13, 2014 at 5:58 AM, Sebastian Moeller wrote: > I think Valdis Kletnieks reported the same for a 3800. Please try the > "manual" route described below and report back your results to the list: I attempted an upgrade using the web interface from -3 to -4 and it also failed. I tried from the shell: root@cerowrt:/tmp# sysupgrade -c -v openwrt-ar71xx-generic-wndr3800-squashfs-sysupgrade_new.bin Saving config files... etc/lighttpd/lighttpd.pem etc/passwd- etc/fw_env.config etc/shadow etc/passwd etc/group- etc/ethers etc/config/wireless etc/config/system etc/config/polipo etc/config/ucitrack etc/config/network etc/config/ubootenv etc/config/dropbear etc/config/firewall etc/config/upnpd etc/config/fstab etc/config/luci etc/config/dhcp etc/config/sqm etc/dropbear/dropbear_rsa_host_key etc/dropbear/authorized_keys etc/dropbear/dropbear_dss_host_key etc/sudoers etc/shadow- etc/samba/secrets.tdb etc/samba/smbpasswd etc/group etc/firewall.user killall: watchdog: no process killed Sending TERM to remaining processes ... logd netifd odhcpd lighttpd crond lighttpd snmpd pimd xinetd dbus-daemon smbd nmbd avahi-daemon miniupnpd polipo babeld natpmp ahcpd rngd ntpd dnsmasq ubusd askfirst Sending KILL to remaining processes ... askfirst Switching to ramdisk... Performing system upgrade... Unlocking firmware ... Writing from to firmware ... Appending jffs2 data from /tmp/sysupgrade.tgz to firmware...TRX header not found Error fixing up TRX header Upgrade completed Rebooting system... After reboot: root@cerowrt:~# cat /etc/openwrt_release DISTRIB_ID="CeroWrt" DISTRIB_RELEASE="3.10.36-4" DISTRIB_REVISION="r40438" The system appears to be working okay, except my 2.4GHz interface is missing - I haven't spent any real time looking into that. Regards, Joel ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Full blown DNSSEC by default?
> Is there a "D"? Running a full resolver in cerowrt? I've been running a dnssec-enabled bind for some time on my boxes (prior to dnssec support in dnsmasq). -Toke ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Full blown DNSSEC by default?
On 04/13/2014 07:26 AM, Dave Taht wrote: > I am delighted that we have the capability now to do dnssec. > > I am not surprised that various domain name holders are doing it > wrong, nor that some ISPs and registrars don't support doing it > either. We are first past the post here, and kind of have to expect > some bugs... > > but is the overall sense here: > > A) we should do full dnssec by default, and encourage users to use > open dns resolvers like google dns that support it when their ISPs > don't? There are people who don't use Google DNS due to privacy concerns. Given the choice between not using DNSSEC, and using Google's DNS they might prefer not having DNSSEC. > > B) or should we fall back to the previous partial dnssec > implementation that didn't break as hard, and encourage folk to turn > it up full blast if supported correctly by the upstream ISP? > > C) or come up with a way of detecting a broken upstream and falling > back to a public open resolver? > > Is there a "D"? There are some tests described here, and a 'dynamic fallback' technique in section 5: http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-roadblock-avoidance-00 I think the 'dynamic fallback' can be described in short as: try to use upstream DNS resolver, and if you don't get the DNSSEC metadata that you expected, *then* eventually fallback to iterating from Root for that metadata. So then A//TXT/NS/etc. records would be answered by upstream, and only for the DNSSEC metadata you would need to iterate (and you could cache that, or stop iterating if you realize the zone is unsigned as per section 5.1.1) Best regards, --Edwin ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
