Dear OpenSSH team, First of all thanks a lot for your good work on developing such a usable peace of software. Nice job. As you may know, we have some issues using OpenSSH in Iran. Recently the government did some packet filtering on some protocols, including SSH. We don't know what exactly they've done but it appears to be some routing rule that prevents SSH protocol to initiate a connection. Its like that the handshake packet is dropped. Fortunately there is a patch on OpenSSH done by Bruce Leidl ( https://github.com/brl/obfuscated-openssh) that obfuscates the handshake packet and luckily it helps us pass through this annoying packet filtering. But sadly this patch isn't implemented in the main project. We, a group of Iranian OpenSSH users, recommend you to include this useful patch in the main project because: 0. As Bruce Leidl explains it's true that the communication is secured during a session, but before starting a session since the encryption keys have not yet been determined, there is no encryption and the handshake packets are insecure. 1. It's always better to have more options. In this case, having the handshake packet obfuscated is an important choice to make. 2. The patch nicely adds the ability of obfuscating the handshake and makes no harm to the rest of the project. So why not? 3. We really want you to do it. Thank you very much and best regards.
Anything in the mainline OpenSSH code will be adapted to by your adversaries. (Put another way, if you want your code to remain functional, it has to remain a patch.) On Thu, Jan 12, 2012 at 10:58 AM, iam iranian <x.issuer at gmail.com> wrote:> Dear OpenSSH team, > > First of all thanks a lot for your good work on developing such a usable > peace of software. Nice job. > As you may know, we have some issues using OpenSSH in Iran. Recently the > government did some packet filtering on some protocols, including SSH. We > don't know what exactly they've done but it appears to be some routing rule > that prevents SSH protocol to initiate a connection. Its like that the > handshake packet is dropped. > Fortunately there is a patch on OpenSSH done by Bruce Leidl ( > https://github.com/brl/obfuscated-openssh) that obfuscates the handshake > packet and luckily it helps us pass through this annoying packet filtering. > But sadly this patch isn't implemented in the main project. > > We, a group of Iranian OpenSSH users, recommend you to include this useful > patch in the main project because: > 0. As Bruce Leidl explains it's true that the communication is secured > during a session, but before starting a session since the encryption keys > have not yet been determined, there is no encryption and the handshake > packets are insecure. > 1. It's always better to have more options. In this case, having the > handshake packet obfuscated is an important choice to make. > 2. The patch nicely adds the ability of obfuscating the handshake and makes > no harm to the rest of the project. So why not? > 3. We really want you to do it. > > Thank you very much and best regards. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >
Hello Sir, I have been reading the protocol description and, although there are some 'arbitrary' choices (eg. the stream cipher, the hash, the value of OBFUSCATE_HASH_ITERATIONS, or why not include the counter in the iterations), the easiest way is _probably_ to follow the public description (this is only obfuscation). But I think the weakest point is that your government can easily block it by not allowing a connection sending random bytes. And there is no provision for it to look like 'something else'. I think the best hiding is what the tor projet strives to do, enmasquerading as a HTTPS handshake. Which is probably overkill to consider as an addition for openssh. I started thinking about something like a HTTP POST, which triggered the detection from a point where the characters mathed some kind of crazy condition, such as the difference of two characters with the next two were a prime number, thus forcing to read an arbitrary-length content (and the payload common enough it would appear in 'legitimate' content, too). I wonder, does the new filters also block ssh if there's a banner? (eg. it shows a Shakespeare poem before connecting you). Not that it matters much (they can easily close it), but they could have forgotten that. I pondered if there were an easy way to skip the cleartext (eg. automatically assuming that you received a SSH-2.0 banner) but the negotiation options are even more obvious, so a stream cipher does seem required. Steganographying ssh is an interesting problem. Good luck for you all