News for hackers. Stuff that matters.
Re:QUIC and HTTP/3 Support Now in Firefox Nightly and Beta by aasasd on Friday April 16, 2021 @09:23PM (#26840839)
The Great Firewall does probing for ages now. It pauses the connection and sends its own request, checking what kind of protocol the server returns. Nothing stops these firewalls from trying ‘connect-ip’. The path could be used as a secret ‘key’ to thwart too-curious firewalls (though the protocol probably won't do much against DPI anyway).
Re:QUIC and HTTP/3 Support Now in Firefox Nightly and Beta by shawnz on Friday April 16, 2021 @10:05PM (#26841044)
Why not just require authentication?
Re:QUIC and HTTP/3 Support Now in Firefox Nightly and Beta by tmp538394722 on Saturday April 17, 2021 @02:47AM (#26842136)
The goal is to look like normal boring traffic.
Re:QUIC and HTTP/3 Support Now in Firefox Nightly and Beta by shawnz on Saturday April 17, 2021 @03:20AM (#26842295)
The parent is talking about having the firewall attempt its own request, not some kind of sniffing (which shouldn't be possible with TLS)
Re:QUIC and HTTP/3 Support Now in Firefox Nightly and Beta by saurik on Saturday April 17, 2021 @04:48AM (#26842671)
It would then be weirdly important that a mis-authenticated CONNECT-IP then look the same as if CONNECT-IP were not implemented, as opposed to returning an authorization error of some kind (which seems weirder than hiding the method via the path).
Re:QUIC and HTTP/3 Support Now in Firefox Nightly and Beta by shawnz on Saturday April 17, 2021 @05:10AM (#26842771)
True. But the path method has issues too, like, how would you implement that with HTTP 1.1? The "path" field is actually part of the target, so you would have to send the request like `CONNECT-IP https://remote-server/mount-point` which seems backwards. (EDIT: and also you still need to make sure you don't give the wrong kind of error if the path is wrong, like a 404 instead of a 501 not implemented or whatever)

As a possible solution for the discovery by authorization error problem, maybe a convention could be established where an authorization error is returned by default if CONNECT-* isn't configured.

Re:QUIC and HTTP/3 Support Now in Firefox Nightly and Beta by saurik on Saturday April 17, 2021 @05:49AM (#26842981)
Huh. It is possible that I simply didn't understand the spec, as I was (and am...) pretty sure that CONNECT-IP (at least at the HTTP semantics level) just takes a path (and only /)--like GET--without an associated "extra" authority, as it is creating an IP tunnel: there is no remote host (as there would be with an old-school CONNECT); like, what is the "target" here? I am just talking to the server and asking it to give me an IP bridge, right? What does "remote-server" represent to an IP tunnel?
Re:QUIC and HTTP/3 Support Now in Firefox Nightly and Beta by shawnz on Saturday April 17, 2021 @09:02AM (#26843929)
You're right, I misunderstood the usage. That does make the possibility of using the path more compelling
Re:QUIC and HTTP/3 Support Now in Firefox Nightly and Beta by aasasd on Saturday April 17, 2021 @06:03AM (#26843048)
I guess authentication via https before ‘connect-ip’ would work. Or, authenticating with headers in the same first ‘connect-ip’ request, if the server responds with ‘invalid method’ when not authenticated.
Re:QUIC and HTTP/3 Support Now in Firefox Nightly and Beta by aasasd on Saturday April 17, 2021 @08:52AM (#26843872)
By the way, probing at connection time, that I mentioned in my original comment, isn't actually necessary. The GFW will just scan known popular-ish hosts, trying ‘connect-ip’ and banning everything that works as a proxy. (Connection-time probing would just make it easier to discover the hosts, such that collecting the IPs and stats separately is not needed.)