[Cerowrt-users] Setting up bridging and debugging problems with LAN ports with WNDR3800

[Marc MERLIN]

On Mon, Nov 19, 2012 at 01:24:36PM -0800, Marc MERLIN wrote:
> 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'm still happy to post something. I'll do it on my blog if it's the best
place.
Before posting info though, I want to make sure I'm not giving people bad
advise. Is what I wrote above enough not to disable to latency tweaks, or is
there more I should do?

For the stuff below, if it makes sense to you, I can try to appeal to the
openwrt folks directly since they are your upstream.
In the end, providing ssh but not https just doesn't make sense, and the
http interface is just as bad as asking me to telnet into the router to
configure it :)

Happy black friday :)

Marc

> > 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/