ssh security questions
Hello,
i have two questions to ask regarding security.
1) if i use "putty" to ssh into a shell account, what data will be encrypted? i guess all the commands i issue are encrypted. but what about the remote host name? i mean, after firing up putty, i will be asked for a hostname and protocol to use. suppose i key in "boo.hello.org" and choose "ssh". will my ISP be able to tell i'm trying to ssh the site "boo.hello.org"? can i tell i'm using ssh rather than telnet? In a nutshell, how much will my local ISP know about what i'm doing?
2) i'm using "tera term" with ssh package installed. when i fire up "ttssh" and key in domain name i want to connect to, another windows pops up, asking for my user name and password. The thing is: i'm concerned with the lines under the username and password area: "use plain passwords to log in","use RSA key to log in", "use challenge/response(TIS) to log in" and by default, "use plain passwords to log in" is ticked. So does it mean my username and passwords are sent in plain texts? and if i use ttssh to upload files to a site, are they encrypted in the uploading process or not?
another question is: how can i "use RSA key to log in"?
Thanks,
KEN
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
At it again, ken?!
It is as Jim says, all the traffic in your ssh "tunnel" is encrypted, so they can buffer all they like/analyze whichever way they want, they will still only know the plain obvious things about your session: your IP address, the remote hosts IP address, the destination and source ports, the packets TTL (Time To Live, or hop counter), and not bl**dy much else.
They _could_ try to decrypt the traffic, but... an ssh-session can carry quite a load (especially if used as a VPN tunnel, and not a "secured terminal"), and they would have to brute-force crack every packet... not really feasible, even if "they" would be a "foreign third party" (that is "The Enemy" ... Used to be the russians to the US (and to a large part still is to us here in Sweden...). This is precisely the reason the US governament tries to control strong cryptography, so that their enemies cannot conceal there doings (this effort is spelled f-u-t-i-l-e ;-).
So the answer is: Yes, if they really really wanted to, they actually might, but it hasn't been done in any highly publicised way (it would be a tremendous feat), and the only ones that have the resources to do it... is the US governament. Not your average ISP.
As you might remember from our previous discussion on this subject, what the RSA authentication is all about signing and validation. So yes, in some small ways this would increase security a little, but not really that much. The key could be compromised (somebody nicked the computer), and in the case you use it without a password it would actually *decrease* security.
You should use openssl.
-- Glenn
It is as Jim says, all the traffic in your ssh "tunnel" is encrypted, so they can buffer all they like/analyze whichever way they want, they will still only know the plain obvious things about your session: your IP address, the remote hosts IP address, the destination and source ports, the packets TTL (Time To Live, or hop counter), and not bl**dy much else.
They _could_ try to decrypt the traffic, but... an ssh-session can carry quite a load (especially if used as a VPN tunnel, and not a "secured terminal"), and they would have to brute-force crack every packet... not really feasible, even if "they" would be a "foreign third party" (that is "The Enemy" ... Used to be the russians to the US (and to a large part still is to us here in Sweden...). This is precisely the reason the US governament tries to control strong cryptography, so that their enemies cannot conceal there doings (this effort is spelled f-u-t-i-l-e ;-).
So the answer is: Yes, if they really really wanted to, they actually might, but it hasn't been done in any highly publicised way (it would be a tremendous feat), and the only ones that have the resources to do it... is the US governament. Not your average ISP.
As you might remember from our previous discussion on this subject, what the RSA authentication is all about signing and validation. So yes, in some small ways this would increase security a little, but not really that much. The key could be compromised (somebody nicked the computer), and in the case you use it without a password it would actually *decrease* security.
You should use openssl.
-- Glenn
ASKER
hey nice to see you here again, Glenn!
>>So the answer is: Yes, if they really really wanted to, >>they actually might, but it hasn't been done in any >>highly publicised way (it would be a tremendous feat), >>and the only ones that have the resources to do it... is >>the US governament. Not your average ISP.
well well well...i'm travelling in prc and they have very strict rules about what you can see and what you can't. my local ISP may not be able to decrypt anything, but if they become aware that someone is using ssh sessions a lot, they might report it to some kind of authority and no privacy for me any more. there are many brilliant programmers in china...
KEN
(now i'm lost. i got two gurus to answer my questions and i'm happy with all the comments they put...i only put 50 points for this question...geeze, it's like you fell in love with two gorgeous girls and can't decide whom you should pick up...:) maybe i should increase points to 100 and ask another quick question to finalize this post?? )
>>So the answer is: Yes, if they really really wanted to, >>they actually might, but it hasn't been done in any >>highly publicised way (it would be a tremendous feat), >>and the only ones that have the resources to do it... is >>the US governament. Not your average ISP.
well well well...i'm travelling in prc and they have very strict rules about what you can see and what you can't. my local ISP may not be able to decrypt anything, but if they become aware that someone is using ssh sessions a lot, they might report it to some kind of authority and no privacy for me any more. there are many brilliant programmers in china...
KEN
(now i'm lost. i got two gurus to answer my questions and i'm happy with all the comments they put...i only put 50 points for this question...geeze, it's like you fell in love with two gorgeous girls and can't decide whom you should pick up...:) maybe i should increase points to 100 and ask another quick question to finalize this post?? )
That state certainly might attempt such a feat, and possibly have the resources. You might try to "up" the number of key bits somewhat in /etc/ssh/sshd.conf (if your "server side" is linux/OpenSSH).
What you might do to ... confuse the matter somewhat, if you control both ends of the tunnel, is to _not_ use the SSH Well Known Port (22), but something innocuous like telnet (port 23) or HTTP (port 80). With OpenSSH, just start the server as "sshd -p <port number>", then connect with "ssh -p <the same port>" (I'm sure it can be configured in putty/ttssh too). Just remember to disable anything else that listens to that port...
Oh and don't worry about the points. Jim was first with a correct answer, so he should have 'em. Don't up the points and go off on a tangent question, but rather put in another question at 50 points. I'll look at it, and I'm sure Jim will too (he seems rather active ATM;). If you pose another question, notify me here.
-- Glenn
What you might do to ... confuse the matter somewhat, if you control both ends of the tunnel, is to _not_ use the SSH Well Known Port (22), but something innocuous like telnet (port 23) or HTTP (port 80). With OpenSSH, just start the server as "sshd -p <port number>", then connect with "ssh -p <the same port>" (I'm sure it can be configured in putty/ttssh too). Just remember to disable anything else that listens to that port...
Oh and don't worry about the points. Jim was first with a correct answer, so he should have 'em. Don't up the points and go off on a tangent question, but rather put in another question at 50 points. I'll look at it, and I'm sure Jim will too (he seems rather active ATM;). If you pose another question, notify me here.
-- Glenn
Right, the monitors wouldn't be able to see your ssh session contents, but in a place like the PRC I'd be concerned that they might take the existance of an encrypted session as evidence of wrong doing. Unless your login sessions could expose very sensitive data I'd consider not using SSH to avoid the appearance of possible improper activity.
ASKER
hi,
to Glenn:
i've posted another question:
https://www.experts-exchange.com/jsp/qManageQuestion.jsp?ta=linux&qid=20319130
to jlevie:
but on the other hand, there are SO MANY users that it would be very time-consuming and difficult to decrypt an ssh session, especially when they haven't detected something explicit first...there are more than 30 million internet users... anyway, noone like the idea of being put behind the bars :)
cheers,
KEN
to Glenn:
i've posted another question:
https://www.experts-exchange.com/jsp/qManageQuestion.jsp?ta=linux&qid=20319130
to jlevie:
but on the other hand, there are SO MANY users that it would be very time-consuming and difficult to decrypt an ssh session, especially when they haven't detected something explicit first...there are more than 30 million internet users... anyway, noone like the idea of being put behind the bars :)
cheers,
KEN
I'm joining to late, anyway ..
All important things about ssh still said (encrypted, can be decrypted with briute-force-attack, host and port visible).
AFAIK ssh encryption cannot be improced by the user, it's either protocol version 1 (SSH1) or protocol version 2 (SSH2), where the later is more save.
The things about RSA, DSA etc. encryption is just aabout the user authentificatio, not the encryption of the data itself.
ssh changes its symetric encryption (session) key periodicaly (not shure about the time, 2 hours or so)
Any attacker (who ever it is) most likely tries to break this session key, which needs to be done every XX minutes again. So theory and experinace (not practice) tells us that ssh is safe.
If someone logs all the traffic, he might get a chance. But think about the resources necessary to store the logs, and then to compute the session keys ...
Ken, if you need to anonymize the traffic, I suggest something like http://www.htthost.com/, check for anonymizer proxies there too.
BTW, keep in mind that ttssh only supports SSH1, unfortunately.
All important things about ssh still said (encrypted, can be decrypted with briute-force-attack, host and port visible).
AFAIK ssh encryption cannot be improced by the user, it's either protocol version 1 (SSH1) or protocol version 2 (SSH2), where the later is more save.
The things about RSA, DSA etc. encryption is just aabout the user authentificatio, not the encryption of the data itself.
ssh changes its symetric encryption (session) key periodicaly (not shure about the time, 2 hours or so)
Any attacker (who ever it is) most likely tries to break this session key, which needs to be done every XX minutes again. So theory and experinace (not practice) tells us that ssh is safe.
If someone logs all the traffic, he might get a chance. But think about the resources necessary to store the logs, and then to compute the session keys ...
Ken, if you need to anonymize the traffic, I suggest something like http://www.htthost.com/, check for anonymizer proxies there too.
BTW, keep in mind that ttssh only supports SSH1, unfortunately.
I didn't mean that the PRC monitors would attempt to decrypt the session to see what you were doing. Rather, I meant that the existance of an SSH session could be construed to be evidence of improper activity, since they would not be able to tell what was being done within the session.
As an example, there are certain classes of networks where complete auditing of all network traffic and user activity is required. On such a network the very existance of an encrypted session is taken to be evidence of improper activity. It then becomes the responsibility of the user to prove that what they were doing did not violate any of the rules that govern network use. On those networks, as soon as an encrypted session is discovered the user is banned from the network and a full investigation into his/her's activities is initiated. The PRC monitors could adopt simiar policies for their networks.
As an example, there are certain classes of networks where complete auditing of all network traffic and user activity is required. On such a network the very existance of an encrypted session is taken to be evidence of improper activity. It then becomes the responsibility of the user to prove that what they were doing did not violate any of the rules that govern network use. On those networks, as soon as an encrypted session is discovered the user is banned from the network and a full investigation into his/her's activities is initiated. The PRC monitors could adopt simiar policies for their networks.
ASKER
hi,
yes they could introduce such a policy. but i don't think they are applying the strictest policies...
take an example: many people know what a proxy server is and they are able to view so-called "inappropriate" contents by first connecting to a proxy server and then go to some sites from there. Then the authority found this out and react by:
1) ban those proxy servers
2) forge "friendly" proxy servers which are actually set up by the authority and thus they are able to monitor everything
another example is that one of my friends receive highly-sensitive contents from "the outside world" in his emails, which are supposed to be filtered in the first place.
by saying this i mean they are not doing their job in accordance with the highest requirements, although they are able to do so. on the other hand, i guess with more than 30 million users, they don't want to buffer _everything_ ...
oh, another quick question is: if i browse sites through a proxy server, will i be easily traced?
Thanks,
KEN
yes they could introduce such a policy. but i don't think they are applying the strictest policies...
take an example: many people know what a proxy server is and they are able to view so-called "inappropriate" contents by first connecting to a proxy server and then go to some sites from there. Then the authority found this out and react by:
1) ban those proxy servers
2) forge "friendly" proxy servers which are actually set up by the authority and thus they are able to monitor everything
another example is that one of my friends receive highly-sensitive contents from "the outside world" in his emails, which are supposed to be filtered in the first place.
by saying this i mean they are not doing their job in accordance with the highest requirements, although they are able to do so. on the other hand, i guess with more than 30 million users, they don't want to buffer _everything_ ...
oh, another quick question is: if i browse sites through a proxy server, will i be easily traced?
Thanks,
KEN
You answered that yourself ken.
If you (the "tracer") have control of the (ussumed moderately busy) proxy, then no. Not really. Of course, Jims "big Brother" scenario above applies... "You have been seen to use this 'known bad' server..."
If you have control of the proxy...:-)
-- Glenn
If you (the "tracer") have control of the (ussumed moderately busy) proxy, then no. Not really. Of course, Jims "big Brother" scenario above applies... "You have been seen to use this 'known bad' server..."
If you have control of the proxy...:-)
-- Glenn
ussumed == assumed
-- G
-- G
beside the proxy pros and cons described above, have a look at the htthost link, that's a proxy which goes through https, which is a common used port and protocol (: let have big brother fun with 1'st decrypting SSL, then the tunneled ssh connection;-)
Which still leaves the problem of Big Brother seeing you establish the connection to the "big bad proxy" ... the point being that BB doesn't have to look at the content, in this scenario, to ascertain "badness" on your part. Think Orwellian (Animal Farm, 1984). One tend to take certain priviledges for granted when living in a democratic society... proven guilt etc...
And Big Brother don't have to "buffer traffic" for this. A passive sniffer will do nicely.
-- Glenn
And Big Brother don't have to "buffer traffic" for this. A passive sniffer will do nicely.
-- Glenn
Glenn, I assume that you didn't read htthost's docs.
It's not restricted to a special (unique) "big bad proxy", you can setup your own one anywhere.
You still can see the SSL connection, and decrypt it, but it's getting harder, and that'll be sufficient with nowerdays hardware.
Such software is admin's (big brother) nightmare, but some people really need it.
It's not restricted to a special (unique) "big bad proxy", you can setup your own one anywhere.
You still can see the SSL connection, and decrypt it, but it's getting harder, and that'll be sufficient with nowerdays hardware.
Such software is admin's (big brother) nightmare, but some people really need it.
Aha, you caught me!
Then I'll have to catch you right back:-).
"The existance of ssl traffic (assumed, since it is encrypted and use dport 443) is sure proof of you untrustworthy and subversive personality. We find you guilty on all charges, and sentence you to immediate summary..."
See? Jims point really, but... well, it's not about technology, it's about the mindframe of dictatorship.
You're right that ken probably would be OK with that, but... if the information he handles (inside the PRC) is very damning, I for one think he's showing good common sense in questioning all security aspects. I'm sure he is more familiar with the actual situation inside the PRC, and can make a more informed evaluation, than any of us, as to toolusage, risk management etc.
-- Glenn
Then I'll have to catch you right back:-).
"The existance of ssl traffic (assumed, since it is encrypted and use dport 443) is sure proof of you untrustworthy and subversive personality. We find you guilty on all charges, and sentence you to immediate summary..."
See? Jims point really, but... well, it's not about technology, it's about the mindframe of dictatorship.
You're right that ken probably would be OK with that, but... if the information he handles (inside the PRC) is very damning, I for one think he's showing good common sense in questioning all security aspects. I'm sure he is more familiar with the actual situation inside the PRC, and can make a more informed evaluation, than any of us, as to toolusage, risk management etc.
-- Glenn
ASKER
A rose is a rose is a rose!
and i would say "a guru is a guru is a guru!" :)
i learned a lot from both of you, very much appreciated! so do you have something more to put down here or you want me to finalize this post?
Cheers,
KEN
and i would say "a guru is a guru is a guru!" :)
i learned a lot from both of you, very much appreciated! so do you have something more to put down here or you want me to finalize this post?
Cheers,
KEN
I'm guilty :-)
'cause I use SSL, some are guilty 'cause they are born at the wrong place on earth :-(
EOC -- End of Chat
'cause I use SSL, some are guilty 'cause they are born at the wrong place on earth :-(
EOC -- End of Chat
CC. The world simply isn't a fair place. The sadest part is that many dictatorships in the 20:th century actually started as utopian dreams of a better place. Sigh.
EOC
-- Glenn
EOC
-- Glenn
ASKER
Thanks jlevie, but i'm more concerned with my local ISP rather than sniffers...
1)are you saying that my local ISP is able to tell the host i'm connecting to, and source/destination IPs and nothing else? i was told that my local ISP uses something called "enforced buffering" (that's not the exactly correct term, just something like that) and they just buffer and thus monitor ALL THE TRAFFIC. so if they do a strict and persistent analysis, will they be able to find out my username/passwords/issued commands and something else? furthermore, how "robust" is ssh? can my local ISP decrypt it if they REALLY want it?
2) will it be "more secure" if i use RSA authentication? as you said, "the entire ssh session is encrypted, including the initial authentication phase. so your user name and password aren't visible to a sniffer" so what's the point using RSA? and what tool/package should i use in order to get my RSA PUBLIC/PRIVATE KEYS? i only know how to generate a pair of public/private keys using GnuPG, but don't know if they are RSA keys...
your reply will be very much appreciated.
KEN