blob: 0a30efcfc52d689547e825d1616af03948327b80 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
|
GetTor specification
Jacob Appelbaum
0. Preface
This document describes GetTor and how to properly implementation GetTor.
1. Overview
GetTor was created to resolve direct and indirect censorship of Tor's software.
In many countries and networks Tor's main website is blocked and would be Tor
users are unable to download even the source code to the Tor program. Other
software hosted by the Tor Project is similarly censored. The filtering
of the possible download sites is sometimes easy to bypass by using our TLS enabled
website. In other cases the website and all of the mirrors are entirely
blocked; this is a situation where a user seems to actually need Tor to fetch
Tor. We discovered that it is feasible to use alternate transport methods such
as SMTP between a non-trusted third party or with IRC and XDCC.
2. Implementation
Any compliant GetTor implementation will implement at least a single transport
to meet the needs of a certain class of users. It should be i18n and l10n compliant
for all user facing interactions; users should be able to manually set their
language and this should serve as their preference for localization of any
software delivered. The implementation must be free software and it should be
freely available by request from the implementation that they interface with
to download any of the other software available from that GetTor instance.
Security and privacy considerations should be described on a per transport
basis.
2.1 Reference implementation
We have implemented[0] a compliant GetTor that supports SMTP as a transport.
3. SMTP transport
The SMTP transport for GetTor should allow users to send any RFC822 compliant message
in any known human language; GetTor should respond in whatever language is
detected with supplementary translations in the same email. GetTor shall offer
a list of all available software in the body of the email - it should offer the
software as a list of packages and their subsequent descriptions.
3.1 SMTP transport security considerations
Any GetTor instance that offers SMTP as a transport should optionally implement
the checking of DKIM signatures to ensure that email is not forged.
Optionally GetTor should take an OpenPGP key from the user and encrypt the
response with a blinded message.
3.2 SMTP transport privacy considerations
Any GetTor instance that offers SMTP as a transport must at least store the
requester's address for the time that it takes to process a response. This
should not be written to any permanent storage medium; GetTor should function
without any long term storage excepting a cache of files that it will send to
any user who requests it.
GetTor may optionally collect anonymized usage statistics to better understand
how GetTor[1] is in use. This must not include any personally identifying
information about any of the requester beyond language selection.
4. Other transports
At this time no other transports have been specified. IRC XDCC is a likely useful
system as is XMPP/Jabber with the newest OTR file sharing transport.
5. Implementation suggestions
It is suggested that any compliant GetTor instance should be written in a so
called "safe" language such as Python.
[0] https://gitweb.torproject.org/gettor.git
[1] https://metrics.torproject.org/packages.html
|
