124-tls-certificates.txt 14 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315
  1. Filename: 124-tls-certificates.txt
  2. Title: Blocking resistant TLS certificate usage
  3. Version: $Revision$
  4. Last-Modified: $Date$
  5. Author: Steven J. Murdoch
  6. Created: 2007-10-25
  7. Status: Superseded
  8. Overview:
  9. To be less distinguishable from HTTPS web browsing, only Tor servers should
  10. present TLS certificates. This should be done whilst maintaining backwards
  11. compatibility with Tor nodes which present and expect client certificates, and
  12. while preserving existing security properties. This specification describes
  13. the negotiation protocol, what certificates should be presented during the TLS
  14. negotiation, and how to move the client authentication within the encrypted
  15. tunnel.
  16. Motivation:
  17. In Tor's current TLS [1] handshake, both client and server present a
  18. two-certificate chain. Since TLS performs authentication prior to establishing
  19. the encrypted tunnel, the contents of these certificates are visible to an
  20. eavesdropper. In contrast, during normal HTTPS web browsing, the server
  21. presents a single certificate, signed by a root CA and the client presents no
  22. certificate. Hence it is possible to distinguish Tor from HTTP by identifying
  23. this pattern.
  24. To resist blocking based on traffic identification, Tor should behave as close
  25. to HTTPS as possible, i.e. servers should offer a single certificate and not
  26. request a client certificate; clients should present no certificate. This
  27. presents two difficulties: clients are no longer authenticated and servers are
  28. authenticated by the connection key, rather than identity key. The link
  29. protocol must thus be modified to preserve the old security semantics.
  30. Finally, in order to maintain backwards compatibility, servers must correctly
  31. identify whether the client supports the modified certificate handling. This
  32. is achieved by modifying the cipher suites that clients advertise support
  33. for. These cipher suites are selected to be similar to those chosen by web
  34. browsers, in order to resist blocking based on client hello.
  35. Terminology:
  36. Initiator: OP or OR which initiates a TLS connection ("client" in TLS
  37. terminology)
  38. Responder: OR which receives an incoming TLS connection ("server" in TLS
  39. terminology)
  40. Version negotiation and cipher suite selection:
  41. In the modified TLS handshake, the responder does not request a certificate
  42. from the initiator. This request would normally occur immediately after the
  43. responder receives the client hello (the first message in a TLS handshake) and
  44. so the responder must decide whether to request a certificate based only on
  45. the information in the client hello. This is achieved by examining the cipher
  46. suites in the client hello.
  47. List 1: cipher suites lists offered by version 0/1 Tor
  48. From src/common/tortls.c, revision 12086:
  49. TLS1_TXT_DHE_RSA_WITH_AES_128_SHA
  50. TLS1_TXT_DHE_RSA_WITH_AES_128_SHA : SSL3_TXT_EDH_RSA_DES_192_CBC3_SHA
  51. SSL3_TXT_EDH_RSA_DES_192_CBC3_SHA
  52. Client hello sent by initiator:
  53. Initiators supporting version 2 of the Tor connection protocol MUST
  54. offer a different cipher suite list from those sent by pre-version 2
  55. Tors, contained in List 1. To maintain compatibility with older Tor
  56. versions and common browsers, the cipher suite list MUST include
  57. support for:
  58. TLS_DHE_RSA_WITH_AES_256_CBC_SHA
  59. TLS_DHE_RSA_WITH_AES_128_CBC_SHA
  60. SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
  61. SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
  62. Client hello received by responder/server hello sent by responder:
  63. Responders supporting version 2 of the Tor connection protocol should compare
  64. the cipher suite list in the client hello with those in List 1. If it matches
  65. any in the list then the responder should assume that the initiatior supports
  66. version 1, and thus should maintain the version 1 behavior, i.e. send a
  67. two-certificate chain, request a client certificate and do not send or expect
  68. a VERSIONS cell [2].
  69. Otherwise, the responder should assume version 2 behavior and select a cipher
  70. suite following TLS [1] behavior, i.e. select the first entry from the client
  71. hello cipher list which is acceptable. Responders MUST NOT select any suite
  72. that lacks ephemeral keys, or whose symmetric keys are less then KEY_LEN bits,
  73. or whose digests are less than HASH_LEN bits. Implementations SHOULD NOT
  74. allow other SSLv3 ciphersuites.
  75. Should no mutually acceptable cipher suite be found, the connection MUST be
  76. closed.
  77. If the responder is implementing version 2 of the connection protocol it
  78. SHOULD send a server certificate with random contents. The organizationName
  79. field MUST NOT be "Tor", "TOR" or "t o r".
  80. Server certificate received by initiator:
  81. If the server certificate has an organizationName of "Tor", "TOR" or "t o r",
  82. the initiator should assume that the responder does not support version 2 of
  83. the connection protocol. In which case the initiator should respond following
  84. version 1, i.e. send a two-certificate client chain and do not send or expect
  85. a VERSIONS cell.
  86. [SJM: We could also use the fact that a client certificate request was sent]
  87. If the server hello contains a ciphersuite which does not comply with the key
  88. length requirements above, even if it was one offered in the client hello, the
  89. connection MUST be closed. This will only occur if the responder is not a Tor
  90. server.
  91. Backward compatibility:
  92. v1 Initiator, v1 Responder: No change
  93. v1 Initiator, v2 Responder: Responder detects v1 initiator by client hello
  94. v2 Initiator, v1 Responder: Responder accepts v2 client hello. Initiator
  95. detects v1 server certificate and continues with v1 protocol
  96. v2 Initiator, v2 Responder: Responder accepts v2 client hello. Initiator
  97. detects v2 server certificate and continues with v2 protocol.
  98. Additional link authentication process:
  99. Following VERSION and NETINFO negotiation, both responder and
  100. initiator MUST send a certification chain in a CERT cell. If one
  101. party does not have a certificate, the CERT cell MUST still be sent,
  102. but with a length of zero.
  103. A CERT cell is a variable length cell, of the format
  104. CircID [2 bytes]
  105. Command [1 byte]
  106. Length [2 bytes]
  107. Payload [<length> bytes]
  108. CircID MUST set to be 0x0000
  109. Command is [SJM: TODO]
  110. Length is the length of the payload
  111. Payload contains 0 or more certificates, each is of the format:
  112. Cert_Length [2 bytes]
  113. Certificate [<cert_length> bytes]
  114. Each certificate MUST sign the one prececeding it. The initator MUST
  115. place its connection certificate first; the responder, having
  116. already sent its connection certificate as part of the TLS handshake
  117. MUST place its identity certificate first.
  118. Initiators who send a CERT cell MUST follow that with an LINK_AUTH
  119. cell to prove that they posess the corresponding private key.
  120. A LINK_AUTH cell is fixed-lenth, of the format:
  121. CircID [2 bytes]
  122. Command [1 byte]
  123. Length [2 bytes]
  124. Payload (padded with 0 bytes) [PAYLOAD_LEN - 2 bytes]
  125. CircID MUST set to be 0x0000
  126. Command is [SJM: TODO]
  127. Length is the valid portion of the payload
  128. Payload is of the format:
  129. Signature version [1 byte]
  130. Signature [<length> - 1 bytes]
  131. Padding [PAYLOAD_LEN - <length> - 2 bytes]
  132. Signature version: Identifies the type of signature, currently 0x00
  133. Signature: Digital signature under the initiator's connection key of the
  134. following item, in PKCS #1 block type 1 [3] format:
  135. HMAC-SHA1, using the TLS master secret as key, of the
  136. following elements concatenated:
  137. - The signature version (0x00)
  138. - The NUL terminated ASCII string: "Tor initiator certificate verification"
  139. - client_random, as sent in the Client Hello
  140. - server_random, as sent in the Server Hello
  141. - SHA-1 hash of the initiator connection certificate
  142. - SHA-1 hash of the responder connection certificate
  143. Security checks:
  144. - Before sending a LINK_AUTH cell, a node MUST ensure that the TLS
  145. connection is authenticated by the responder key.
  146. - For the handshake to have succeeded, the initiator MUST confirm:
  147. - That the TLS handshake was authenticated by the
  148. responder connection key
  149. - That the responder connection key was signed by the first
  150. certificate in the CERT cell
  151. - That each certificate in the CERT cell was signed by the
  152. following certificate, with the exception of the last
  153. - That the last certificate in the CERT cell is the expected
  154. identity certificate for the node being connected to
  155. - For the handshake to have succeeded, the responder MUST confirm
  156. either:
  157. A) - A zero length CERT cell was sent and no LINK_AUTH cell was
  158. sent
  159. In which case the responder shall treat the identity of the
  160. initiator as unknown
  161. or
  162. B) - That the LINK_AUTH MAC contains a signature by the first
  163. certificate in the CERT cell
  164. - That the MAC signed matches the expected value
  165. - That each certificate in the CERT cell was signed by the
  166. following certificate, with the exception of the last
  167. In which case the responder shall treat the identity of the
  168. initiator as that of the last certificate in the CERT cell
  169. Protocol summary:
  170. 1. I(nitiator) <-> R(esponder): TLS handshake, including responder
  171. authentication under connection certificate R_c
  172. 2. I <->: VERSION and NETINFO negotiation
  173. 3. R -> I: CERT (Responder identity certificate R_i (which signs R_c))
  174. 4. I -> R: CERT (Initiator connection certificate I_c,
  175. Initiator identity certificate I_i (which signs I_c)
  176. 5. I -> R: LINK_AUTH (Signature, under I_c of HMAC-SHA1(master_secret,
  177. "Tor initiator certificate verification" ||
  178. client_random || server_random ||
  179. I_c hash || R_c hash)
  180. Notes: I -> R doesn't need to wait for R_i before sending its own
  181. messages (reduces round-trips).
  182. Certificate hash is calculated like identity hash in CREATE cells.
  183. Initiator signature is calculated in a similar way to Certificate
  184. Verify messages in TLS 1.1 (RFC4346, Sections 7.4.8 and 4.7).
  185. If I is an OP, a zero length certificate chain may be sent in step 4;
  186. In which case, step 5 is not performed
  187. Rationale:
  188. - Version and netinfo negotiation before authentication: The version cell needs
  189. to come before before the rest of the protocol, since we may choose to alter
  190. the rest at some later point, e.g switch to a different MAC/signature scheme.
  191. It is useful to keep the NETINFO and VERSION cells close to each other, since
  192. the time between them is used to check if there is a delay-attack. Still, a
  193. server might want to not act on NETINFO data from an initiator until the
  194. authentication is complete.
  195. Appendix A: Cipher suite choices
  196. This specification intentionally does not put any constraints on the
  197. TLS ciphersuite lists presented by clients, other than a minimum
  198. required for compatibility. However, to maximize blocking
  199. resistance, ciphersuite lists should be carefully selected.
  200. Recommended client ciphersuite list
  201. Source: http://lxr.mozilla.org/security/source/security/nss/lib/ssl/sslproto.h
  202. 0xc00a: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
  203. 0xc014: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  204. 0x0039: TLS_DHE_RSA_WITH_AES_256_CBC_SHA
  205. 0x0038: TLS_DHE_DSS_WITH_AES_256_CBC_SHA
  206. 0xc00f: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
  207. 0xc005: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
  208. 0x0035: TLS_RSA_WITH_AES_256_CBC_SHA
  209. 0xc007: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
  210. 0xc009: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
  211. 0xc011: TLS_ECDHE_RSA_WITH_RC4_128_SHA
  212. 0xc013: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  213. 0x0033: TLS_DHE_RSA_WITH_AES_128_CBC_SHA
  214. 0x0032: TLS_DHE_DSS_WITH_AES_128_CBC_SHA
  215. 0xc00c: TLS_ECDH_RSA_WITH_RC4_128_SHA
  216. 0xc00e: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
  217. 0xc002: TLS_ECDH_ECDSA_WITH_RC4_128_SHA
  218. 0xc004: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
  219. 0x0004: SSL_RSA_WITH_RC4_128_MD5
  220. 0x0005: SSL_RSA_WITH_RC4_128_SHA
  221. 0x002f: TLS_RSA_WITH_AES_128_CBC_SHA
  222. 0xc008: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
  223. 0xc012: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
  224. 0x0016: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
  225. 0x0013: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
  226. 0xc00d: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
  227. 0xc003: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
  228. 0xfeff: SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA (168-bit Triple DES with RSA and a SHA1 MAC)
  229. 0x000a: SSL_RSA_WITH_3DES_EDE_CBC_SHA
  230. Order specified in:
  231. http://lxr.mozilla.org/security/source/security/nss/lib/ssl/sslenum.c#47
  232. Recommended options:
  233. 0x0000: Server Name Indication [4]
  234. 0x000a: Supported Elliptic Curves [5]
  235. 0x000b: Supported Point Formats [5]
  236. Recommended compression:
  237. 0x00
  238. Recommended server ciphersuite selection:
  239. The responder should select the first entry in this list which is
  240. listed in the client hello:
  241. 0x0039: TLS_DHE_RSA_WITH_AES_256_CBC_SHA [ Common Firefox choice ]
  242. 0x0033: TLS_DHE_RSA_WITH_AES_128_CBC_SHA [ Tor v1 default ]
  243. 0x0016: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA [ Tor v1 fallback ]
  244. 0x0013: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA [ Valid IE option ]
  245. References:
  246. [1] The Transport Layer Security (TLS) Protocol, Version 1.1, RFC4346, IETF
  247. [2] Version negotiation for the Tor protocol, Tor proposal 105
  248. [3] B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1:
  249. RSA Cryptography Specifications Version 1.5", RFC 2313,
  250. March 1998.
  251. [4] TLS Extensions, RFC 3546
  252. [5] Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)
  253. % <!-- Local IspellDict: american -->