Opened 3 years ago
Last modified 3 years ago
#18141 new enhancement
Tame "reading from ORPort" error logs in meek-server
Reported by: | dcf | Owned by: | dcf |
---|---|---|---|
Priority: | Medium | Milestone: | |
Component: | Obfuscation/meek | Version: | |
Severity: | Normal | Keywords: | |
Cc: | tor-admin@… | Actual Points: | |
Parent ID: | Points: | ||
Reviewer: | Sponsor: |
Description
meek-server operators have asked to disable this error message:
reading from ORPort: read tcp 127.0.0.1:YYYY->127.0.0.1:ZZZZ: read: connection reset by peer
It occurs whenever tor closes the TCP connection between meek-server and itself. This happens very frequently when you restart the meek-server process, because it loses its cache of current session-IDs. When clients connect using their formerly valid session-IDs, meek-server treats them as new connections and opens new ORPort connections. The clients push TLS application data over the new connection, which doesn't match what tor expects from a new connection, so it shuts it down. Right after restarting you get a ton of these messages for a while (can be more than 10 per second).
Child Tickets
Change History (4)
comment:1 follow-up: 3 Changed 3 years ago by
comment:2 Changed 3 years ago by
Cc: | tor-admin@… added |
---|
comment:3 follow-up: 4 Changed 3 years ago by
Replying to dcf:
One possible approach: have client indicate in their HTTP requests whether they intend to start a new session with a new session ID. meek-server would drop requests with an unknown session ID that don't have this bit set, and would request the bit to be not set for any existing session ID. That way we would drop the client connection before it gets passed through to tor.
Hm. Won't this break backwards compatibility?
comment:4 Changed 3 years ago by
Replying to yawning:
Replying to dcf:
One possible approach: have client indicate in their HTTP requests whether they intend to start a new session with a new session ID. meek-server would drop requests with an unknown session ID that don't have this bit set, and would request the bit to be not set for any existing session ID. That way we would drop the client connection before it gets passed through to tor.
Hm. Won't this break backwards compatibility?
No; we'll fall back to the previous behavior if clients don't send whatever header has the flag in it (treat it as true/false/null). I think we're going to have to add a header with flags for #12857 anyway.
One possible approach: have client indicate in their HTTP requests whether they intend to start a new session with a new session ID. meek-server would drop requests with an unknown session ID that don't have this bit set, and would request the bit to be not set for any existing session ID. That way we would drop the client connection before it gets passed through to tor.