Using unprotected Wifi
in [Linux Networking]
|
Prev: WANTED TO BUY - NETWORKING, TELECOM EQUIPMENT & SOFTWARE - CISCO, NORTEL, LUCENT, JUNIPER, EXTREME, FOUNDRY, FUJITSU, MICROSOFT, ADOBE, SYMANTEC & MORE
Next: NFS boot: where are the mount options ?!?
From: unruh on 29 May 2010 23:44 On 2010-05-29, Robert Nichols <SEE_SIGNATURE(a)localhost.localdomain.invalid> wrote: > On 05/29/2010 03:53 PM, David Schwartz wrote: >> On May 28, 5:08 pm, Robert Nichols >> <SEE_SIGNAT...(a)localhost.localdomain.invalid> wrote: >> >>> For someone who is in the habit of ignoring key change warnings, >>> concerns about unprotected WiFi should be the least of his worries. >> >> I think that's a pretty ridiculous attitude. If nothing else, it >> ignores the difference between blocking passive interception and >> blocking active attacks. There are many circumstances where it is much >> more important to block the latter than the former. (For example, >> cases where one is legal and the other is not and you are much more >> concerned by legal interception than illegal interception.) > > Passive interception does not offer the opportunity to present a > fake host key that is a prerequisite for a MITM attack. The > design of the ssh protocol assumes that an eavesdropper is able > to monitor both sides of the conversation. If you know of a way > to crack an ssh connection by passive interception, I'm sure the > security community would be quite eager to hear about it. > > Anyone is welcome to passively monitor my ssh connections at any > time, and that includes connections where I had no previous > knowledge of the remote system's public host key. > You got it. If the OP is worried about passive listening, ssh is always an answer. If he believes a mitm attack will be launched mor detailed care is needed.
From: David Schwartz on 30 May 2010 20:40 On May 29, 4:22 pm, Robert Nichols <SEE_SIGNAT...(a)localhost.localdomain.invalid> wrote: > Passive interception does not offer the opportunity to present a > fake host key that is a prerequisite for a MITM attack. The > design of the ssh protocol assumes that an eavesdropper is able > to monitor both sides of the conversation. If you know of a way > to crack an ssh connection by passive interception, I'm sure the > security community would be quite eager to hear about it. > > Anyone is welcome to passively monitor my ssh connections at any > time, and that includes connections where I had no previous > knowledge of the remote system's public host key. Now, that is much more sensible than nonsense like "For someone who is in the habit of ignoring key change warnings, concerns about unprotected WiFi should be the least of his worries." It is perfectly reasonable to be concerned about passive attacks but not so concerned about active attacks. DS
From: Jon Solberg on 31 May 2010 11:06 On 2010-05-28, unruh <unruh(a)wormhole.physics.ubc.ca> wrote: > On 2010-05-28, David W. Hodgins <dwhodgins(a)nomail.afraid.org> wrote: >> On Fri, 28 May 2010 02:46:12 -0400, unruh <unruh(a)wormhole.physics.ubc.ca> wrote: >> >>> ssh IS "his own encryption" An ssh session is encrypted from end to end >>> including between his machine and the access point. >> >> The ssh connection will only be encrypted after the session has been >> established. > > False. The estabilshment of the key is also protected. A approaches B > and assuming that the two have shared a public key before hand, can > verify that B is actually the intended recipient. Then the two exchange > a key in a protected matter. > >> >> If he's using a passphrase, instead of public/private key encryption, >> then he is susceptible to passphrase sniffing. > > No he is not. [...] Well, actually he is, historically there has existed buggy implementations of SSH susceptible of password sniffing and some of these are still around. Although running against a reasonably modern client-servers pair (SSH v.2) should be safe, keys are still a good thing. -- Jon Solberg (remove "nospam." from email address)
From: Roy Smith on 31 May 2010 12:53 In article <slrni07k41.ecr.news(a)jonsolberg.se>, Jon Solberg <news(a)jonsolberg.nospam.se> wrote: > historically there has existed buggy implementations of SSH > susceptible of password sniffing and some of these are still around. > Although running against a reasonably modern client-servers pair (SSH > v.2) should be safe, keys are still a good thing. To expand on Jon's statement, note that to find a pre-v.2 implementation, you need to set the controls on the way-back machine to something like 15 years ago. You would have to put some effort into find any examples being used in the field today.
From: Robert Nichols on 31 May 2010 13:36
On 05/30/2010 07:40 PM, David Schwartz wrote: > On May 29, 4:22 pm, Robert Nichols > <SEE_SIGNAT...(a)localhost.localdomain.invalid> wrote: > >> Passive interception does not offer the opportunity to present a >> fake host key that is a prerequisite for a MITM attack. The >> design of the ssh protocol assumes that an eavesdropper is able >> to monitor both sides of the conversation. If you know of a way >> to crack an ssh connection by passive interception, I'm sure the >> security community would be quite eager to hear about it. >> >> Anyone is welcome to passively monitor my ssh connections at any >> time, and that includes connections where I had no previous >> knowledge of the remote system's public host key. > > Now, that is much more sensible than nonsense like "For someone who is > in the habit of ignoring key change warnings, concerns about > unprotected WiFi should be the least of his worries." It is perfectly > reasonable to be concerned about passive attacks but not so concerned > about active attacks. Really? If someone is lax enough about security to be running an unencrypted WiFi access point, I find it very hard to trust the network behind that access point enough to be "not so concerned" about a possible MITM attack lurking there. I'll re-phrase a bit. Channels using SSL protect against passive interception, so exposure from an unprotected WiFi access point does not present a significant threat. But, if you ignore key change warnings and certificate warnings, you have to trust every node in the network from end to end in order to trust that your connection is actually secure. That's pretty much an impossible condition unless that network is totally under your control. -- Bob Nichols AT comcast.net I am "RNichols42" |