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