From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail1.merlins.org (magic.merlins.org [209.81.13.136]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id BF58321F107 for ; Mon, 19 Nov 2012 13:24:37 -0800 (PST) Received: from merlin by mail1.merlins.org with local (Exim 4.77 #2) id 1TaYpY-0001gv-T9; Mon, 19 Nov 2012 13:24:36 -0800 Date: Mon, 19 Nov 2012 13:24:36 -0800 From: Marc MERLIN To: Dave Taht Message-ID: <20121119212436.GA4860@merlins.org> References: <20121117234437.GA5542@merlins.org> <20121119175536.GM27306@merlins.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Sysadmin: BOFH X-URL: http://marc.merlins.org/ X-Operating-System: Proudly running Linux 3.1.5-core2-volpreempt-noide-hm64-20111218/Debian squeeze/sid X-Mailer: Some Outlooks can't quote properly without this header User-Agent: Mutt/1.5.13 (2006-08-11) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: marc@merlins.org Cc: cerowrt-users@lists.bufferbloat.net Subject: Re: [Cerowrt-users] Setting up bridging and debugging problems with LAN ports with WNDR3800 X-BeenThere: cerowrt-users@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Support for user problems regarding cerowrt List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 21:24:38 -0000 First, I got bridging to work this morning over wired and wireless. I'll post my diffs when I have verified everything is still ok. Should I post on the list, or some web page of yours or mine? Second, I think I only had to change network, wireless, dhcp, and firewall. Are there other magic files where you have your congestion code applying settings to the interfaces that are now wrong after I renamed them? I want to make sure I don't drop some of your work by posting an incomplete patch. On Mon, Nov 19, 2012 at 07:15:36PM +0100, Dave Taht wrote: > > That's a pretty bad GUI trap, 4H of my time down the drain :( > > I'm glad that you got somewhere and documented it publicly. I'm not sure how well this list is indexed. Is your wiki something others like me can contribute to? (and/or can the dangerous option be removed from the GUI for your next version?) > > 81 is firewalled off on the ge00 interface. > > I might argue it be firewalled off from wifi entirely, too. The reason Yes, although if it had been, I'd have rendered my router unusable after the bug above since lan wifi was my only way in. > why it isn't is that I fairly often have to reflash a large number of > routers, remotely, which tends to blow up something or another, and > it's helpful to be able to get back into the wifi side. Yes :) > > Seems that openwrt didn't seem to hink it was a good idea. > > The problem here is threefold: > > 1) The amount of available randomness (entropy) in the linux kernel, > on an embedded device, is nearly nil. This has all sorts of bad > side-effects. I didn't realize there was no good entropy on those devices. I was hoping there were floating IO pins that you could do analogread on, or other such stuff. Shows how much I know. > We've had multiple cases where routers generated the same ssh key, for example. Doh, that's obviously very bad. > This is quite scary to me, as 10s of millions of commercial devices > with lousy entropy and yet supposedly secure "wpa2" are shipping in > the field. Yes :( That said, sounds like the kernel needs to fix that, not openwrt by disabling https, arguably making security even worse. A good compromize would be for https to work by default and have a message at the top that says "you likely have a bad http cert, please make a good one linux with 'type foo bar', paste the output in "/path/to/filebaz", and reboot. > While cerowrt contains a few patches intended to increase entropy, > they were far from satisfactory. Even with the merge of the new random > number code from 3.6, multiple device drivers need to be enhanced > before it's truly useful, and I'll remain unhappy until I find a > device with hardware RNG, or am convinced enough entropy is wedged > into the pool on boot to be random enough. Fair enough. > 2) For doing https, there are two solutions. A) create a self signed > SSL key on first boot. This has the problems of 1, above, and > additionally causes your browser to throw an error saying it's a self > signed key, even though, normally, self signed keys are more secure > than anything else, as the various breaks in the chain of trust via > conventional authorities shows. Yep. > C) somehow acquire a ssl key on first boot. Unfortunately you are not > connected to anything on first boot, you need a key. And automating > key creation and signing is something of a problem, when you don't > control a certificate authority and have secure paths in the first > place. > > Sigh. Indeed. > https IS supported in the web server and the only problem with > enabling it are the problems noted above. Understood. > I felt that it was best to not "lie" about the level of security by > using https, and try to firewall off the core interfaces, more than If I ssh in though, it's no better, so I'm not sure it's a win. Probably putting an http banner on the https site with the problem and how to fix it would be a good compromize. Thanks for the answers, Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/