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

D. Hugh Redelmeier hugh at mimosa.com
Sun Mar 27 14:17:55 UTC 2016


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


More information about the talk mailing list