Comment Re:Oh I just love (Score 4, Funny) 475
Here's an idea -- keep the food dish full all the time...
Let me guess, all of your cats are fat.
Here's an idea -- keep the food dish full all the time...
Let me guess, all of your cats are fat.
So there is no proof of it being in the wild and was only found on a website for analyzing files. So how exactly were they wrong?
Where do you think the "suspicious files" come from?
As with TLS, I'd like to see any future revisions of these secure protocols trim more fat.
Dude, SSH is half a meg. Calm down.
I think buddy's point is that SSH should deprecate support for old crypto libs because no one uses them anymore, and they are sort of an Achilles Heal...look at how easily GSM can be subverted because it supports old cypher protocols (and even one that is "No Encryption" encryption!)...anyway, point is: get rid of the stuff no one uses anymore, use only strong crypto with no option for in-the-clear, to reduce the potential for security issues. Our good friend AC just isn't so verbose about his idea...
When you're operating on a slow wireless connection with an already high amount of traffic on it, every bit counts.
Aw man! Nerdiest double-entendre ever! I'm jealous.
You open a SSH connection (client->server:22). This port is allowed on the firewall, it lets you through. But then the server decides to listen on UDP:(random port) and tells the client, back through the (encrypted) initial connection, which UDP port to contact. So you initiate a SSP UDP session on that port. How does the firewall knows it should let you through? Since the port number is communicated on an encrypted session, it doesn't have access to that information. So how does this work in a secure environment? The paper doesn't mention any mean for the server to communicate with the network which port its listening on.
My guess is as good as anyone else's, but I surmise it does a bit of packet trickery. Once device A (behind firewall) is connected to device B (may/may not be behind firewall, but at least one port is open, 22 by default in this case), device A can create an SSH tunnel...they really are rather neat and VERY useful as a means of security. For example, I have webmin running on a server, but its port (10 000) is blocked by the firewall. Once I connect to SSH I can redirect packets to a certain IP:Port combo (device A's IP:Random Port#) to the servers local address (127.0.0.1) and new UDP port, and voila: hidden/secure/direct connection. One can even make a tunnel in the other direction, so that the server can connect to a remote device in the same manner, and any application won't realize that it's even connecting to anything outside of its network.
Whomever thought of and implemented SSH tunnels is a master genius. I would shake his/her hand if I ever saw them.
I program, therefore I am.