Hi. I read the proposal here https://spec.torproject.org/proposals/365-http-connect-ext.html I hate these notes: * Tenses are weird. The whole proposal is written in a weird mix of tenses and sometimes in a weird mood. Writing the specifications in the future tense is confusing and will make moving the text to the main spec (which we should do after approval and as part of implementation) much harder. There should not be statements like "we should". Specifications, even proposals, should be definitive and therefore should be definite. So everything should be written in the present imperative. * "X-Tor-RPC-Target: Arti RPC support" is weird. Firstly, is this being a protocol registry? Secondly, do we not have a notion of critical extensions? We should be using that for something like this. * Proxy-Authorization Don't we need to continue to support http clients where we can't specify custom headers? If so then this spec is a recipe for continuation of the bad protocol where we use the whole of the Proxy-Authorization contents as an unconditional input to isolation. * Optimistic data This has a framing hazard, which could be a vulnerability in some circumstances. I wrote about this in this torspec MR https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/419#note_323... AFAICT that means if that MR merges, this feature will be removed? That would resolve the concern. * "X-Tor-Family-Preference: IP version preferences" What is this for? Is there not an existing way to control this over HTTP? * "X-Tor-Proxy: Indication for Tor proxy protocol support" Why does this need to be separate from the X-Tor-Capabilities ? * Capabilities
Clients SHOULD NOT inspect the contents of this header to determine whether a given feature is supported or not.
Should be MUST NOT. Capability guessing via version strings is completely terrible. I suggest: Clients MAY use this to determine whether some software has a particular bug, but the matching MUST NOT treat any future versions as buggy. So the bug must be fixed before this technique can be used. (This is the rule adopted by the PuTTY team for compatibility with broken ssh servers.) Thanks for your attention, Ian.
On Thu, Sep 4, 2025 at 12:44 PM Ian Jackson via tor-dev <tor-dev@lists.torproject.org> wrote:
Hi. I read the proposal here https://spec.torproject.org/proposals/365-http-connect-ext.html
Hi, thanks for the tenses!
I hate these notes:
* Tenses are weird.
The whole proposal is written in a weird mix of tenses and sometimes in a weird mood. Writing the specifications in the future tense is confusing and will make moving the text to the main spec (which we should do after approval and as part of implementation) much harder.
There should not be statements like "we should". Specifications, even proposals, should be definitive and therefore should be definite.
So everything should be written in the present imperative.
I'll try to do this in a revision.
* "X-Tor-RPC-Target: Arti RPC support" is weird.
Firstly, is this being a protocol registry?
Secondly, do we not have a notion of critical extensions? We should be using that for something like this.
What is the "this" that you're asking about in the sense of being a protocol registry, and how would it be a protocol registry? Do you mean, are we starting a list of special Tor HTTP CONNECT extensions? If so, we already have such a list in https://spec.torproject.org/http-connect.html . But I think you must mean something else? As for critical extensions: I don't think HTTP does those? Even if we add a specific "critical extension" mechanism to our own headers, we can't rely on any other implementation rejecting requests that have them. We _could_ say that some extensions are "critical" from a Tor POV, in the sense that they mean "you must either implement this or reject it if you are a Tor implementation". Is that what you have in mind? I don't think I'm understanding your questions very well here; maybe we should meet once you're back.
* Proxy-Authorization
Don't we need to continue to support http clients where we can't specify custom headers?
I think so, yes.
If so then this spec is a recipe for continuation of the bad protocol where we use the whole of the Proxy-Authorization contents as an unconditional input to isolation.
The idea here is that the existing mechanism (using the whole proxy-authorization content) would work, but it would be deprecated and cause a warning when used, whereas the new scheme (using Basic with username x-tor) would be the non-deprecated thing. I'll add a note about deprecation.
* Optimistic data
This has a framing hazard, which could be a vulnerability in some circumstances. I wrote about this in this torspec MR https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/419#note_323...
AFAICT that means if that MR merges, this feature will be removed? That would resolve the concern.
Yes; I'm just waiting for some of your replies on that ticket.
* "X-Tor-Family-Preference: IP version preferences"
What is this for? Is there not an existing way to control this over HTTP?
I cannot find any such header for regular HTTP.
* "X-Tor-Proxy: Indication for Tor proxy protocol support"
Why does this need to be separate from the X-Tor-Capabilities ?
The idea is that this tells you what the proxy implementation is, and that you'd use it for bug-checking as noted below.
* Capabilities
Clients SHOULD NOT inspect the contents of this header to determine whether a given feature is supported or not.
Should be MUST NOT. Capability guessing via version strings is completely terrible.
I suggest:
Clients MAY use this to determine whether some software has a particular bug, but the matching MUST NOT treat any future versions as buggy. So the bug must be fixed before this technique can be used.
(This is the rule adopted by the PuTTY team for compatibility with broken ssh servers.)
Agreed. ==== Please let me know what you think about the places above; I'll start revisions on this once I know what you think. -- Nick
Sorry for the delay replying: Nick Mathewson writes ("Re: [tor-dev] Proposal 365, review notes"):
On Thu, Sep 4, 2025 at 12:44 PM Ian Jackson via tor-dev
* "X-Tor-RPC-Target: Arti RPC support" is weird.
Firstly, is this being a protocol registry?
Secondly, do we not have a notion of critical extensions? We should be using that for something like this.
What is the "this" that you're asking about in the sense of being a protocol registry, and how would it be a protocol registry? Do you mean, are we starting a list of special Tor HTTP CONNECT extensions? If so, we already have such a list in https://spec.torproject.org/http-connect.html . But I think you must mean something else?
I think I must have misread it somehow. My previous comment now makes no sense to my current self. Sorry!
As for critical extensions: I don't think HTTP does those? Even if we add a specific "critical extension" mechanism to our own headers, we can't rely on any other implementation rejecting requests that have them.
In that case, this text in the proposal Implementations that do not support Arti RPC should reject requests containing this header. is doubtful. It might be an attempt to modify the base HTTP protocol and make an incompatible version of it. Maybe we could say something like An HTTP proxy that knows that it is forwarding requests over Tor, and generally supports these Tor extensions, should reject requests with this header, if it doesn't support Arti RPC. ?
If so then this spec is a recipe for continuation of the bad protocol where we use the whole of the Proxy-Authorization contents as an unconditional input to isolation.
The idea here is that the existing mechanism (using the whole proxy-authorization content) would work, but it would be deprecated and cause a warning when used, whereas the new scheme (using Basic with username x-tor) would be the non-deprecated thing. I'll add a note about deprecation.
But:
Don't we need to continue to support http clients where we can't specify custom headers?
I think so, yes.
I don't think we ought to try to deprecate clients were we can't specify custom headers. This implies that there should be a non-deprecated way to pass stream isolation information to a Tor HTTP proxy. That non-deprecated way ought not to use the bad "whole value" approach. IOW the present proposal deprecates the bad thing, but it doesn't provide a practical replacement.
* "X-Tor-Family-Preference: IP version preferences"
What is this for? Is there not an existing way to control this over HTTP?
I cannot find any such header for regular HTTP.
Hrm. I looked in MDN too, and didn't find one. There's Prefer but I don't think that's addressed strictly to proxies, and we'd have to have an ad-hoc extension there. It's probably better to invent our own header.
* "X-Tor-Proxy: Indication for Tor proxy protocol support"
Why does this need to be separate from the X-Tor-Capabilities ?
The idea is that this tells you what the proxy implementation is, and that you'd use it for bug-checking as noted below.
I think the comment field in the HTTP `Via` header could be used for this? I would very much prefer to direct people to a formal capabilities header. Certainly, testing for whether this is a Tor proxy ought to be done with the capabilities header.
* Capabilities
Clients SHOULD NOT inspect the contents of this header to determine whether a given feature is supported or not.
Should be MUST NOT. Capability guessing via version strings is completely terrible.
I suggest:
Clients MAY use this to determine whether some software has a particular bug, but the matching MUST NOT treat any future versions as buggy. So the bug must be fixed before this technique can be used.
(This is the rule adopted by the PuTTY team for compatibility with broken ssh servers.)
Agreed.
While I was looking at this I found the Accept-CH header. I think we don't want to use it here, but I thought I'd mention it. Also, since I was browsing MDN: Should we do something intelligent with Vary? Ian.
participants (2)
-
Ian Jackson -
Nick Mathewson