Enough administrative firewalls block non-80/443 ports that it's harder to deploy a protocol that uses them. This has got a bit better with UPNP and admin education, but it's the only reason absurdities like XMLRPC-over-HTTP got off the ground.
I'm actually psyched about Palo Alto's app-id and Snort OpenAppId that maybe firewalls will start allowing things through by behavior instead of port. Then we can have the internet back the way it was designed.
BOFH-admins will configure to accept-and-bitbucket-default; that is, make the other party think it's gotten through, and then ignore everything it has to say.
Maybe throw in some fuzzing: accept-and-respond-with-gibberish-default.
Comments
Enough administrative firewalls block non-80/443 ports that it's harder to deploy a protocol that uses them. This has got a bit better with UPNP and admin education, but it's the only reason absurdities like XMLRPC-over-HTTP got off the ground.
I'm actually psyched about Palo Alto's app-id and Snort OpenAppId that maybe firewalls will start allowing things through by behavior instead of port. Then we can have the internet back the way it was designed.
"Looks like TLS". "Also looks like TLS". "That's funny, this one looks like TLS too".
This is very true. That's why you MITM everything with your own CA!
Not necessarily; presumably conservative admins will still configure it to deny-default. Especially if the traffic is encrypted and unfamiliar.
BOFH-admins will configure to accept-and-bitbucket-default; that is, make the other party think it's gotten through, and then ignore everything it has to say.
Maybe throw in some fuzzing: accept-and-respond-with-gibberish-default.
accept-and-spam-MX-record-always
How about accept-and-randomly-lose? I'm a big fan of RFC 748 [1]
[1] https://tools.ietf.org/html/rfc748