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 <[email protected]> wrote: > | From: Alvin Starr <[email protected]> > > | 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 > [email protected] > https://gtalug.org/mailman/listinfo/talk >
--- Talk Mailing List [email protected] https://gtalug.org/mailman/listinfo/talk
