[GTALUG] Netgear 5-port Gigabit switch -- $10 ?

David Thornton northdot9 at gmail.com
Sun Mar 27 17:46:14 UTC 2016


So when you ssh into something it doesn't send silly stings like
"username:" or "password:" . That stuff is handed "in protocol" .

David

On Sun, Mar 27, 2016, 2:17 PM D. Hugh Redelmeier <hugh at mimosa.com> wrote:

> | From: Alvin Starr <alvin at netvel.net>
>
> | On 03/27/2016 10:02 AM, James Knott wrote:
>
> | I do not know for sure but It was my understanding that if you know the
> | payload it is possible to back calculate the encryption keys and
> | invariably switches sent a standard banner and a Username: Password:.
> | There may be better security with key based login and no password.
> | On the other hand I am sure the encryption is good enough to stop all
> | but nation states or folks like SPECTRE or KAOS.
>
> When you are trying to break a cryptosystem, you have a leg up if you
> know the plain text.  That does not mean that you can break the
> system.  So good crypto hygiene, often at the protocol level, reduces
> known plain text.
>
> For example, if your key is based only on a password, then trying all
> passwords might be feasible.  Know plain text lets you easily check
> whether a particular guess is correct.
>
> SSH public/private keypairs are as long as you want.  They are not
> passwords.  Usually 2k or more bits of RSA these days.  That's too
> large to brute force, probably until quantum computers work better.
> But one never knows.  Do make sure your keys are long enough.
>
> So no, I don't think that the known plain text exposed by SSH is a
> problem.  But I'm not a cryptographer.
>
> |
> | >> A lot of the lower end switches use a http web interface which is no
> | >> more secure than telnet.
> | > Many use https, instead of plain http.  Again, it's the same key
> | > situation as with ssh.
>
> HTTPS, as it is used, is a bit more risky than ssh.  First of all,
> lots of obsolete versions of TLS and SSL had security bugs at the
> protocol and implementation levels.  And those versions are frozen
> into much firmware.
>
> Secondly, authentication, as used, is substandard.  I'm talking about
> within-protocol authentication -- passwords are not part of TLS/SSL.
> Without authentication, a man-in-the-middle attack is trivial.  The
> normal form of authentication for SSL/TLS is x.509 certificates.
> Unfortunately, the client end is almost never authenticated.  In the
> case of switches, the normal procedure is for the switch (the server)
> to use self-signed certificates in a way that provides no actual
> authentication.
>
> | On 03/27/2016 10:02 AM, James Knott wrote:
>
> | > As I mentioned earlier, in order to attack a password, you have to see
> | > the data.  That doesn't happen much with switches, though it was quite
> | > easy prior to switches.  Also, remote management is generally done via
> | > vlan, which makes it a bit more difficult for a casual eavesdropper.
>
> A switch offers fewer easy points of interception but they are
> available anywhere along the path unless it is within your security
> perimeter.  I can imagine that switches could get attacked via spoofed
> packets too.
>
> | I have to lots of switch management remotely.
> | I do login to the local networks via VPN but you never know what is in
> | the middle on the internet or even the local network.
>
> A good VPN, well-deployed, should be safe.  Depending on your threat model.
>
> ================
>
> I talk to my routers (gateways actually) through SSH.  I can talk to
> them through IPSec too.  But that's because they are PCs running
> ordinary Linux.
>
> My gateways' SSH servers don't allow password authentication.  They
> are constantly hit by SSH attempts from miscreants, all password based.
> ---
> Talk Mailing List
> talk at gtalug.org
> https://gtalug.org/mailman/listinfo/talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gtalug.org/pipermail/talk/attachments/20160327/eb300c91/attachment.html>


More information about the talk mailing list