- tor-commits - lists.torproject.org

[tor/master] Merge remote-tracking branch 'origin/maint-0.2.1' into maint-0.2.2
by nickm＠torproject.org 07 Nov '11

07 Nov '11

commit 4d8306e0e92200e1a25a073480ec342e22e590b7 Merge: 9725646 be6928d Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Nov 7 10:42:34 2011 -0500 Merge remote-tracking branch 'origin/maint-0.2.1' into maint-0.2.2 changes/bug4410 | 5 +++++ src/or/routerparse.c | 5 +++++ 2 files changed, 10 insertions(+), 0 deletions(-)

1 0

[tor/master] Merge remote-tracking branch 'origin/maint-0.2.2'
by nickm＠torproject.org 07 Nov '11

07 Nov '11

commit 51f53b590ee15c972adcff9e7d94c904a9267ac2 Merge: 350fe95 4d8306e Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Nov 7 10:44:02 2011 -0500 Merge remote-tracking branch 'origin/maint-0.2.2' changes/bug4410 | 5 +++++ src/or/routerparse.c | 5 +++++ 2 files changed, 10 insertions(+), 0 deletions(-)

1 0

[tor/master] Fix remotely triggerable assert during ip decryption
by nickm＠torproject.org 07 Nov '11

07 Nov '11

