gettor-spec.txt 3.3 KB

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