4 ms·

Here is a better idea. If it looks like a duck, walks like a duck and quacks like a duck, is it a duck? Run ssh on port 443 at the same time you run a web serv

by rd0 14y ago

Here is a better idea. If it looks like a duck, walks like a duck and quacks like a duck, is it a duck? Run ssh on port 443 at the same time you run a web server on the same port. http://www.rutschle.net/tech/sslh.shtml http://www.rutschle.net/tech/sslh.shtml I've seen implementatios in about a page of C, which I can vet.

cperciva 14y ago
That is terrifyingly evil. And I mean that in the best possible way.
- yungchin 14y ago
  As someone who doesn't have a very subtle understanding in English, I can't figure out if this is an endorsement, or very much not one? (serious question! I'd rather fly by your crypto-intuitions than my own...)
  - cperciva 14y ago
    It's incredibly cool. Not something I'd necessarily want to actually use in production, though.
casca 14y ago
In the ssh protocol, the server sends a banner first. For HTTPS, the client sends certificate data first. How is it possible to run these 2 services on the same port without changing the client?
- peterwwillis 14y ago
  The link he gave is a custom multiplexing daemon that handles those cases. A timeout value is used to connect to the SSH daemon if the server hasn't received anything from the client.
  - JoachimSchipper 14y ago
    I've done the same thing to set up a "SVN-or-git repository" on a machine on which I only had my own shell account. Fortunately, that never made it to production.
rd0 14y ago
The concept that the protocol multiplexer uses is pretty sound and simple. I have and would continue to deploy in production, but as usual you have to know what is going on and what the implications are. You do pay a known penalty in complexity and startup time but you gain a world of obscurity. It's like every other tool; it has it's uses, but it's not suitable for all problems. The fact that an implementation is possible in a few pages of C goes a long way, especially when the install base for that tool is small and you need to understand the details. If nothing else, the concept stands on it's own and might offer ideas in solving other problems.

by rd0 14y ago

cperciva 14y ago

That is terrifyingly evil. And I mean that in the best possible way.

yungchin 14y ago
As someone who doesn't have a very subtle understanding in English, I can't figure out if this is an endorsement, or very much not one? (serious question! I'd rather fly by your crypto-intuitions than my own...)
- cperciva 14y ago
  It's incredibly cool. Not something I'd necessarily want to actually use in production, though.

casca 14y ago

In the ssh protocol, the server sends a banner first. For HTTPS, the client sends certificate data first. How is it possible to run these 2 services on the same port without changing the client?

peterwwillis 14y ago
The link he gave is a custom multiplexing daemon that handles those cases. A timeout value is used to connect to the SSH daemon if the server hasn't received anything from the client.
- JoachimSchipper 14y ago
  I've done the same thing to set up a "SVN-or-git repository" on a machine on which I only had my own shell account. Fortunately, that never made it to production.

rd0 14y ago

The concept that the protocol multiplexer uses is pretty sound and simple. I have and would continue to deploy in production, but as usual you have to know what is going on and what the implications are. You do pay a known penalty in complexity and startup time but you gain a world of obscurity. It's like every other tool; it has it's uses, but it's not suitable for all problems. The fact that an implementation is possible in a few pages of C goes a long way, especially when the install base for that tool is small and you need to understand the details. If nothing else, the concept stands on it's own and might offer ideas in solving other problems.