That's a different point though as you're now effectively using HTTP as your transport layer rather than using your proprietary protocol "naked" on port 443. So whether you send your protocol in a proprietary binary format over HTTP or via JSON API's, it's still just HTTP over TLS. You're still sending HTTP headers, just with our own proprietary content as the body. The real problem is if you want persistent types of connections. As websockets have taught us: a great many equipment that supports HTTP don't support websockets and thus why even websites are still often stuck with RESTful APIs even when that doesn't always fit their problem quite right (that situation is improving however).
If one is using HTTP to transport your protocol (and the aforementioned websockets point isn't an issue) then your protocol should work over port 80 as well as 443. Barring any corporate / nationwide web filtering; but as others have already pointed out, that could also be an issue with 443 even with advantage of TLS.
By the way, was it Socks2HTTP you worked on? I remember that project back around the time you described and was quite fascinated by it.
> That's a different point though as you're now effectively using HTTP as your transport layer rather than using your proprietary protocol "naked" on port 443.
HTTPS is built on top of TLS, not the other way around. You can't (passively) tell if a 443 TLS connection is HTTPS or a proprietary stream. You can take a guess based on statistics (which is what the Chinese firewall does to detect tunneling) but that's about it.
I'm aware HTTP is built on top of TLS in HTTPS. I think what you're discussing now is a little different from the HTTPS as a transport vs bespoke protocols running "naked" over TCP/IP (unless I've badly misunderstood any of the previous posts?).
Warning: nonsensical brain dump follows:
However to address your point, you might be able to use SNI (which is sent from the client before the TLS connection is encrypted) to make some assumptions about the content. Granted this would be more in the realm of web filtering where you'd blacklist suspect domains or - in extreme cases - banned terms within hostnames. I wouldn't be surprised if SNI is one of the "statistics" the Chinese firewall uses (I'm not familiar with the implementation details of the Great Firewall of China")
A middlebox has no way[1] to tell what protocol is inside of a TLS connection unless it terminates TLS. It could be HTTP, it could be telnet, it could be whatever. So no, you're not effectively using HTTP as your transport.
1. Almost no way. The great firewall of china has traffic models of what payload sizes should look like for upload and download traffic of standard HTTP over TLS. If you start to tunnel TCP/IP over it, the pattern changes enough (small payloads for TCP ACKs, etc) that they will inject a TCP RST into the stream to screw up the connection. It's impressive and super frustrating.
> A middlebox has no way to tell what protocol is inside of a TLS connection unless it terminates TLS. It could be HTTP, it could be telnet, it could be whatever. So no, you're not effectively using HTTP as your transport.
While you're right that you could just use TLS without HTTP (as a great many services already do), the comment I was replying to was talking about running over HTTPS (he specifically stated HTTPS), ie TLS + HTTP. Which is effectively just using HTTP as your transport.
Like everything in IT, there's multiple ways one can approach this problem and it's probably fair to say that using TLS without wrapping your data inside a HTTP body makes greater sense if you're writing your own protocol from scratch. But on this occasion the post I was replying to - and many of the posts that preceded it - did make frequent references to HTTP and HTTPS.
> The great firewall of china has traffic models of what payload sizes should look like for upload and download traffic of standard HTTP over TLS. If you start to tunnel TCP/IP over it, the pattern changes enough (small payloads for TCP ACKs, etc) that they will inject a TCP RST into the stream to screw up the connection. It's impressive and super frustrating.
Ouch. Impressive though. Could one change the payload sizes of the TLS connection to make it look more like HTTP traffic? Shouldn't be that hard to do as most of the time you'd probably just need to add junk to the end of the server replies (assuming you have a client / server relationship with your TLS protocol). You'd probably need to make the TLS connection RESTful as well - to further mimic HTTPS and the limited connection times. Though before long you've just reinvented HTTP....
By the way, how well does websockets work over TLS? Do they throw up false positives on the Chinese firewall?
If one is using HTTP to transport your protocol (and the aforementioned websockets point isn't an issue) then your protocol should work over port 80 as well as 443. Barring any corporate / nationwide web filtering; but as others have already pointed out, that could also be an issue with 443 even with advantage of TLS.
By the way, was it Socks2HTTP you worked on? I remember that project back around the time you described and was quite fascinated by it.