[mschempp]

You are right, but if you are in a network that blocks every packet that is sent to any port which is not 80 or 443 your port knocking capabilities are very limited.

Ultimately reading firewall logs to do port knocking is most secure way, because - as you said - there is virtually no attack surface.

I would argue that port knocking is extremely inconvenient and does not work in every scenario. So for me it's a tradeoff between "ultimate" security and convenience.

[codetrotter]

Port knocking appeals to me because of how few bytes you have to send. But a system I’ve been thinking of (and surely a bunch of people before me) goes like this:

Instead of knocking on ports, send actual HTTP requests to different paths. Over TLS or just plain HTTP.

So where you’d port knock a sequence of ports here instead you send GET requests to some different, publicly known paths

GET /index.htm

GET /about_us.htm

GET /about_us.htm

GET /index.htm

GET /about_us.htm

GET /products.htm

You get the idea.

And now then the challenge is that if you’re on a network that does HTTP caching, it would interfere with this.

But we already have the well known cache-busting technique for that right, so

GET /css/main.css?ver=64729929

GET /js/bundle.js?ver=947367292

GET /js/bundle.js?ver=7483939

And so on. And version is for example current Unix time and is actually ignored in terms of “knocking”. Only the path matters.