commit d5161ab895b9c14a66a08fb38521dd12c0772a97 Author: Dan Rosenberg <dan.j.rosenberg(a)gmail.com> Date: Sun Nov 6 17:23:14 2011 +0100 Fix remotely triggerable assert during ip decryption Fixes bug 4410. --- src/or/routerparse.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/src/or/routerparse.c b/src/or/routerparse.c index 19f9e38..843fc79 100644 --- a/src/or/routerparse.c +++ b/src/or/routerparse.c @@ -3858,6 +3858,11 @@ rend_decrypt_introduction_points(char **ipos_decrypted, crypto_cipher_env_t *cipher; char *dec; int declen; + if (ipos_encrypted_size < CIPHER_IV_LEN + 2) { + log_warn(LD_REND, "Size of encrypted introduction points is too " + "small."); + return -1; + } dec = tor_malloc_zero(ipos_encrypted_size - CIPHER_IV_LEN - 1); cipher = crypto_create_init_cipher(descriptor_cookie, 0); declen = crypto_cipher_decrypt_with_iv(cipher, dec,

1 0

[tor/maint-0.2.2] Fix remotely triggerable assert during ip decryption
by nickm＠torproject.org 07 Nov '11

07 Nov '11

commit d5161ab895b9c14a66a08fb38521dd12c0772a97 Author: Dan Rosenberg <dan.j.rosenberg(a)gmail.com> Date: Sun Nov 6 17:23:14 2011 +0100 Fix remotely triggerable assert during ip decryption Fixes bug 4410. --- src/or/routerparse.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/src/or/routerparse.c b/src/or/routerparse.c index 19f9e38..843fc79 100644 --- a/src/or/routerparse.c +++ b/src/or/routerparse.c @@ -3858,6 +3858,11 @@ rend_decrypt_introduction_points(char **ipos_decrypted, crypto_cipher_env_t *cipher; char *dec; int declen; + if (ipos_encrypted_size < CIPHER_IV_LEN + 2) { + log_warn(LD_REND, "Size of encrypted introduction points is too " + "small."); + return -1; + } dec = tor_malloc_zero(ipos_encrypted_size - CIPHER_IV_LEN - 1); cipher = crypto_create_init_cipher(descriptor_cookie, 0); declen = crypto_cipher_decrypt_with_iv(cipher, dec,

1 0

[tor/maint-0.2.2] Add a changes file for 4410
by nickm＠torproject.org 07 Nov '11

07 Nov '11

commit be6928d6e78a47800a96962403efff753ad70e84 Author: Sebastian Hahn <sebastian(a)torproject.org> Date: Sun Nov 6 17:24:09 2011 +0100 Add a changes file for 4410 --- changes/bug4410 | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/changes/bug4410 b/changes/bug4410 new file mode 100644 index 0000000..f42893a --- /dev/null +++ b/changes/bug4410 @@ -0,0 +1,5 @@ + o Major bugfixes: + - Correctly sanity-check that we don't underflow on a memory allocation + for introduction point decryption. Bug discovered by Dan Rosenberg. + Fixes bug 4410; bugfix on 0.2.1.5-alpha. +

1 0

[tor/maint-0.2.2] Merge remote-tracking branch 'origin/maint-0.2.1' into maint-0.2.2
by nickm＠torproject.org 07 Nov '11

07 Nov '11

commit 4d8306e0e92200e1a25a073480ec342e22e590b7 Merge: 9725646 be6928d Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Nov 7 10:42:34 2011 -0500 Merge remote-tracking branch 'origin/maint-0.2.1' into maint-0.2.2 changes/bug4410 | 5 +++++ src/or/routerparse.c | 5 +++++ 2 files changed, 10 insertions(+), 0 deletions(-)

1 0

[tor/maint-0.2.1] Fix remotely triggerable assert during ip decryption
by nickm＠torproject.org 07 Nov '11

07 Nov '11

commit d5161ab895b9c14a66a08fb38521dd12c0772a97 Author: Dan Rosenberg <dan.j.rosenberg(a)gmail.com> Date: Sun Nov 6 17:23:14 2011 +0100 Fix remotely triggerable assert during ip decryption Fixes bug 4410. --- src/or/routerparse.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/src/or/routerparse.c b/src/or/routerparse.c index 19f9e38..843fc79 100644 --- a/src/or/routerparse.c +++ b/src/or/routerparse.c @@ -3858,6 +3858,11 @@ rend_decrypt_introduction_points(char **ipos_decrypted, crypto_cipher_env_t *cipher; char *dec; int declen; + if (ipos_encrypted_size < CIPHER_IV_LEN + 2) { + log_warn(LD_REND, "Size of encrypted introduction points is too " + "small."); + return -1; + } dec = tor_malloc_zero(ipos_encrypted_size - CIPHER_IV_LEN - 1); cipher = crypto_create_init_cipher(descriptor_cookie, 0); declen = crypto_cipher_decrypt_with_iv(cipher, dec,

1 0

[tor/maint-0.2.1] Add a changes file for 4410
by nickm＠torproject.org 07 Nov '11

07 Nov '11

commit be6928d6e78a47800a96962403efff753ad70e84 Author: Sebastian Hahn <sebastian(a)torproject.org> Date: Sun Nov 6 17:24:09 2011 +0100 Add a changes file for 4410 --- changes/bug4410 | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/changes/bug4410 b/changes/bug4410 new file mode 100644 index 0000000..f42893a --- /dev/null +++ b/changes/bug4410 @@ -0,0 +1,5 @@ + o Major bugfixes: + - Correctly sanity-check that we don't underflow on a memory allocation + for introduction point decryption. Bug discovered by Dan Rosenberg. + Fixes bug 4410; bugfix on 0.2.1.5-alpha. +

1 0

[torspec/master] Add proposals/189-authorize-cell.txt.
by nickm＠torproject.org 07 Nov '11

07 Nov '11

commit 067ba228365a0262e08c0af9a8da16d5d35e1a62 Author: George Kadianakis <desnacked(a)gmail.com> Date: Fri Nov 4 18:38:51 2011 +0100 Add proposals/189-authorize-cell.txt. --- proposals/189-authorize-cell.txt | 122 ++++++++++++++++++++++++++++++++++++++ 1 files changed, 122 insertions(+), 0 deletions(-) diff --git a/proposals/189-authorize-cell.txt b/proposals/189-authorize-cell.txt new file mode 100644 index 0000000..10b45a2 --- /dev/null +++ b/proposals/189-authorize-cell.txt @@ -0,0 +1,122 @@ +Filename: 189-authorize-cell.txt +Title: AUTHORIZE and AUTHORIZED cells +Author: George Kadianakis +Created: 04 Nov 2011 +Status: Open + +1. Overview + + Proposal 187 introduced the concept of the AUTHORIZE cell, a cell + whose purpose is to make Tor bridges resistant to scanning attacks. + + This is achieved by having the bridge and the client share a secret + out-of-band and then use AUTHORIZE cells to validate that the + client indeed knows that secret before proceeding with the Tor + protocol. + + This proposal specifies the format of the AUTHORIZE cell and also + introduces the AUTHORIZED cell, a way for bridges to announce to + clients that the authorization process is complete and successful. + +2. Motivation + + AUTHORIZE cells should be able to perform a variety of + authorization protocols based on a variety of shared secrets. This + forces the AUTHORIZE cell to have a dynamic format based on the + authorization method used. + + AUTHORIZED cells are used by bridges to signal the end of a + successful bridge client authorization and the beginning of the + actual link handshake. AUTHORIZED cells have no other use and for + this reason their format is very simple. + + Both AUTHORIZE and AUTHORIZED cells are to be used under censorship + conditions and they should look innocuous to any adversary capable + of monitoring network traffic. + + As an attack example, an adversary could passively monitor the + traffic of a bridge host, looking at the packets directly after the + TLS handshake and trying to deduce from their packet size if they + are AUTHORIZE and AUTHORIZED cells. For this reason, AUTHORIZE and + AUTHORIZED cells are padded with a random amount of padding before + sending. + +3. Design + +3.1. AUTHORIZE cell + + The AUTHORIZE cell is a variable-sized cell. + + The generic AUTHORIZE cell format is: + + AuthMethod [1 octet] + MethodFields [...] + PadLen [2 octets] + Padding ['PadLen' octets] + + where: + + 'AuthMethod', is the authorization method to be used. + + 'MethodFields', is dependent on the authorization Method used. It's + a meta-field hosting an arbitrary amount of fields. + + 'PadLen', specifies the amount of padding in octets. + + 'Padding', is 'PadLen' octets of random content. + +3.2. AUTHORIZED cell format + + The AUTHORIZED cell is a variable-sized cell. + + The AUTHORIZED cell format is: + + 'AuthMethod' [1 octet] + 'PadLen' [2 octets] + 'Padding' ['PadLen' octets] + + where all fields have the same meaning as in section 3.1. + +3.3. Cell parsing + + Implementations MUST ignore the contents of 'Padding'. + + Implementations MUST reject an AUTHORIZE or AUTHORIZED cell where + the 'Padding' field is not 'PadLen' octets long. + + Implementations MUST reject an AUTHORIZE cell with an 'AuthMethod' + they don't recognize. + +4. Discussion + +4.1. Why not let the pluggable transports do the padding, like they + are supposed to do for the rest of the Tor protocol? + + The arguments of section "Alternative design: Just use pluggable + transports" of proposal 187, apply here as well: + + All bridges who use client authorization will also need camouflaged + AUTHORIZE/AUTHORIZED cell. + +4.2. How should multiple round-trip authorization protocols be handled? + + Protocols that require multiple round-trips between the client and + the bridge should use AUTHORIZE cells for communication. + + The format of the AUTHORIZE cell is flexible enough to support + messages from the client to the bridge and the inverse. + + In the end of a successful multiple round-trip protocol, an + AUTHORIZED cell must be issued from the bridge to the client. + +4.3. AUTHORIZED seems useless. Why not use VPADDING instead? + + As noted in proposal 187, the Tor protocol uses VPADDING cells for + padding; any other use of VPADDING makes the Tor protocol kludgy. + + In the future, and in the example case of a v3 handshake, a client + can optimistically send a VERSIONS cell along with the final + AUTHORIZE cell of an authorization protocol. That allows the + bridge, in the case of successful authorization, to also process + the VERSIONS cell and begin the v3 handshake promptly. +

1 0

[torspec/master] Now add proposals/190-password-bridge-authorization.txt.
by nickm＠torproject.org 07 Nov '11

07 Nov '11

commit 4aba6f4a27638cd9fed82124f70c640a054003a1 Author: George Kadianakis <desnacked(a)gmail.com> Date: Fri Nov 4 18:39:00 2011 +0100 Now add proposals/190-password-bridge-authorization.txt. --- proposals/190-password-bridge-authorization.txt | 156 +++++++++++++++++++++++ 1 files changed, 156 insertions(+), 0 deletions(-) diff --git a/proposals/190-password-bridge-authorization.txt b/proposals/190-password-bridge-authorization.txt new file mode 100644 index 0000000..36c8c35 --- /dev/null +++ b/proposals/190-password-bridge-authorization.txt @@ -0,0 +1,156 @@ +Filename: 190-password-bridge-authorization.txt +Title: Password-based Bridge Client Authorization +Author: George Kadianakis +Created: 04 Nov 2011 +Status: Open + +1. Overview + + Proposals 187 and 189 introduced the AUTHORIZE and AUTHORIZED cells. + Their purpose is to make bridge relays scanning resistant against + censoring adversaries capable of probing hosts to observe whether + they speak the Tor protocol. + + This proposal specifies a bridge client authorization scheme based + on a shared password between the bridge user and bridge operator. + +2. Motivation + + A proper bridge client authorization scheme should: + + - request information from a client that only an authorized bridge + client would know. + + - ensure that the shared secret sent by the bridge client during + the authorization can only be read and validated by the proper + bridge relay. This is important since the v3 link handshake which + authenticates the bridge to the client is carried out *after* the + bridge client authorization, which means that when the AUTHORIZE + cell is sent, the client might be actually speaking to a Man In + The Middle. + + The bridge client authorization scheme presented in this proposal + is based on a shared password and attempts to satisfy both of the + above requirements. + +3. Design + + If the AuthMethod of an AUTHORIZE cell is '0x1', the client wants + to become authorized using a shared secret based on a password. + + The short name of this authorization scheme is 'BRIDGE_AUTH_PSK'. + +3.1. Notation + + '||', denotes concatenation. + + 'HMAC(k, m)', is the Hash-based Message Authentication Code of + message 'm' using 'k' as the secret key. + + 'H(m)', is a cryptographic hash function applied on a message 'm'. + + 'HASH_LEN', is the output size of the hash function 'H'. + +3.2. Shared secret format + + A bridge client and a bridge relay willing to use this + authorization scheme, should have already exchanged out-of-band + (for example, during the bridge credentials exchange) a shared + password. + + In this case, the shared secret of this scheme becomes: + + shared_secret = H( H(bridge_identity_key) || ":" || password) + + where: + + 'bridge_identity_key', is the PKCS#1 ASN1 encoding of the bridge's + public identity key. + + '":"', is the colon character (0x3a in UTF-8). + + 'password', is the bridge password. + +3.3. Password-based authorization AUTHORIZE cell format + + In password-based authorization, the MethodFields field of the + AUTHORIZE cell becomes: + + 'HMAC(shared_secret, tls_cert)' [HASH_LEN octets] + + where: + + 'HMAC(shared_secret, tls_cert), is the HMAC construction of the TLS + certificate of the bridge relay, using the shared secret of section + 3.2 as the secret key. + +3.4. Password-based authorization notes + + Bridge implementations MUST reject clients who provide malformed + AUTHORIZE cells or HMAC values that do not verify the appropriate + TLS certificate. + + Bridge implementations SHOULD provide an easy way to create and + change the bridge shared secret. + +3.5. Security arguments + + An adversary who does not know the 'shared_secret' of a bridge + cannot construct an HMAC that verifies its TLS certificate when + used with the correct 'shared_secret'. + + An adversary who attempts to MITM the TLS connection of a bridge + user to steal the 'shared_secret' will instead steal an HMAC value + created by the 'tls_cert' of the TLS certificate that the attacker + used to MITM the TLS connection. Replaying that 'shared_secret' + value to the actual bridge will fail to verify the correct + 'tls_cert'. + + The two above paragraphs resolve the requirements of the + 'Motivation' section. + + Furthermore, an adversary who compromises a bridge, steals the + shared secret and attempts to replay it to other bridges of the + same bridge operator will fail since each shared secret has a + digest of the bridge's identity key baked in it. + + The bridge's identity key digest also serves as a salt to counter + rainbow table precomputation attacks. + +4. Tor implementation + + The Tor implementation of the above scheme uses SHA256 as the hash + function 'H'. + + SHA256 also makes HASH_LEN equal to 32. + +5. Discussion + +5.1. Do we need more authorization schemes? + + Probably yes. + + The centuries-old problem with passwords is that humans can't get + their passwords right. + + To avoid problems associated with the human condition, schemes + based on public key cryptography and certificates can be used. A + public and well tested protocol that can be used as the basis of a + future authorization scheme is the SSH "publickey" authorization + protocol. + +5.2. What should actually happen when a bridge rejects an AUTHORIZE + cell? + + When a bridge detects a badly formed or malicious AUTHORIZE cell, + it should assume that the other side is an adversary scanning for + bridges. The bridge should then act accordingly to avoid detection. + + This proposal does not try to specify how a bridge can avoid + detection by an adversary. + +6. Acknowledgements + + Without Nick Mathewson and Robert Ransom this proposal would + actually be specifying a useless and broken authentication scheme. + Thanks!

1 0