[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #18938 [Core Tor/Tor]: Authorities should reject non-ASCII content in ExtraInfo descriptors
#18938: Authorities should reject non-ASCII content in ExtraInfo descriptors
-------------------------------------------------+-------------------------
Reporter: teor | Owner: neel
Type: defect | Status:
| assigned
Priority: Medium | Milestone: Tor:
| unspecified
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: needs-proposal, tor-dirauth, needs- | Actual Points:
spec, easy, 034-triage-20180328, |
034-removed-20180328 |
Parent ID: #24033 | Points: 1
Reviewer: | Sponsor:
-------------------------------------------------+-------------------------
Old description:
> In #18656, we discovered that authorities don't validate that ExtraInfo
> descriptors are printable ASCII before accepting them.
>
> Authorities (and HSDirs) should check every directory document they
> receive consists only of "printing ASCII", as defined in torspec:
> {{{
> NL = The ascii LF character (hex value 0x0a).
> KeywordChar ::= 'A' ... 'Z' | 'a' ... 'z' | '0' ... '9' | '-'
> ArgumentChar ::= any printing ASCII character except NL.
> WS = (SP | TAB)+
> }}}
>
> I've heard others say that the following lines allow non-ASCII content,
> but I'm not sure if that's actually the case, and if it is, how many
> relays this would affect:
> * the "platform" line in relay descriptors, which is a "human-readable
> string",
> * the contact "info" line in relay descriptors, which has an undefined
> format.
>
> If it is, I'd recommend we make them all ASCII for consistency, and
> update torspec to clarify, and include it as a "major" change in an 0.2.x
> tor release.
>
> (This means that some users will be unable to spell their names
> correctly. But there was never any guarantee that 8-bit characters in
> "info" would be interpreted as users intended. I think security is more
> important here.)
New description:
In #18656, we discovered that authorities don't validate that ExtraInfo
descriptors are printable ASCII before accepting them.
Authorities (and HSDirs) should check every ~~directory~~ extrainfo
document they receive consists only of "printing ASCII", as defined in
torspec:
{{{
NL = The ascii LF character (hex value 0x0a).
KeywordChar ::= 'A' ... 'Z' | 'a' ... 'z' | '0' ... '9' | '-'
ArgumentChar ::= any printing ASCII character except NL.
WS = (SP | TAB)+
}}}
I've heard others say that the following lines allow non-ASCII content,
but I'm not sure if that's actually the case, and if it is, how many
relays this would affect:
* the "platform" line in relay descriptors, which is a "human-readable
string",
* the contact "info" line in relay descriptors, which has an undefined
format.
Edit: allowing users to spell their names correctly is important. That's
why we'll use utf-8 for relay descriptors, votes, and consensuses.
~~If it is, I'd recommend we make them all ASCII for consistency, and
update torspec to clarify, and include it as a "major" change in an 0.2.x
tor release.
(This means that some users will be unable to spell their names correctly.
But there was never any guarantee that 8-bit characters in "info" would be
interpreted as users intended. I think security is more important here.)~~
--
Comment (by teor):
Change description based on prop285 utf-8 support.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18938#comment:34>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs