Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

Since it's HTTPS, those proxies can't see the traffic anyway, so as long as they used SSL on port 443, they could use any protocol on top.


sort by: page size:

Can the proxies be (ab)used to proxy arbitrary HTTPS 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.

My school blocks all protocols except for HTTP and HTTPS. However they actually MITM HTTPS connections (I have to install a root certificate from them) so they can decrypt and see everything people do. So unfortunately typical TCP proxies don't work, even on port 443 as their transparent proxy makes the handshake. Instead, I have to put the payload in an HTTP request acting as a download, and another request as an upload, and make an OpenVPN connection over that.

A drawback is that a proxy won't be able to filter HTTPS traffic.

You... really don't understand HSTS or how proxies work. Any actual secure proxy configuration would still work just fine with HSTS. Its only ones that specifically downgrade HTTPS connections to HTTP ones that break.

Are proxies even relevant anymore with HTTPS? The only two scenarios I can imagine are reverse proxies at the server's side (which the server controls), and corporate MITMing firewalls (which I personally think are the plaugue and don't belong in 2021).

That's simple, they just won't, browsers will only support HTTP/2 over TLS, so proxies are effectively dead.

How do you proxy their traffic ?

I couldn't because they seem to use pinned certificates.


I've considered the HTTP proxy (anyone remember the fantastic proxomitron?), the problem is it would have to MITM all the HTTPS.

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.

Sure they can.. but they can’t get around your outgoing firewall rule that reroutes alle traffic for certain ports to the proxy.

Deep packet. That's how they got HTTP proxies too.

it's not hard to set up a proxy and just sniff the traffic to reconstruct the protocol

It's possible if the connection goes through an http proxy.

As opposed to HTTP where they proxy it and MITM it? I don't understand the objection.

You can still do that with HTTPS. Squid supports HTTPS proxying. Basically, you create your own root CA, distribute it to all endpoints on your network, and use squid to MITM all connections. That's (essentially) how most corporate proxies work.

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

HTTP Proxies do this.

> Though HTTP proxies are dead thanks to HTTPS

Well, they're not as broadly useful as without HTTPS, but you can still always MITM yourself to get a free transparent caching layer between the client and your end server.

next

Legal | privacy