The main issue I see here is the use of a port other than 443 - this means traffic will likely be blocked for many users, also over 443 traffic should be encrypted to avoide bad proxies messing up the request headers
If you are using secure web sockets (wss), this shouldn't be an issue as the traffic goes over port 443 and the proxy won't be able to tell if it's HTTP or another type of traffic.
Proxying on 443 would 100% work, I can say that without trying. The only case that would not work is if the firewall would do any deep packet inspection to see whether the connection setup resembles https. That of course would also be easy to circumvent, but I don't think any firewall would go so far.
That's insufficient. There's nothing stopping a web site (or ad on a website) from forming its own DoH request that bypasses the browser and the port. It can be done entirely within the HTTPS stream.
Explicit proxies are no problem. There are a lot of servers behind proxies. No problem there.
There is plenty of client software that can be configured to use proxies. Also no problem there.
Where it goes wrong is transparent proxies (also called 'middleboxes') that operate without consent of the endpoints. In general, those proxies have caused so many network problems that most people involved in the IETF will happily see them die.
And the easiest way to do that is to encrypt all traffic.
Frankly, I can't think of any way to proxy or decrypt it that would result in the packets still being destined for the same Microsoft IP, but with port 80 instead of 443.
The only explanation I could think of was that it falls back to HTTP if HTTPS is unavailable and they blocked port 443, which not only would be bat**** insane, but I tested and that does not occur.
Proxies are not the only thing that is necessary to support - login portals is another related usage in the same general area.
Basically the problem is that the encryption possibilities available assume Internet is a dumb pipe between source and destination, but that is simply not the case.
Many proxies deployed today won't understand the upgrade header and in the case of an explicit proxy config will ignore the CONNECT operation if performed on 80 (rather than 443).
This is a small service for developers. Please see the FAQ comment. There are not currently 40,000 proxy connections to the public server (more like 10). If there are then the server will gracefully give an error and terminate the connection.
Please do not spread fear, uncertainty, and doubt about security without precise details. It’s not conducive to a healthy conversation.
You said it better than I did. That was one of the issues we ran into since we have third party APIs that require IP whitelisting, certs and VPNs, a proxy just won't work in that instance. Can't wait for the Python implementation...
I'm pretty sure that you could also setup an OpenVPN server. It can be configured to listen over TCP port 443, so it can also get past proxies. It may be a bit more setup on the server-side, but it should be a lot easier on the clients.
Everyone I've seen using something like this or Google cloud shell is doing it to get around oppressive corporate proxies to get some kind of work done.
Proxies like Forcepoint/Websense are content-aware enough that simple tricks like having sshd listen on port 443 don't work.
The idea behind obfsproxy is that you don't want it looking like port 443 on the wire. You can infact mask the traffic using the domain fronting technique providing you setup obfsproxy correctly. I haven't tried it myself, but I have analyzed Tunnelbear's 'ghostbear' feature with wireshark and the traffic looks fairly innocuous which is what we're aiming for.
reply