[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