mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-28 06:13:31 +01:00
Proposal 121: Limit maximum descriptor size to 20 kilobytes to prevent abuse.
svn:r16303
This commit is contained in:
parent
1a76cd179a
commit
1b2545ff98
@ -26,6 +26,8 @@ Change history:
|
|||||||
scalable authorization protocol (2.2), rewrote existing
|
scalable authorization protocol (2.2), rewrote existing
|
||||||
authorization protocol (2.3); changes based on discussion
|
authorization protocol (2.3); changes based on discussion
|
||||||
with Nick
|
with Nick
|
||||||
|
31-Jul-2008 Limit maximum descriptor size to 20 kilobytes to prevent
|
||||||
|
abuse.
|
||||||
|
|
||||||
Overview:
|
Overview:
|
||||||
|
|
||||||
@ -212,6 +214,23 @@ Details:
|
|||||||
(clients and servers would have to be upgraded anyway for using the new
|
(clients and servers would have to be upgraded anyway for using the new
|
||||||
features).
|
features).
|
||||||
|
|
||||||
|
An adversary could try to abuse the fact that introduction points can be
|
||||||
|
encrypted by storing arbitrary, unrelated data in the hidden service
|
||||||
|
directory. This abuse can be limited by setting a hard descriptor size
|
||||||
|
limit, forcing the adversary to split data into multiple chunks. There
|
||||||
|
are some limitations that make splitting data across multiple descriptors
|
||||||
|
unattractive: 1) The adversary would not be able to choose descriptor IDs
|
||||||
|
freely and have to implement an own indexing structure. 2) Validity of
|
||||||
|
descriptors is limited to at most 24 hours after which descriptors need
|
||||||
|
to be republished.
|
||||||
|
|
||||||
|
The regular descriptor size in bytes is 745 + num_ipos * 837 + auth_data.
|
||||||
|
A large descriptor with 7 introduction points and 5 kilobytes of
|
||||||
|
authorization data would be 11724 bytes in size. The upper size limit of
|
||||||
|
descriptors should be set to 20 kilobytes, which limits the effect of
|
||||||
|
abuse while retaining enough flexibility in designing authorization
|
||||||
|
protocols.
|
||||||
|
|
||||||
1.2. Client authorization at introduction point
|
1.2. Client authorization at introduction point
|
||||||
|
|
||||||
The next possible authorization point after downloading and decrypting
|
The next possible authorization point after downloading and decrypting
|
||||||
|
Loading…
Reference in New Issue
Block a user