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

101–108 of 108 posts

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

#101

Post by saclark11 »

mr_mitm wrote: post #8

Pretty cool. Have you seen considerations regarding port knocking by Moxie Marlinspike? I think he raises some valid points: https://github.com/moxie0/knockknock Instead of using UDP he reads the firewall log. Also he prevents replay attacks (even though his implementation is apparently not secure in this regard). Unfortunately his code is ancient and in Python 2, so a rust implementation would be awesome.

I wonder if Moxie would now consider knockknock "cryptographically doomed"? From the README, whose commit [1] is dated 2011-09-15:

> The request is encrypted using AES in CTR mode, with an HMAC-SHA1 using the authenticate-then-encrypt paradigm.

A mere three months later, he would publish The Cryptographic Doom Principle [2] (dated 2011-12-13).

[1]: https://github.com/moxie0/knockknock/commit/e24eb33f666fc092...

[2]: https://moxie.org/2011/12/13/the-cryptographic-doom-principl...

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

#102

Post by [deleted] »

saclark11 wrote: post #101
mr_mitm wrote: post #8

Pretty cool. Have you seen considerations regarding port knocking by Moxie Marlinspike? I think he raises some valid points: https://github.com/moxie0/knockknock Instead of using UDP he reads the firewall log. Also he prevents replay attacks (even though his implementation is apparently not secure in this regard). Unfortunately his code is ancient and in Python 2, so a rust implementation would be awesome.

I wonder if Moxie would now consider knockknock "cryptographically doomed"? From the README, whose commit [1] is dated 2011-09-15: > The request is encrypted using AES in CTR mode, with an HMAC-SHA1 using the authenticate-then-encrypt paradigm. A mere three months later, he would publish The Cryptographic Doom Principle [2] (dated 2011-12-13). [1]: https://github.com/moxie0/knockknock/commit/e24eb33f666fc092... [2]:…

[deleted]

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

#103

Post by justaj »

mr_mitm wrote: post #8

Pretty cool. Have you seen considerations regarding port knocking by Moxie Marlinspike? I think he raises some valid points: https://github.com/moxie0/knockknock Instead of using UDP he reads the firewall log. Also he prevents replay attacks (even though his implementation is apparently not secure in this regard). Unfortunately his code is ancient and in Python 2, so a rust implementation would be awesome.

Very unfortunate.

http://www.thoughtcrime.org/software/knockknock/ has been excluded from the Wayback Machine, and archive.is is captchawalled.

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

#104

Post by Jnr »

throwitaway1123 wrote: post #97
Jnr wrote: post #96

Earlier quoted context omitted.

No, the example is - you go to friends, join their Wifi, have the same external IP, send the knock from your phone/laptop to open 443 to that IP, and then you can connect from TV or their computers.

Port knocking only handles authentication (it's basically a crude password). It doesn't ensure the integrity (tamper prevention) or privacy of your connection. You would need to set up SSL certificates to handle that. You also need to get the TV to accept those certificates, which would require either a public DNS record (which exposes your server's IP via the certificate transparency log to any client that can issue…

You are slightly wrong.

TLS is not mandatory in all cases, but if you want to use it, it is not an issue having a certificate. Certificate itself has nothing to do with DNS beyond the verification step.

And even then you do not have to open any ports, even to letsencrypt verification, since you can use DNS verification method instead (for example using Cloudflare API).

And there can be a public DNS record but it doesn't say anything about ports. And the CT transparency log doesn't say anything about ports or IP addresses.

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

#105

Post by throwitaway1123 »

Jnr wrote: post #104
throwitaway1123 wrote: post #97

Earlier quoted context omitted.

Port knocking only handles authentication (it's basically a crude password). It doesn't ensure the integrity (tamper prevention) or privacy of your connection. You would need to set up SSL certificates to handle that. You also need to get the TV to accept those certificates, which would require either a public DNS record (which exposes your server's IP via the certificate transparency log to any client that can issue…

You are slightly wrong. TLS is not mandatory in all cases, but if you want to use it, it is not an issue having a certificate. Certificate itself has nothing to do with DNS beyond the verification step. And even then you do not have to open any ports, even to letsencrypt verification, since you can use DNS verification method instead (for example using Cloudflare API). And there can be a public DNS record but it does…

You are both slightly wrong, and slightly misunderstanding what I'm saying.

> TLS is not mandatory in all cases, but if you want to use it, it is not an issue having a certificate.

TLS is mandatory if you want to ensure your connection isn't being eavesdropped on or tampered with.

> And even then you do not have to open any ports, even to letsencrypt verification, since you can use DNS verification method instead (for example using Cloudflare API).

Yes this is called the ACME DNS challenge. I've used it many times, but if you want to be able to type in your server's domain name on a friend's TV and have it resolve to your server's IP address, then you'll need a public DNS record.

> Certificate itself has nothing to do with DNS beyond the verification step.

Yes it does, because most certificate authorities only sign certificates for fully qualified domain names, not IP addresses [1], so it obviously does involve the domain name system (you can view the domain name associated with a certificate in your browser, it'll be listed under the field "common name"). On a desktop computer you could get around this by editing the hosts file to map any domain name to any arbitrary IP address, but you can't do that on a TV.

> And there can be a public DNS record but it doesn't say anything about ports. And the CT transparency log doesn't say anything about ports or IP addresses.

I never said anything about ports, I said a public DNS record exposes the server's IP address. The whole point of the domain name system is to convert domain names into IP addresses, so that you can actually use the internet protocol to connect to a server's IP (internet protocol) address. Try running dig from the command line on literally any domain name and watch it expose the server's IP. Malicious bots can watch the transparency log to find out about new certificates [2], then run dig or some other tool to issue a DNS request (to determine the IP address of the server), and then start hammering the server to search for vulnerabilities or even potentially to just DDOS it. If you use a wildcard certificate it's harder for attackers to figure out which subdomain to query to find your server's IP, but with WireGuard I don't need a domain name at all.

[1] https://community.letsencrypt.org/t/ssl-on-a-ip-instead-of-d...

[2] https://community.letsencrypt.org/t/suspicious-web-traffic-a...

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

#106

Post by Jnr »

throwitaway1123 wrote: post #105
Jnr wrote: post #104

Earlier quoted context omitted.

You are slightly wrong. TLS is not mandatory in all cases, but if you want to use it, it is not an issue having a certificate. Certificate itself has nothing to do with DNS beyond the verification step. And even then you do not have to open any ports, even to letsencrypt verification, since you can use DNS verification method instead (for example using Cloudflare API). And there can be a public DNS record but it does…

You are both slightly wrong, and slightly misunderstanding what I'm saying. > TLS is not mandatory in all cases, but if you want to use it, it is not an issue having a certificate. TLS is mandatory if you want to ensure your connection isn't being eavesdropped on or tampered with. > And even then you do not have to open any ports, even to letsencrypt verification, since you can use DNS verification method instead (fo…

It does not matter - all the ports are closed.

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

#107

Post by throwitaway1123 »

Jnr wrote: post #106
throwitaway1123 wrote: post #105

Earlier quoted context omitted.

You are both slightly wrong, and slightly misunderstanding what I'm saying. > TLS is not mandatory in all cases, but if you want to use it, it is not an issue having a certificate. TLS is mandatory if you want to ensure your connection isn't being eavesdropped on or tampered with. > And even then you do not have to open any ports, even to letsencrypt verification, since you can use DNS verification method instead (fo…

It does not matter - all the ports are closed.

> It does not matter - all the ports are closed.

Yeah and I have a lock on my door. I still won't post my address on HN. It's all about defense in depth.

Another thing I forgot to mention is that port knocking only works if your hypothetical friend has a dedicated static IP. If your ISP decides to reassign your IP address then IP allowlists are useless. Many ISPs in the US run this racket where they make you pay for a "business account" to get a dedicated IP, even if you only want an IP6 address (which are plentiful).

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

#108

Post by Thorrez »

beagle3 wrote: post #26
Thorrez wrote: post #13

Earlier quoted context omitted.

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.

Spoofing UDP is easy. Spoofing TCP is useless - you actually need to receive all the packets sent to the original TCP, which means either you are already on the receiving path, or managed to put yourself on it e.g. through a BGP route advertisement - either way, it leaves some trail and much harder to carry out. (And even so, the attacker still has to go through SSH authentication or an SSH vulnerability)

>Spoofing TCP is useless - you actually need to receive all the packets sent to the original TCP

What do you mean "original TCP"? I'm talking about an attacker creating a new TCP connection with a spoofed source address.

> which means either you are already on the receiving path

Yes, I believe that's the threat model under discussion here. Tepix mentioned an attacker who can intercept a packet, which I believe means the attacker is already on the receiving path.

Post reply on HN