<div dir="ltr">-1 to default key...<div><br></div><div>> <span style="font-size:12.8px">at the moment the user *is* used to a key mismatch, because</span></div><span style="font-size:12.8px">> every box comes up with 192.168.1.1 and another key.</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">No need to generate another weak point just because there can be another similar one...</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">More general, should a bad guy have physical access to an device, be it embedded router or full server, the game is mostly lost at that point already... He can allways take out the hard disk and boot own linux and read the contents etc...</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I could see the point of serial connection asking password in normal boot, but no point with that in failsafe... for same reasons than above... mr bad guy can even flash own bootloader to do stuff should he need access to embedded device contents...</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">So, to recap, bad guy + physical access = game over, no matter what you try to do...</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"> mine .02, Sami Olmari</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 24, 2015 at 11:33 PM, Bastian Bittorf <span dir="ltr"><<a href="mailto:bittorf@bluebottle.com" target="_blank">bittorf@bluebottle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">* Michael Richardson <<a href="mailto:mcr@sandelman.ca">mcr@sandelman.ca</a>> [24.12.2015 22:14]:<br>
</span><span class="">>     >> > till the real keys are generated? it can last several minutes on some<br>
>     >> > routers and it feels like the box is broken. also: if really something<br>
>     >> > goes wrong during key generating we can at least login.<br>
>     >><br>
>     >> you have a very bizarre understanding of securing a device.<br>
><br>
>     > in this stage the box is still without password.<br>
><br>
> okay.  So the impersonator machine lets the user in without a password, and<br>
> the impersonator machine has ALREADY connected to the new machine with no<br>
> password, and trojan'ed some binaries.<br>
<br>
</span>yes, if somebody wants to upload some binaries it's possible.<br>
<span class=""><br>
>     > the only issue i can think of is, that one can<br>
>     > read on the wire to which password somebody changes<br>
>     > with 'passwd' - but i'am pretty sure this is not<br>
>     > the case, because each session has it's own privacy.<br>
><br>
> No, since the impersonator (MITM) has involved itself with the session.<br>
> Effectively, the MITM creates:<br>
><br>
>              ssh mitm 'tee /badguy | ssh target'<br>
><br>
> (but, bidirectionally, and inside the SSH transport layer)<br>
><br>
> A new ICMP port-unreachable code would be nice to have here.<br>
<br>
</span>interesting idea, but this is also possible with the current<br>
approach. the user has to accept a new unknown key and has no<br>
idea from which box it comes from.<br>
<br>
but really, this is really hypothetical - normally you have<br>
1 box on your desk and you are connected via wire to it. what<br>
is your usecase?<br>
<div class="HOEnZb"><div class="h5"><br>
bye, bastian<br>
_______________________________________________<br>
openwrt-devel mailing list<br>
<a href="mailto:openwrt-devel@lists.openwrt.org">openwrt-devel@lists.openwrt.org</a><br>
<a href="https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel" rel="noreferrer" target="_blank">https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel</a><br>
</div></div></blockquote></div><br></div>