Opened 3 years ago

Last modified 3 years ago

#12677 reopened enhancement

fteproxy server's response to malformed messages

Reported by: kpdyer Owned by: kpdyer
Priority: Medium Milestone:
Component: Obfuscation/FTE Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Raised here: https://trac.torproject.org/projects/tor/ticket/12673

cypherpunks suggests that fteproxy, when using an HTTP regex, should tolerate a range of HTTP headers. Specifically, an fteproxy server when using HTTP will terminate the connection, if the following is submitted:

GET /<encoded_data> HTTP/1.1\r\n
Host: tpo.org\r\n
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Firefox/24.0\r\n
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n
Accept-Language: en-us,en;q=0.5\r\n
Accept-Encoding: gzip, deflate\r\n
Connection: keep-alive\r\n
\r\n

It turns out that this is a complex issue to solve in general, as one solution we could allow custom error handlers in fteproxy that are activated under certain cases.

As a step towards this, we should probably distinguish between the following two cases:

  • The server receives a message that is in the language specified by the regex, but is malformed.
  • The server receives a message that is NOT in the language specified by the regex, and is, by definition, malformed.

Thoughts?

Child Tickets

Change History (4)

comment:1 Changed 3 years ago by cypherpunks

Any progress?

comment:2 Changed 3 years ago by kpdyer

No, unfortunately.

What's more, this isn't on my roadmap and I don't have the spare cycles to tackle it. So, this will probably stay in an open state until someone else picks it up.

comment:3 Changed 3 years ago by cypherpunks

Resolution: wontfix
Status: newclosed

comment:4 Changed 3 years ago by gk

Resolution: wontfix
Status: closedreopened

kpdyer did not say something about a won't fix. Reopening.

Note: See TracTickets for help on using tickets.