Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Ruroco – like port knocking, but better

github.com

Post reply on HN
Print view View original

11–20 of 108 posts

Re: Show HN: Ruroco – like port knocking, but better

#11

Post by cies »

Tepix wrote: post #7

The security section fails to explain how the service prevents an attacker from intercepting a packet, then sending it again himself with a new sender IP address to whitelist SSH access his IP address. The original (authorized) sender would then think something went wrong (packet loss), send a new packet and be none the wiser.

I agree with your observation, but this is merely put fwd as an alternative to port knocking.

Port knocking is IMHO just to keep your sshd logs clean from huge lists of failed attempts, that prevent me from actually finding interesting information in them.

Re: Show HN: Ruroco – like port knocking, but better

#12

Post by wongarsu »

cius wrote: post #10
jagged-chisel wrote: post #9

Earlier quoted context omitted.

Encrypting with the private key has the name “signing” because it’s convenient. Both are technically correct.

It sounds like my misunderstanding. So is this just a nomenclature mix up? I'll have to do more research, because I am under the impression there is something special about the private key other than the fact it was designated as such at generation time. I have many holes to fill in my knowledge around this.

The special thing about the private key is that if you have the private key you can also derive the public key from it. Meanwhile if you only have the public key you can't derive the private key.

Hence you always use the private key for decrypting or for signing. But other than switching which key to use signing and encrypting are the same thing

Re: Show HN: Ruroco – like port knocking, but better

#13

Post by Thorrez »

Tepix wrote: post #7

The security section fails to explain how the service prevents an attacker from intercepting a packet, then sending it again himself with a new sender IP address to whitelist SSH access his IP address. The original (authorized) sender would then think something went wrong (packet loss), send a new packet and be none the wiser.

Even if that was protected against (by putting the source IP inside the payload), I'm not sure it's really much more secure. An attacker who can intercept the packet can likely also spoof the source IP, so the attacker could wait for you to open it with your IP, and then use your IP using spoofing.

Re: Show HN: Ruroco – like port knocking, but better

#14

Post by praptak »

If your use case is "remotely trigger execution of a very small set of fixed commands, securely" then there's Ostiary: https://openwrt.org/docs/guide-user/services/remote_control/...

Its value is in the simplicity of the crypto protocol used for this - basically "hash a password with a one time pad".

Re: Show HN: Ruroco – like port knocking, but better

#16

Post by rmholt »

Tepix wrote: post #7

The security section fails to explain how the service prevents an attacker from intercepting a packet, then sending it again himself with a new sender IP address to whitelist SSH access his IP address. The original (authorized) sender would then think something went wrong (packet loss), send a new packet and be none the wiser.

Afaik it doesn't. The only useful thing there is, is a deadline on each packet so the retransmission would have to be fast, but it seems doable.

https://github.com/beac0n/ruroco/blob/ce766751b51c8ff6246a2b...

The encrypted information is current time, command and random data. So the server could feasibly detect that a retransmission has occurred but that's about it.

Re: Show HN: Ruroco – like port knocking, but better

#17

Post by password4321 »

I documented the snippets I needed when setting up Caddy + fastcgi to run shell scripts remotely with self-signed HTTPS Basic Auth on an internal server a couple years ago: https://hn-notes.pages.dev/20221128

Although far more heavyweight and barely relevant to this discussion since it's not hidden, sometimes it's useful to be able to do things remotely in an emergency without a private key.

Re: Show HN: Ruroco – like port knocking, but better

#18

Post by brookst »

Tepix wrote: post #7

The security section fails to explain how the service prevents an attacker from intercepting a packet, then sending it again himself with a new sender IP address to whitelist SSH access his IP address. The original (authorized) sender would then think something went wrong (packet loss), send a new packet and be none the wiser.

Fair point, but all that gets you is SSH listening, they way it has to be now anyways if you want remote access.

This doesn’t feel like an unpickable lock so much as a decorative cover that makes the lock less obvious.

Re: Show HN: Ruroco – like port knocking, but better

#19

Post by orev »

jbstack wrote: post #15

What would be the reasons to choose this over fwknop?

While I wish that fwknop would have displaced the whole idea of port knocking by now, this adds the element of triggering command execution based on the packet, instead of the single fixed action of just opening a port.

Re: Show HN: Ruroco – like port knocking, but better

#20

Post by Thorrez »

jagged-chisel wrote: post #9
cius wrote: post #6

Your docs say: client uses private key to encrypt -> server uses public key to decrypt. Do you mean: client uses private key to sign -> server uses public key to verify? My understanding is private keys decrypt/sign and public keys encrypt/verify. Either your usage, your docs, or my understanding seem to be wrong. I think I'll stick with fwknop for now.

Encrypting with the private key has the name “signing” because it’s convenient. Both are technically correct.

I think that's only true if you're using direct asymmetric cryptography. In the real world people use hybrid asymmetric cryptography.

Hybrid asymmetric signing is: hash the payload, then use direct asymmetric encryption/signing to encrypt/sign the hash with the private key.

Hybrid asymmetric encryption is: encrypt the payload with symmetric encryption (e.g. AES) with a random key, then encrypt the random key with direct asymmetric encryption using the public key.

As you can see, with hybrid asymmetric cryptography, there's a difference between signing and encryption besides the public vs private key difference.

Post reply on HN