tor-commits March 2011

tor-commits@lists.torproject.org

18 participants
683 discussions

[torspec/master] rename xxx-draft-spec-for-TLS-normalization.txt to xxx-TLS-cert-and-parameter-normalization.txt
by ioerror＠torproject.org 03 Mar '11

03 Mar '11

commit 46f7a8f427a3b36e902b59c789c21c48c7dca70e Author: Jacob Appelbaum <jacob(a)appelbaum.net> Date: Wed Mar 2 15:37:35 2011 -0800 rename xxx-draft-spec-for-TLS-normalization.txt to xxx-TLS-cert-and-parameter-normalization.txt --- .../xxx-TLS-cert-and-parameter-normalization.txt | 360 ++++++++++++++++++++ .../ideas/xxx-draft-spec-for-TLS-normalization.txt | 360 -------------------- 2 files changed, 360 insertions(+), 360 deletions(-) diff --git a/proposals/ideas/xxx-TLS-cert-and-parameter-normalization.txt b/proposals/ideas/xxx-TLS-cert-and-parameter-normalization.txt new file mode 100644 index 0000000..74704b1 --- /dev/null +++ b/proposals/ideas/xxx-TLS-cert-and-parameter-normalization.txt @@ -0,0 +1,360 @@ +Filename: xxx-TLS-cert-and-parameter-normalization.txt +Title: TLS certificate and parameter normalization +Author: Jacob Appelbaum, Gladys Shufflebottom +Created: 16-Feb-2011 +Status: Draft + + + Draft spec for TLS certificate and handshake normalization + + + Overview + +Scope + +This is a document that proposes improvements to problems with Tor's +current TLS (Transport Layer Security) certificates and handshake that will +reduce the distinguishability of Tor traffic from other encrypted traffic that +uses TLS. It also addresses some of the possible fingerprinting attacks +possible against the current Tor TLS protocol setup process. + +Motivation and history + +Censorship is an arms race and this is a step forward in the defense +of Tor. This proposal outlines ideas to make it more difficult to +fingerprint and block Tor traffic. + +Goals + +This proposal intends to normalize or remove easy-to-predict or static +values in the Tor TLS certificates and with the Tor TLS setup process. +These values can be used as criteria for the automated classification of +encrypted traffic as Tor traffic. Network observers should not be able +to trivially detect Tor merely by receiving or observing the certificate +used or advertised by a Tor relay. I also propose the creation of +a hard-to-detect covert channel through which a server can signal that it +supports the third version ("V3") of the Tor handshake protocol. + +Non-Goals + +This document is not intended to solve all of the possible active or passive +Tor fingerprinting problems. This document focuses on removing distinctive +and predictable features of TLS protocol negotiation; we do not attempt to +make guarantees about resisting other kinds of fingerprinting of Tor +traffic, such as fingerprinting techniques related to timing or volume of +transmitted data. + + Implementation details + + +Certificate Issues + +The CN or commonName ASN1 field + +Tor generates certificates with a predictable commonName field; the +field is within a given range of values that is specific to Tor. +Additionally, the generated host names have other undesirable properties. +The host names typically do not resolve in the DNS because the domain +names referred to are generated at random. Although they are syntatically +valid, they usually refer to domains that have never been registered by +any domain name registrar. + +An example of the current commonName field: CN=www.s4ku5skci.net + +An example of OpenSSL’s asn1parse over a typical Tor certificate: + + 0:d=0 hl=4 l= 438 cons: SEQUENCE + 4:d=1 hl=4 l= 287 cons: SEQUENCE + 8:d=2 hl=2 l= 3 cons: cont [ 0 ] + 10:d=3 hl=2 l= 1 prim: INTEGER :02 + 13:d=2 hl=2 l= 4 prim: INTEGER :4D3C763A + 19:d=2 hl=2 l= 13 cons: SEQUENCE + 21:d=3 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption + 32:d=3 hl=2 l= 0 prim: NULL + 34:d=2 hl=2 l= 35 cons: SEQUENCE + 36:d=3 hl=2 l= 33 cons: SET + 38:d=4 hl=2 l= 31 cons: SEQUENCE + 40:d=5 hl=2 l= 3 prim: OBJECT :commonName + 45:d=5 hl=2 l= 24 prim: PRINTABLESTRING :www.vsbsvwu5b4soh4wg.net + 71:d=2 hl=2 l= 30 cons: SEQUENCE + 73:d=3 hl=2 l= 13 prim: UTCTIME :110123184058Z + 88:d=3 hl=2 l= 13 prim: UTCTIME :110123204058Z + 103:d=2 hl=2 l= 28 cons: SEQUENCE + 105:d=3 hl=2 l= 26 cons: SET + 107:d=4 hl=2 l= 24 cons: SEQUENCE + 109:d=5 hl=2 l= 3 prim: OBJECT :commonName + 114:d=5 hl=2 l= 17 prim: PRINTABLESTRING :www.s4ku5skci.net + 133:d=2 hl=3 l= 159 cons: SEQUENCE + 136:d=3 hl=2 l= 13 cons: SEQUENCE + 138:d=4 hl=2 l= 9 prim: OBJECT :rsaEncryption + 149:d=4 hl=2 l= 0 prim: NULL + 151:d=3 hl=3 l= 141 prim: BIT STRING + 295:d=1 hl=2 l= 13 cons: SEQUENCE + 297:d=2 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption + 308:d=2 hl=2 l= 0 prim: NULL + 310:d=1 hl=3 l= 129 prim: BIT STRING + +I propose that we match OpenSSL's default self-signed certificates. I hypothesise +that they are the most common self-signed certificates. If this turns out not +to be the case, then we should use whatever the most common turns out to be. + +Certificate serial numbers + +Currently our generated certificate serial number is set to the number of +seconds since the epoch at the time of the certificate's creation. I propose +that we should ensure that our serial numbers are unrelated to the epoch, +since the generation methods are potentially recognizable as Tor-related. + +Instead, I propose that we use a randomly generated number that is +subsequently hashed with SHA-512 and then truncate the data to eight bytes[1]. + +Random sixteen byte values appear to be the high bound for serial number as +issued by Verisign and DigiCert. RapidSSL appears to be three bytes in length. +Others common byte lengths appear to be between one and four bytes. The default +OpenSSL certificates are eight bytes and we should use this length with our +self-signed certificates. + +This randomly generated serial number field may now serve as a covert channel +that signals to the client that the OR will not support TLS renegotiation; this +means that the client can expect to perform a V3 TLS handshake setup. +Otherwise, if the serial number is a reasonable time since the epoch, we should +assume the OR is using an earlier protocol version and hence that it expects +renegotiation. + +We also have a need to signal properties with our certificates for a possible +v3 handshake in the future. Therefore I propose that we match OpenSSL default +self-signed certificates (a 64-bit random number), but reserve the two least- +significant bits for signaling. For the moment, these two bits will be zero. + +This means that an attacker may be able to identify Tor certificates from default +OpenSSL certificates with a 75% probability. + +As a security note, care must be taken to ensure that supporting this +covert channel will not lead to an attacker having a method to downgrade client +behavior. This shouldn't be a risk because the TLS Finished message hashes over +all the bytes of the handshake, including the certificates. + +Certificate fingerprinting issues expressed as base64 encoding + +It appears that all deployed Tor certificates have the following strings in +common: + +MIIB +CCA +gAwIBAgIETU +ANBgkqhkiG9w0BAQUFADA +YDVQQDEx +3d3cu + +As expected these values correspond to specific ASN.1 OBJECT IDENTIFIER (OID) +properties (sha1WithRSAEncryption, commonName, etc) of how we generate our +certificates. + +As an illustrated example of the common bytes of all certificates used within +the Tor network within a single one hour window, I have replaced the actual +value with a wild card ('.') character here: + +-----BEGIN CERTIFICATE----- +MIIB..CCA..gAwIBAgIETU....ANBgkqhkiG9w0BAQUFADA.M..w..YDVQQDEx.3 +d3cu............................................................ +................................................................ +................................................................ +................................................................ +................................................................ +................................................................ +................................................................ +................................................................ +........................... <--- Variable length and padding +-----END CERTIFICATE----- + +This fine ascii art only illustrates the bytes that absolutely match in all +cases. In many cases, it's likely that there is a high probability for a given +byte to be only a small subset of choices. + +Using the above strings, the EFF's certificate observatory may trivially +discover all known relays, known bridges and unknown bridges in a single SQL +query. I propose that we ensure that we test our certificates to ensure that +they do not have these kinds of statistical similarities without ensuring +overlap with a very large cross section of the internet's certificates. + +Certificate dating and validity issues + +TLS certificates found in the wild are generally found to be long-lived; +they are frequently old and often even expired. The current Tor certificate +validity time is a very small time window starting at generation time and +ending shortly thereafter, as defined in or.h by MAX_SSL_KEY_LIFETIME +(2*60*60). + +I propose that the certificate validity time length is extended to a period of +twelve Earth months, possibly with a small random skew to be determined by the +implementer. Tor should randomly set the start date in the past or some +currently unspecified window of time before the current date. This would +more closely track the typical distribution of non-Tor TLS certificate +expiration times. + +The certificate values, such as expiration, should not be used for anything +relating to security; for example, if the OR presents an expired TLS +certificate, this does not imply that the client should terminate the +connection (as would be appropriate for an ordinary TLS implementation). +Rather, I propose we use a TOFU style expiration policy - the certificate +should never be trusted for more than a two hour window from first sighting. + +This policy should have two major impacts. The first is that an adversary will +have to perform a differential analysis of all certificates for a given IP +address rather than a single check. The second is that the server expiration +time is enforced by the client and confirmed by keys rotating in the consensus. + +The expiration time should not be a fixed time that is simple to calculate by +any Deep Packet Inspection device or it will become a new Tor TLS setup +fingerprint. + +Proposed certificate form + +The following output from openssl asn1parse results from the proposed +certificate generation algorithm. It matches the results of generating a +default self-signed certificate: + + 0:d=0 hl=4 l= 513 cons: SEQUENCE + 4:d=1 hl=4 l= 362 cons: SEQUENCE + 8:d=2 hl=2 l= 9 prim: INTEGER :DBF6B3B864FF7478 + 19:d=2 hl=2 l= 13 cons: SEQUENCE + 21:d=3 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption + 32:d=3 hl=2 l= 0 prim: NULL + 34:d=2 hl=2 l= 69 cons: SEQUENCE + 36:d=3 hl=2 l= 11 cons: SET + 38:d=4 hl=2 l= 9 cons: SEQUENCE + 40:d=5 hl=2 l= 3 prim: OBJECT :countryName + 45:d=5 hl=2 l= 2 prim: PRINTABLESTRING :AU + 49:d=3 hl=2 l= 19 cons: SET + 51:d=4 hl=2 l= 17 cons: SEQUENCE + 53:d=5 hl=2 l= 3 prim: OBJECT :stateOrProvinceName + 58:d=5 hl=2 l= 10 prim: PRINTABLESTRING :Some-State + 70:d=3 hl=2 l= 33 cons: SET + 72:d=4 hl=2 l= 31 cons: SEQUENCE + 74:d=5 hl=2 l= 3 prim: OBJECT :organizationName + 79:d=5 hl=2 l= 24 prim: PRINTABLESTRING :Internet Widgits Pty Ltd + 105:d=2 hl=2 l= 30 cons: SEQUENCE + 107:d=3 hl=2 l= 13 prim: UTCTIME :110217011237Z + 122:d=3 hl=2 l= 13 prim: UTCTIME :120217011237Z + 137:d=2 hl=2 l= 69 cons: SEQUENCE + 139:d=3 hl=2 l= 11 cons: SET + 141:d=4 hl=2 l= 9 cons: SEQUENCE + 143:d=5 hl=2 l= 3 prim: OBJECT :countryName + 148:d=5 hl=2 l= 2 prim: PRINTABLESTRING :AU + 152:d=3 hl=2 l= 19 cons: SET + 154:d=4 hl=2 l= 17 cons: SEQUENCE + 156:d=5 hl=2 l= 3 prim: OBJECT :stateOrProvinceName + 161:d=5 hl=2 l= 10 prim: PRINTABLESTRING :Some-State + 173:d=3 hl=2 l= 33 cons: SET + 175:d=4 hl=2 l= 31 cons: SEQUENCE + 177:d=5 hl=2 l= 3 prim: OBJECT :organizationName + 182:d=5 hl=2 l= 24 prim: PRINTABLESTRING :Internet Widgits Pty Ltd + 208:d=2 hl=3 l= 159 cons: SEQUENCE + 211:d=3 hl=2 l= 13 cons: SEQUENCE + 213:d=4 hl=2 l= 9 prim: OBJECT :rsaEncryption + 224:d=4 hl=2 l= 0 prim: NULL + 226:d=3 hl=3 l= 141 prim: BIT STRING + 370:d=1 hl=2 l= 13 cons: SEQUENCE + 372:d=2 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption + 383:d=2 hl=2 l= 0 prim: NULL + 385:d=1 hl=3 l= 129 prim: BIT STRING + + +Custom Certificates + +It should be possible for a Tor relay operator to use a specifically supplied +certificate and secret key. This will allow a relay or bridge operator to use a +certificate signed by any member of any geographically relevant certificate +authority racket; it will also allow for any other user-supplied certificate. +This may be desirable in some kinds of filtered networks or when attempting to +avoid attracting suspicion by blending in with the TLS web server certificate +crowd. + +Problematic Diffie–Hellman parameters + +We currently send a static Diffie–Hellman parameter, prime p (or “prime p +outlaw”) as specified in RFC2409 as part of the TLS Server Hello response. + +The use of this prime in TLS negotiations may, as a result, be filtered and +effectively banned by certain networks. We do not have to use this particular +prime in all cases. + +While amusing to have the power to make specific prime numbers into a new class +of numbers (cf. imaginary, irrational, illegal [3]) - our new friend prime p +outlaw is not required. + +The use of this prime in TLS negotiations may, as a result, be filtered and +effectively banned by certain networks. We do not have to use this particular +prime in all cases. + +I propose that the function to initialize and generate DH parameters be +split into two functions. + +First, init_dh_param() should be used only for OR-to-OR DH setup and +communication. Second, it is proposed that we create a new function +init_tls_dh_param() that will have a two-stage development process. + +The first stage init_tls_dh_param() will use the same prime that +Apache2.x [4] sends (or “dh1024_apache_p”), and this change should be +made immediately. This is a known good and safe prime number (p-1 / 2 +is also prime) that is currently not known to be blocked. + +The second stage init_tls_dh_param() should randomly generate a new prime on a +regular basis; this is designed to make the prime difficult to outlaw or +filter. Call this a shape-shifting or "Rakshasa" prime. This should be added +to the 0.2.3.x branch of Tor. This prime can be generated at setup or execution +time and probably does not need to be stored on disk. Rakshasa primes only +need to be generated by Tor relays as Tor clients will never send them. Such +a prime should absolutely not be shared between different Tor relays nor +should it ever be static after the 0.2.3.x release. + +As a security precaution, care must be taken to ensure that we do not generate +weak primes or known filtered primes. Both weak and filtered primes will +undermine the TLS connection security properties. OpenSSH solves this issue +dynamically in RFC 4419 [5] and may provide a solution that works reasonably +well for Tor. More research in this area including the applicability of +Miller-Rabin or AKS primality tests[6] will need to be analyzed and probably +added to Tor. + +Practical key size + +Currently we use a 1024 bit long RSA modulus. I propose that we increase the +RSA key size to 2048 as an additional channel to signal support for the V3 +handshake setup. 2048 appears to be the most common key size[0] above 1024. +Additionally, the increase in modulus size provides a reasonable security boost +with regard to key security properties. + +The implementer should increase the 1024 bit RSA modulus to 2048 bits. + +Possible future filtering nightmares + +At some point it may cost effective or politically feasible for a network +filter to simply block all signed or self-signed certificates without a known +valid CA trust chain. This will break many applications on the internet and +hopefully, our option for custom certificates will ensure that this step is +simply avoided by the censors. + +The Rakshasa prime approach may cause censors to specifically allow only +certain known and accepted DH parameters. + + +Appendix: Other issues + +What other obvious TLS certificate issues exist? What other static values are +present in the Tor TLS setup process? + +[0] http://archives.seul.org/or/dev/Jan-2011/msg00051.html +[1] http://archives.seul.org/or/dev/Feb-2011/msg00016.html +[2] http://archives.seul.org/or/dev/Feb-2011/msg00039.html +[3] To be fair this is hardly a new class of numbers. History is rife with + similar examples of inane authoritarian attempts at mathematical secrecy. + Probably the most dramatic example is the story of the pupil Hipassus of + Metapontum, pupil of the famous Pythagoras, who, legend goes, proved the + fact that Root2 cannot be expressed as a fraction of whole numbers (now + called an irrational number) and was assassinated for revealing this + secret. Further reading on the subject may be found on the Wikipedia: + http://en.wikipedia.org/wiki/Hippasus + +[4] httpd-2.2.17/modules/ss/ssl_engine_dh.c +[5] http://tools.ietf.org/html/rfc4419 +[6] http://archives.seul.org/or/dev/Jan-2011/msg00037.html diff --git a/proposals/ideas/xxx-draft-spec-for-TLS-normalization.txt b/proposals/ideas/xxx-draft-spec-for-TLS-normalization.txt deleted file mode 100644 index 16484e6..0000000 --- a/proposals/ideas/xxx-draft-spec-for-TLS-normalization.txt +++ /dev/null @@ -1,360 +0,0 @@ -Filename: xxx-draft-spec-for-TLS-normalization.txt -Title: Draft spec for TLS certificate and handshake normalization -Author: Jacob Appelbaum, Gladys Shufflebottom -Created: 16-Feb-2011 -Status: Draft - - - Draft spec for TLS certificate and handshake normalization - - - Overview - -Scope - -This is a document that proposes improvements to problems with Tor's -current TLS (Transport Layer Security) certificates and handshake that will -reduce the distinguishability of Tor traffic from other encrypted traffic that -uses TLS. It also addresses some of the possible fingerprinting attacks -possible against the current Tor TLS protocol setup process. - -Motivation and history - -Censorship is an arms race and this is a step forward in the defense -of Tor. This proposal outlines ideas to make it more difficult to -fingerprint and block Tor traffic. - -Goals - -This proposal intends to normalize or remove easy-to-predict or static -values in the Tor TLS certificates and with the Tor TLS setup process. -These values can be used as criteria for the automated classification of -encrypted traffic as Tor traffic. Network observers should not be able -to trivially detect Tor merely by receiving or observing the certificate -used or advertised by a Tor relay. I also propose the creation of -a hard-to-detect covert channel through which a server can signal that it -supports the third version ("V3") of the Tor handshake protocol. - -Non-Goals - -This document is not intended to solve all of the possible active or passive -Tor fingerprinting problems. This document focuses on removing distinctive -and predictable features of TLS protocol negotiation; we do not attempt to -make guarantees about resisting other kinds of fingerprinting of Tor -traffic, such as fingerprinting techniques related to timing or volume of -transmitted data. - - Implementation details - - -Certificate Issues - -The CN or commonName ASN1 field - -Tor generates certificates with a predictable commonName field; the -field is within a given range of values that is specific to Tor. -Additionally, the generated host names have other undesirable properties. -The host names typically do not resolve in the DNS because the domain -names referred to are generated at random. Although they are syntatically -valid, they usually refer to domains that have never been registered by -any domain name registrar. - -An example of the current commonName field: CN=www.s4ku5skci.net - -An example of OpenSSL’s asn1parse over a typical Tor certificate: - - 0:d=0 hl=4 l= 438 cons: SEQUENCE - 4:d=1 hl=4 l= 287 cons: SEQUENCE - 8:d=2 hl=2 l= 3 cons: cont [ 0 ] - 10:d=3 hl=2 l= 1 prim: INTEGER :02 - 13:d=2 hl=2 l= 4 prim: INTEGER :4D3C763A - 19:d=2 hl=2 l= 13 cons: SEQUENCE - 21:d=3 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption - 32:d=3 hl=2 l= 0 prim: NULL - 34:d=2 hl=2 l= 35 cons: SEQUENCE - 36:d=3 hl=2 l= 33 cons: SET - 38:d=4 hl=2 l= 31 cons: SEQUENCE - 40:d=5 hl=2 l= 3 prim: OBJECT :commonName - 45:d=5 hl=2 l= 24 prim: PRINTABLESTRING :www.vsbsvwu5b4soh4wg.net - 71:d=2 hl=2 l= 30 cons: SEQUENCE - 73:d=3 hl=2 l= 13 prim: UTCTIME :110123184058Z - 88:d=3 hl=2 l= 13 prim: UTCTIME :110123204058Z - 103:d=2 hl=2 l= 28 cons: SEQUENCE - 105:d=3 hl=2 l= 26 cons: SET - 107:d=4 hl=2 l= 24 cons: SEQUENCE - 109:d=5 hl=2 l= 3 prim: OBJECT :commonName - 114:d=5 hl=2 l= 17 prim: PRINTABLESTRING :www.s4ku5skci.net - 133:d=2 hl=3 l= 159 cons: SEQUENCE - 136:d=3 hl=2 l= 13 cons: SEQUENCE - 138:d=4 hl=2 l= 9 prim: OBJECT :rsaEncryption - 149:d=4 hl=2 l= 0 prim: NULL - 151:d=3 hl=3 l= 141 prim: BIT STRING - 295:d=1 hl=2 l= 13 cons: SEQUENCE - 297:d=2 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption - 308:d=2 hl=2 l= 0 prim: NULL - 310:d=1 hl=3 l= 129 prim: BIT STRING - -I propose that we match OpenSSL's default self-signed certificates. I hypothesise -that they are the most common self-signed certificates. If this turns out not -to be the case, then we should use whatever the most common turns out to be. - -Certificate serial numbers - -Currently our generated certificate serial number is set to the number of -seconds since the epoch at the time of the certificate's creation. I propose -that we should ensure that our serial numbers are unrelated to the epoch, -since the generation methods are potentially recognizable as Tor-related. - -Instead, I propose that we use a randomly generated number that is -subsequently hashed with SHA-512 and then truncate the data to eight bytes[1]. - -Random sixteen byte values appear to be the high bound for serial number as -issued by Verisign and DigiCert. RapidSSL appears to be three bytes in length. -Others common byte lengths appear to be between one and four bytes. The default -OpenSSL certificates are eight bytes and we should use this length with our -self-signed certificates. - -This randomly generated serial number field may now serve as a covert channel -that signals to the client that the OR will not support TLS renegotiation; this -means that the client can expect to perform a V3 TLS handshake setup. -Otherwise, if the serial number is a reasonable time since the epoch, we should -assume the OR is using an earlier protocol version and hence that it expects -renegotiation. - -We also have a need to signal properties with our certificates for a possible -v3 handshake in the future. Therefore I propose that we match OpenSSL default -self-signed certificates (a 64-bit random number), but reserve the two least- -significant bits for signaling. For the moment, these two bits will be zero. - -This means that an attacker may be able to identify Tor certificates from default -OpenSSL certificates with a 75% probability. - -As a security note, care must be taken to ensure that supporting this -covert channel will not lead to an attacker having a method to downgrade client -behavior. This shouldn't be a risk because the TLS Finished message hashes over -all the bytes of the handshake, including the certificates. - -Certificate fingerprinting issues expressed as base64 encoding - -It appears that all deployed Tor certificates have the following strings in -common: - -MIIB -CCA -gAwIBAgIETU -ANBgkqhkiG9w0BAQUFADA -YDVQQDEx -3d3cu - -As expected these values correspond to specific ASN.1 OBJECT IDENTIFIER (OID) -properties (sha1WithRSAEncryption, commonName, etc) of how we generate our -certificates. - -As an illustrated example of the common bytes of all certificates used within -the Tor network within a single one hour window, I have replaced the actual -value with a wild card ('.') character here: - ------BEGIN CERTIFICATE----- -MIIB..CCA..gAwIBAgIETU....ANBgkqhkiG9w0BAQUFADA.M..w..YDVQQDEx.3 -d3cu............................................................ -................................................................ -................................................................ -................................................................ -................................................................ -................................................................ -................................................................ -................................................................ -........................... <--- Variable length and padding ------END CERTIFICATE----- - -This fine ascii art only illustrates the bytes that absolutely match in all -cases. In many cases, it's likely that there is a high probability for a given -byte to be only a small subset of choices. - -Using the above strings, the EFF's certificate observatory may trivially -discover all known relays, known bridges and unknown bridges in a single SQL -query. I propose that we ensure that we test our certificates to ensure that -they do not have these kinds of statistical similarities without ensuring -overlap with a very large cross section of the internet's certificates. - -Certificate dating and validity issues - -TLS certificates found in the wild are generally found to be long-lived; -they are frequently old and often even expired. The current Tor certificate -validity time is a very small time window starting at generation time and -ending shortly thereafter, as defined in or.h by MAX_SSL_KEY_LIFETIME -(2*60*60). - -I propose that the certificate validity time length is extended to a period of -twelve Earth months, possibly with a small random skew to be determined by the -implementer. Tor should randomly set the start date in the past or some -currently unspecified window of time before the current date. This would -more closely track the typical distribution of non-Tor TLS certificate -expiration times. - -The certificate values, such as expiration, should not be used for anything -relating to security; for example, if the OR presents an expired TLS -certificate, this does not imply that the client should terminate the -connection (as would be appropriate for an ordinary TLS implementation). -Rather, I propose we use a TOFU style expiration policy - the certificate -should never be trusted for more than a two hour window from first sighting. - -This policy should have two major impacts. The first is that an adversary will -have to perform a differential analysis of all certificates for a given IP -address rather than a single check. The second is that the server expiration -time is enforced by the client and confirmed by keys rotating in the consensus. - -The expiration time should not be a fixed time that is simple to calculate by -any Deep Packet Inspection device or it will become a new Tor TLS setup -fingerprint. - -Proposed certificate form - -The following output from openssl asn1parse results from the proposed -certificate generation algorithm. It matches the results of generating a -default self-signed certificate: - - 0:d=0 hl=4 l= 513 cons: SEQUENCE - 4:d=1 hl=4 l= 362 cons: SEQUENCE - 8:d=2 hl=2 l= 9 prim: INTEGER :DBF6B3B864FF7478 - 19:d=2 hl=2 l= 13 cons: SEQUENCE - 21:d=3 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption - 32:d=3 hl=2 l= 0 prim: NULL - 34:d=2 hl=2 l= 69 cons: SEQUENCE - 36:d=3 hl=2 l= 11 cons: SET - 38:d=4 hl=2 l= 9 cons: SEQUENCE - 40:d=5 hl=2 l= 3 prim: OBJECT :countryName - 45:d=5 hl=2 l= 2 prim: PRINTABLESTRING :AU - 49:d=3 hl=2 l= 19 cons: SET - 51:d=4 hl=2 l= 17 cons: SEQUENCE - 53:d=5 hl=2 l= 3 prim: OBJECT :stateOrProvinceName - 58:d=5 hl=2 l= 10 prim: PRINTABLESTRING :Some-State - 70:d=3 hl=2 l= 33 cons: SET - 72:d=4 hl=2 l= 31 cons: SEQUENCE - 74:d=5 hl=2 l= 3 prim: OBJECT :organizationName - 79:d=5 hl=2 l= 24 prim: PRINTABLESTRING :Internet Widgits Pty Ltd - 105:d=2 hl=2 l= 30 cons: SEQUENCE - 107:d=3 hl=2 l= 13 prim: UTCTIME :110217011237Z - 122:d=3 hl=2 l= 13 prim: UTCTIME :120217011237Z - 137:d=2 hl=2 l= 69 cons: SEQUENCE - 139:d=3 hl=2 l= 11 cons: SET - 141:d=4 hl=2 l= 9 cons: SEQUENCE - 143:d=5 hl=2 l= 3 prim: OBJECT :countryName - 148:d=5 hl=2 l= 2 prim: PRINTABLESTRING :AU - 152:d=3 hl=2 l= 19 cons: SET - 154:d=4 hl=2 l= 17 cons: SEQUENCE - 156:d=5 hl=2 l= 3 prim: OBJECT :stateOrProvinceName - 161:d=5 hl=2 l= 10 prim: PRINTABLESTRING :Some-State - 173:d=3 hl=2 l= 33 cons: SET - 175:d=4 hl=2 l= 31 cons: SEQUENCE - 177:d=5 hl=2 l= 3 prim: OBJECT :organizationName - 182:d=5 hl=2 l= 24 prim: PRINTABLESTRING :Internet Widgits Pty Ltd - 208:d=2 hl=3 l= 159 cons: SEQUENCE - 211:d=3 hl=2 l= 13 cons: SEQUENCE - 213:d=4 hl=2 l= 9 prim: OBJECT :rsaEncryption - 224:d=4 hl=2 l= 0 prim: NULL - 226:d=3 hl=3 l= 141 prim: BIT STRING - 370:d=1 hl=2 l= 13 cons: SEQUENCE - 372:d=2 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption - 383:d=2 hl=2 l= 0 prim: NULL - 385:d=1 hl=3 l= 129 prim: BIT STRING - - -Custom Certificates - -It should be possible for a Tor relay operator to use a specifically supplied -certificate and secret key. This will allow a relay or bridge operator to use a -certificate signed by any member of any geographically relevant certificate -authority racket; it will also allow for any other user-supplied certificate. -This may be desirable in some kinds of filtered networks or when attempting to -avoid attracting suspicion by blending in with the TLS web server certificate -crowd. - -Problematic Diffie–Hellman parameters - -We currently send a static Diffie–Hellman parameter, prime p (or “prime p -outlaw”) as specified in RFC2409 as part of the TLS Server Hello response. - -The use of this prime in TLS negotiations may, as a result, be filtered and -effectively banned by certain networks. We do not have to use this particular -prime in all cases. - -While amusing to have the power to make specific prime numbers into a new class -of numbers (cf. imaginary, irrational, illegal [3]) - our new friend prime p -outlaw is not required. - -The use of this prime in TLS negotiations may, as a result, be filtered and -effectively banned by certain networks. We do not have to use this particular -prime in all cases. - -I propose that the function to initialize and generate DH parameters be -split into two functions. - -First, init_dh_param() should be used only for OR-to-OR DH setup and -communication. Second, it is proposed that we create a new function -init_tls_dh_param() that will have a two-stage development process. - -The first stage init_tls_dh_param() will use the same prime that -Apache2.x [4] sends (or “dh1024_apache_p”), and this change should be -made immediately. This is a known good and safe prime number (p-1 / 2 -is also prime) that is currently not known to be blocked. - -The second stage init_tls_dh_param() should randomly generate a new prime on a -regular basis; this is designed to make the prime difficult to outlaw or -filter. Call this a shape-shifting or "Rakshasa" prime. This should be added -to the 0.2.3.x branch of Tor. This prime can be generated at setup or execution -time and probably does not need to be stored on disk. Rakshasa primes only -need to be generated by Tor relays as Tor clients will never send them. Such -a prime should absolutely not be shared between different Tor relays nor -should it ever be static after the 0.2.3.x release. - -As a security precaution, care must be taken to ensure that we do not generate -weak primes or known filtered primes. Both weak and filtered primes will -undermine the TLS connection security properties. OpenSSH solves this issue -dynamically in RFC 4419 [5] and may provide a solution that works reasonably -well for Tor. More research in this area including the applicability of -Miller-Rabin or AKS primality tests[6] will need to be analyzed and probably -added to Tor. - -Practical key size - -Currently we use a 1024 bit long RSA modulus. I propose that we increase the -RSA key size to 2048 as an additional channel to signal support for the V3 -handshake setup. 2048 appears to be the most common key size[0] above 1024. -Additionally, the increase in modulus size provides a reasonable security boost -with regard to key security properties. - -The implementer should increase the 1024 bit RSA modulus to 2048 bits. - -Possible future filtering nightmares - -At some point it may cost effective or politically feasible for a network -filter to simply block all signed or self-signed certificates without a known -valid CA trust chain. This will break many applications on the internet and -hopefully, our option for custom certificates will ensure that this step is -simply avoided by the censors. - -The Rakshasa prime approach may cause censors to specifically allow only -certain known and accepted DH parameters. - - -Appendix: Other issues - -What other obvious TLS certificate issues exist? What other static values are -present in the Tor TLS setup process? - -[0] http://archives.seul.org/or/dev/Jan-2011/msg00051.html -[1] http://archives.seul.org/or/dev/Feb-2011/msg00016.html -[2] http://archives.seul.org/or/dev/Feb-2011/msg00039.html -[3] To be fair this is hardly a new class of numbers. History is rife with - similar examples of inane authoritarian attempts at mathematical secrecy. - Probably the most dramatic example is the story of the pupil Hipassus of - Metapontum, pupil of the famous Pythagoras, who, legend goes, proved the - fact that Root2 cannot be expressed as a fraction of whole numbers (now - called an irrational number) and was assassinated for revealing this - secret. Further reading on the subject may be found on the Wikipedia: - http://en.wikipedia.org/wiki/Hippasus - -[4] httpd-2.2.17/modules/ss/ssl_engine_dh.c -[5] http://tools.ietf.org/html/rfc4419 -[6] http://archives.seul.org/or/dev/Jan-2011/msg00037.html

1 0

[torspec/master] TLS certificate and parameter normalization [DRAFT] as prop 179
by ioerror＠torproject.org 03 Mar '11

03 Mar '11

commit 3a85a3afac30dc8a2433a6e06508ac57c964f820 Author: Jacob Appelbaum <jacob(a)appelbaum.net> Date: Wed Mar 2 16:00:42 2011 -0800 TLS certificate and parameter normalization [DRAFT] as prop 179 --- proposals/000-index.txt | 2 + .../179-TLS-cert-and-parameter-normalization.txt | 360 ++++++++++++++++++++ .../xxx-TLS-cert-and-parameter-normalization.txt | 360 -------------------- 3 files changed, 362 insertions(+), 360 deletions(-) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index b642703..be9b4e2 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -99,6 +99,7 @@ Proposals by number: 176 Proposed version-3 link handshake for Tor [OPEN] 177 Abstaining from votes on individual flags [OPEN] 178 Require majority of authorities to vote for consensus parameters [OPEN] +179 TLS certificate and parameter normalization [DRAFT] Proposals by status: @@ -112,6 +113,7 @@ Proposals by status: 149 Using data from NETINFO cells [for 0.2.1.x] 170 Configuration options regarding circuit building 175 Automatically promoting Tor clients to nodes + 179 TLS certificate and parameter normalization NEEDS-REVISION: 131 Help users to verify they are using Tor OPEN: diff --git a/proposals/179-TLS-cert-and-parameter-normalization.txt b/proposals/179-TLS-cert-and-parameter-normalization.txt new file mode 100644 index 0000000..acad79a --- /dev/null +++ b/proposals/179-TLS-cert-and-parameter-normalization.txt @@ -0,0 +1,360 @@ +Filename: 179-TLS-cert-and-parameter-normalization.txt +Title: TLS certificate and parameter normalization +Author: Jacob Appelbaum, Gladys Shufflebottom +Created: 16-Feb-2011 +Status: Draft + + + Draft spec for TLS certificate and handshake normalization + + + Overview + +Scope + +This is a document that proposes improvements to problems with Tor's +current TLS (Transport Layer Security) certificates and handshake that will +reduce the distinguishability of Tor traffic from other encrypted traffic that +uses TLS. It also addresses some of the possible fingerprinting attacks +possible against the current Tor TLS protocol setup process. + +Motivation and history + +Censorship is an arms race and this is a step forward in the defense +of Tor. This proposal outlines ideas to make it more difficult to +fingerprint and block Tor traffic. + +Goals + +This proposal intends to normalize or remove easy-to-predict or static +values in the Tor TLS certificates and with the Tor TLS setup process. +These values can be used as criteria for the automated classification of +encrypted traffic as Tor traffic. Network observers should not be able +to trivially detect Tor merely by receiving or observing the certificate +used or advertised by a Tor relay. I also propose the creation of +a hard-to-detect covert channel through which a server can signal that it +supports the third version ("V3") of the Tor handshake protocol. + +Non-Goals + +This document is not intended to solve all of the possible active or passive +Tor fingerprinting problems. This document focuses on removing distinctive +and predictable features of TLS protocol negotiation; we do not attempt to +make guarantees about resisting other kinds of fingerprinting of Tor +traffic, such as fingerprinting techniques related to timing or volume of +transmitted data. + + Implementation details + + +Certificate Issues + +The CN or commonName ASN1 field + +Tor generates certificates with a predictable commonName field; the +field is within a given range of values that is specific to Tor. +Additionally, the generated host names have other undesirable properties. +The host names typically do not resolve in the DNS because the domain +names referred to are generated at random. Although they are syntatically +valid, they usually refer to domains that have never been registered by +any domain name registrar. + +An example of the current commonName field: CN=www.s4ku5skci.net + +An example of OpenSSL’s asn1parse over a typical Tor certificate: + + 0:d=0 hl=4 l= 438 cons: SEQUENCE + 4:d=1 hl=4 l= 287 cons: SEQUENCE + 8:d=2 hl=2 l= 3 cons: cont [ 0 ] + 10:d=3 hl=2 l= 1 prim: INTEGER :02 + 13:d=2 hl=2 l= 4 prim: INTEGER :4D3C763A + 19:d=2 hl=2 l= 13 cons: SEQUENCE + 21:d=3 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption + 32:d=3 hl=2 l= 0 prim: NULL + 34:d=2 hl=2 l= 35 cons: SEQUENCE + 36:d=3 hl=2 l= 33 cons: SET + 38:d=4 hl=2 l= 31 cons: SEQUENCE + 40:d=5 hl=2 l= 3 prim: OBJECT :commonName + 45:d=5 hl=2 l= 24 prim: PRINTABLESTRING :www.vsbsvwu5b4soh4wg.net + 71:d=2 hl=2 l= 30 cons: SEQUENCE + 73:d=3 hl=2 l= 13 prim: UTCTIME :110123184058Z + 88:d=3 hl=2 l= 13 prim: UTCTIME :110123204058Z + 103:d=2 hl=2 l= 28 cons: SEQUENCE + 105:d=3 hl=2 l= 26 cons: SET + 107:d=4 hl=2 l= 24 cons: SEQUENCE + 109:d=5 hl=2 l= 3 prim: OBJECT :commonName + 114:d=5 hl=2 l= 17 prim: PRINTABLESTRING :www.s4ku5skci.net + 133:d=2 hl=3 l= 159 cons: SEQUENCE + 136:d=3 hl=2 l= 13 cons: SEQUENCE + 138:d=4 hl=2 l= 9 prim: OBJECT :rsaEncryption + 149:d=4 hl=2 l= 0 prim: NULL + 151:d=3 hl=3 l= 141 prim: BIT STRING + 295:d=1 hl=2 l= 13 cons: SEQUENCE + 297:d=2 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption + 308:d=2 hl=2 l= 0 prim: NULL + 310:d=1 hl=3 l= 129 prim: BIT STRING + +I propose that we match OpenSSL's default self-signed certificates. I hypothesise +that they are the most common self-signed certificates. If this turns out not +to be the case, then we should use whatever the most common turns out to be. + +Certificate serial numbers + +Currently our generated certificate serial number is set to the number of +seconds since the epoch at the time of the certificate's creation. I propose +that we should ensure that our serial numbers are unrelated to the epoch, +since the generation methods are potentially recognizable as Tor-related. + +Instead, I propose that we use a randomly generated number that is +subsequently hashed with SHA-512 and then truncate the data to eight bytes[1]. + +Random sixteen byte values appear to be the high bound for serial number as +issued by Verisign and DigiCert. RapidSSL appears to be three bytes in length. +Others common byte lengths appear to be between one and four bytes. The default +OpenSSL certificates are eight bytes and we should use this length with our +self-signed certificates. + +This randomly generated serial number field may now serve as a covert channel +that signals to the client that the OR will not support TLS renegotiation; this +means that the client can expect to perform a V3 TLS handshake setup. +Otherwise, if the serial number is a reasonable time since the epoch, we should +assume the OR is using an earlier protocol version and hence that it expects +renegotiation. + +We also have a need to signal properties with our certificates for a possible +v3 handshake in the future. Therefore I propose that we match OpenSSL default +self-signed certificates (a 64-bit random number), but reserve the two least- +significant bits for signaling. For the moment, these two bits will be zero. + +This means that an attacker may be able to identify Tor certificates from default +OpenSSL certificates with a 75% probability. + +As a security note, care must be taken to ensure that supporting this +covert channel will not lead to an attacker having a method to downgrade client +behavior. This shouldn't be a risk because the TLS Finished message hashes over +all the bytes of the handshake, including the certificates. + +Certificate fingerprinting issues expressed as base64 encoding + +It appears that all deployed Tor certificates have the following strings in +common: + +MIIB +CCA +gAwIBAgIETU +ANBgkqhkiG9w0BAQUFADA +YDVQQDEx +3d3cu + +As expected these values correspond to specific ASN.1 OBJECT IDENTIFIER (OID) +properties (sha1WithRSAEncryption, commonName, etc) of how we generate our +certificates. + +As an illustrated example of the common bytes of all certificates used within +the Tor network within a single one hour window, I have replaced the actual +value with a wild card ('.') character here: + +-----BEGIN CERTIFICATE----- +MIIB..CCA..gAwIBAgIETU....ANBgkqhkiG9w0BAQUFADA.M..w..YDVQQDEx.3 +d3cu............................................................ +................................................................ +................................................................ +................................................................ +................................................................ +................................................................ +................................................................ +................................................................ +........................... <--- Variable length and padding +-----END CERTIFICATE----- + +This fine ascii art only illustrates the bytes that absolutely match in all +cases. In many cases, it's likely that there is a high probability for a given +byte to be only a small subset of choices. + +Using the above strings, the EFF's certificate observatory may trivially +discover all known relays, known bridges and unknown bridges in a single SQL +query. I propose that we ensure that we test our certificates to ensure that +they do not have these kinds of statistical similarities without ensuring +overlap with a very large cross section of the internet's certificates. + +Certificate dating and validity issues + +TLS certificates found in the wild are generally found to be long-lived; +they are frequently old and often even expired. The current Tor certificate +validity time is a very small time window starting at generation time and +ending shortly thereafter, as defined in or.h by MAX_SSL_KEY_LIFETIME +(2*60*60). + +I propose that the certificate validity time length is extended to a period of +twelve Earth months, possibly with a small random skew to be determined by the +implementer. Tor should randomly set the start date in the past or some +currently unspecified window of time before the current date. This would +more closely track the typical distribution of non-Tor TLS certificate +expiration times. + +The certificate values, such as expiration, should not be used for anything +relating to security; for example, if the OR presents an expired TLS +certificate, this does not imply that the client should terminate the +connection (as would be appropriate for an ordinary TLS implementation). +Rather, I propose we use a TOFU style expiration policy - the certificate +should never be trusted for more than a two hour window from first sighting. + +This policy should have two major impacts. The first is that an adversary will +have to perform a differential analysis of all certificates for a given IP +address rather than a single check. The second is that the server expiration +time is enforced by the client and confirmed by keys rotating in the consensus. + +The expiration time should not be a fixed time that is simple to calculate by +any Deep Packet Inspection device or it will become a new Tor TLS setup +fingerprint. + +Proposed certificate form + +The following output from openssl asn1parse results from the proposed +certificate generation algorithm. It matches the results of generating a +default self-signed certificate: + + 0:d=0 hl=4 l= 513 cons: SEQUENCE + 4:d=1 hl=4 l= 362 cons: SEQUENCE + 8:d=2 hl=2 l= 9 prim: INTEGER :DBF6B3B864FF7478 + 19:d=2 hl=2 l= 13 cons: SEQUENCE + 21:d=3 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption + 32:d=3 hl=2 l= 0 prim: NULL + 34:d=2 hl=2 l= 69 cons: SEQUENCE + 36:d=3 hl=2 l= 11 cons: SET + 38:d=4 hl=2 l= 9 cons: SEQUENCE + 40:d=5 hl=2 l= 3 prim: OBJECT :countryName + 45:d=5 hl=2 l= 2 prim: PRINTABLESTRING :AU + 49:d=3 hl=2 l= 19 cons: SET + 51:d=4 hl=2 l= 17 cons: SEQUENCE + 53:d=5 hl=2 l= 3 prim: OBJECT :stateOrProvinceName + 58:d=5 hl=2 l= 10 prim: PRINTABLESTRING :Some-State + 70:d=3 hl=2 l= 33 cons: SET + 72:d=4 hl=2 l= 31 cons: SEQUENCE + 74:d=5 hl=2 l= 3 prim: OBJECT :organizationName + 79:d=5 hl=2 l= 24 prim: PRINTABLESTRING :Internet Widgits Pty Ltd + 105:d=2 hl=2 l= 30 cons: SEQUENCE + 107:d=3 hl=2 l= 13 prim: UTCTIME :110217011237Z + 122:d=3 hl=2 l= 13 prim: UTCTIME :120217011237Z + 137:d=2 hl=2 l= 69 cons: SEQUENCE + 139:d=3 hl=2 l= 11 cons: SET + 141:d=4 hl=2 l= 9 cons: SEQUENCE + 143:d=5 hl=2 l= 3 prim: OBJECT :countryName + 148:d=5 hl=2 l= 2 prim: PRINTABLESTRING :AU + 152:d=3 hl=2 l= 19 cons: SET + 154:d=4 hl=2 l= 17 cons: SEQUENCE + 156:d=5 hl=2 l= 3 prim: OBJECT :stateOrProvinceName + 161:d=5 hl=2 l= 10 prim: PRINTABLESTRING :Some-State + 173:d=3 hl=2 l= 33 cons: SET + 175:d=4 hl=2 l= 31 cons: SEQUENCE + 177:d=5 hl=2 l= 3 prim: OBJECT :organizationName + 182:d=5 hl=2 l= 24 prim: PRINTABLESTRING :Internet Widgits Pty Ltd + 208:d=2 hl=3 l= 159 cons: SEQUENCE + 211:d=3 hl=2 l= 13 cons: SEQUENCE + 213:d=4 hl=2 l= 9 prim: OBJECT :rsaEncryption + 224:d=4 hl=2 l= 0 prim: NULL + 226:d=3 hl=3 l= 141 prim: BIT STRING + 370:d=1 hl=2 l= 13 cons: SEQUENCE + 372:d=2 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption + 383:d=2 hl=2 l= 0 prim: NULL + 385:d=1 hl=3 l= 129 prim: BIT STRING + + +Custom Certificates + +It should be possible for a Tor relay operator to use a specifically supplied +certificate and secret key. This will allow a relay or bridge operator to use a +certificate signed by any member of any geographically relevant certificate +authority racket; it will also allow for any other user-supplied certificate. +This may be desirable in some kinds of filtered networks or when attempting to +avoid attracting suspicion by blending in with the TLS web server certificate +crowd. + +Problematic Diffie–Hellman parameters + +We currently send a static Diffie–Hellman parameter, prime p (or “prime p +outlaw”) as specified in RFC2409 as part of the TLS Server Hello response. + +The use of this prime in TLS negotiations may, as a result, be filtered and +effectively banned by certain networks. We do not have to use this particular +prime in all cases. + +While amusing to have the power to make specific prime numbers into a new class +of numbers (cf. imaginary, irrational, illegal [3]) - our new friend prime p +outlaw is not required. + +The use of this prime in TLS negotiations may, as a result, be filtered and +effectively banned by certain networks. We do not have to use this particular +prime in all cases. + +I propose that the function to initialize and generate DH parameters be +split into two functions. + +First, init_dh_param() should be used only for OR-to-OR DH setup and +communication. Second, it is proposed that we create a new function +init_tls_dh_param() that will have a two-stage development process. + +The first stage init_tls_dh_param() will use the same prime that +Apache2.x [4] sends (or “dh1024_apache_p”), and this change should be +made immediately. This is a known good and safe prime number (p-1 / 2 +is also prime) that is currently not known to be blocked. + +The second stage init_tls_dh_param() should randomly generate a new prime on a +regular basis; this is designed to make the prime difficult to outlaw or +filter. Call this a shape-shifting or "Rakshasa" prime. This should be added +to the 0.2.3.x branch of Tor. This prime can be generated at setup or execution +time and probably does not need to be stored on disk. Rakshasa primes only +need to be generated by Tor relays as Tor clients will never send them. Such +a prime should absolutely not be shared between different Tor relays nor +should it ever be static after the 0.2.3.x release. + +As a security precaution, care must be taken to ensure that we do not generate +weak primes or known filtered primes. Both weak and filtered primes will +undermine the TLS connection security properties. OpenSSH solves this issue +dynamically in RFC 4419 [5] and may provide a solution that works reasonably +well for Tor. More research in this area including the applicability of +Miller-Rabin or AKS primality tests[6] will need to be analyzed and probably +added to Tor. + +Practical key size + +Currently we use a 1024 bit long RSA modulus. I propose that we increase the +RSA key size to 2048 as an additional channel to signal support for the V3 +handshake setup. 2048 appears to be the most common key size[0] above 1024. +Additionally, the increase in modulus size provides a reasonable security boost +with regard to key security properties. + +The implementer should increase the 1024 bit RSA modulus to 2048 bits. + +Possible future filtering nightmares + +At some point it may cost effective or politically feasible for a network +filter to simply block all signed or self-signed certificates without a known +valid CA trust chain. This will break many applications on the internet and +hopefully, our option for custom certificates will ensure that this step is +simply avoided by the censors. + +The Rakshasa prime approach may cause censors to specifically allow only +certain known and accepted DH parameters. + + +Appendix: Other issues + +What other obvious TLS certificate issues exist? What other static values are +present in the Tor TLS setup process? + +[0] http://archives.seul.org/or/dev/Jan-2011/msg00051.html +[1] http://archives.seul.org/or/dev/Feb-2011/msg00016.html +[2] http://archives.seul.org/or/dev/Feb-2011/msg00039.html +[3] To be fair this is hardly a new class of numbers. History is rife with + similar examples of inane authoritarian attempts at mathematical secrecy. + Probably the most dramatic example is the story of the pupil Hipassus of + Metapontum, pupil of the famous Pythagoras, who, legend goes, proved the + fact that Root2 cannot be expressed as a fraction of whole numbers (now + called an irrational number) and was assassinated for revealing this + secret. Further reading on the subject may be found on the Wikipedia: + http://en.wikipedia.org/wiki/Hippasus + +[4] httpd-2.2.17/modules/ss/ssl_engine_dh.c +[5] http://tools.ietf.org/html/rfc4419 +[6] http://archives.seul.org/or/dev/Jan-2011/msg00037.html diff --git a/proposals/ideas/xxx-TLS-cert-and-parameter-normalization.txt b/proposals/ideas/xxx-TLS-cert-and-parameter-normalization.txt deleted file mode 100644 index 74704b1..0000000 --- a/proposals/ideas/xxx-TLS-cert-and-parameter-normalization.txt +++ /dev/null @@ -1,360 +0,0 @@ -Filename: xxx-TLS-cert-and-parameter-normalization.txt -Title: TLS certificate and parameter normalization -Author: Jacob Appelbaum, Gladys Shufflebottom -Created: 16-Feb-2011 -Status: Draft - - - Draft spec for TLS certificate and handshake normalization - - - Overview - -Scope - -This is a document that proposes improvements to problems with Tor's -current TLS (Transport Layer Security) certificates and handshake that will -reduce the distinguishability of Tor traffic from other encrypted traffic that -uses TLS. It also addresses some of the possible fingerprinting attacks -possible against the current Tor TLS protocol setup process. - -Motivation and history - -Censorship is an arms race and this is a step forward in the defense -of Tor. This proposal outlines ideas to make it more difficult to -fingerprint and block Tor traffic. - -Goals - -This proposal intends to normalize or remove easy-to-predict or static -values in the Tor TLS certificates and with the Tor TLS setup process. -These values can be used as criteria for the automated classification of -encrypted traffic as Tor traffic. Network observers should not be able -to trivially detect Tor merely by receiving or observing the certificate -used or advertised by a Tor relay. I also propose the creation of -a hard-to-detect covert channel through which a server can signal that it -supports the third version ("V3") of the Tor handshake protocol. - -Non-Goals - -This document is not intended to solve all of the possible active or passive -Tor fingerprinting problems. This document focuses on removing distinctive -and predictable features of TLS protocol negotiation; we do not attempt to -make guarantees about resisting other kinds of fingerprinting of Tor -traffic, such as fingerprinting techniques related to timing or volume of -transmitted data. - - Implementation details - - -Certificate Issues - -The CN or commonName ASN1 field - -Tor generates certificates with a predictable commonName field; the -field is within a given range of values that is specific to Tor. -Additionally, the generated host names have other undesirable properties. -The host names typically do not resolve in the DNS because the domain -names referred to are generated at random. Although they are syntatically -valid, they usually refer to domains that have never been registered by -any domain name registrar. - -An example of the current commonName field: CN=www.s4ku5skci.net - -An example of OpenSSL’s asn1parse over a typical Tor certificate: - - 0:d=0 hl=4 l= 438 cons: SEQUENCE - 4:d=1 hl=4 l= 287 cons: SEQUENCE - 8:d=2 hl=2 l= 3 cons: cont [ 0 ] - 10:d=3 hl=2 l= 1 prim: INTEGER :02 - 13:d=2 hl=2 l= 4 prim: INTEGER :4D3C763A - 19:d=2 hl=2 l= 13 cons: SEQUENCE - 21:d=3 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption - 32:d=3 hl=2 l= 0 prim: NULL - 34:d=2 hl=2 l= 35 cons: SEQUENCE - 36:d=3 hl=2 l= 33 cons: SET - 38:d=4 hl=2 l= 31 cons: SEQUENCE - 40:d=5 hl=2 l= 3 prim: OBJECT :commonName - 45:d=5 hl=2 l= 24 prim: PRINTABLESTRING :www.vsbsvwu5b4soh4wg.net - 71:d=2 hl=2 l= 30 cons: SEQUENCE - 73:d=3 hl=2 l= 13 prim: UTCTIME :110123184058Z - 88:d=3 hl=2 l= 13 prim: UTCTIME :110123204058Z - 103:d=2 hl=2 l= 28 cons: SEQUENCE - 105:d=3 hl=2 l= 26 cons: SET - 107:d=4 hl=2 l= 24 cons: SEQUENCE - 109:d=5 hl=2 l= 3 prim: OBJECT :commonName - 114:d=5 hl=2 l= 17 prim: PRINTABLESTRING :www.s4ku5skci.net - 133:d=2 hl=3 l= 159 cons: SEQUENCE - 136:d=3 hl=2 l= 13 cons: SEQUENCE - 138:d=4 hl=2 l= 9 prim: OBJECT :rsaEncryption - 149:d=4 hl=2 l= 0 prim: NULL - 151:d=3 hl=3 l= 141 prim: BIT STRING - 295:d=1 hl=2 l= 13 cons: SEQUENCE - 297:d=2 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption - 308:d=2 hl=2 l= 0 prim: NULL - 310:d=1 hl=3 l= 129 prim: BIT STRING - -I propose that we match OpenSSL's default self-signed certificates. I hypothesise -that they are the most common self-signed certificates. If this turns out not -to be the case, then we should use whatever the most common turns out to be. - -Certificate serial numbers - -Currently our generated certificate serial number is set to the number of -seconds since the epoch at the time of the certificate's creation. I propose -that we should ensure that our serial numbers are unrelated to the epoch, -since the generation methods are potentially recognizable as Tor-related. - -Instead, I propose that we use a randomly generated number that is -subsequently hashed with SHA-512 and then truncate the data to eight bytes[1]. - -Random sixteen byte values appear to be the high bound for serial number as -issued by Verisign and DigiCert. RapidSSL appears to be three bytes in length. -Others common byte lengths appear to be between one and four bytes. The default -OpenSSL certificates are eight bytes and we should use this length with our -self-signed certificates. - -This randomly generated serial number field may now serve as a covert channel -that signals to the client that the OR will not support TLS renegotiation; this -means that the client can expect to perform a V3 TLS handshake setup. -Otherwise, if the serial number is a reasonable time since the epoch, we should -assume the OR is using an earlier protocol version and hence that it expects -renegotiation. - -We also have a need to signal properties with our certificates for a possible -v3 handshake in the future. Therefore I propose that we match OpenSSL default -self-signed certificates (a 64-bit random number), but reserve the two least- -significant bits for signaling. For the moment, these two bits will be zero. - -This means that an attacker may be able to identify Tor certificates from default -OpenSSL certificates with a 75% probability. - -As a security note, care must be taken to ensure that supporting this -covert channel will not lead to an attacker having a method to downgrade client -behavior. This shouldn't be a risk because the TLS Finished message hashes over -all the bytes of the handshake, including the certificates. - -Certificate fingerprinting issues expressed as base64 encoding - -It appears that all deployed Tor certificates have the following strings in -common: - -MIIB -CCA -gAwIBAgIETU -ANBgkqhkiG9w0BAQUFADA -YDVQQDEx -3d3cu - -As expected these values correspond to specific ASN.1 OBJECT IDENTIFIER (OID) -properties (sha1WithRSAEncryption, commonName, etc) of how we generate our -certificates. - -As an illustrated example of the common bytes of all certificates used within -the Tor network within a single one hour window, I have replaced the actual -value with a wild card ('.') character here: - ------BEGIN CERTIFICATE----- -MIIB..CCA..gAwIBAgIETU....ANBgkqhkiG9w0BAQUFADA.M..w..YDVQQDEx.3 -d3cu............................................................ -................................................................ -................................................................ -................................................................ -................................................................ -................................................................ -................................................................ -................................................................ -........................... <--- Variable length and padding ------END CERTIFICATE----- - -This fine ascii art only illustrates the bytes that absolutely match in all -cases. In many cases, it's likely that there is a high probability for a given -byte to be only a small subset of choices. - -Using the above strings, the EFF's certificate observatory may trivially -discover all known relays, known bridges and unknown bridges in a single SQL -query. I propose that we ensure that we test our certificates to ensure that -they do not have these kinds of statistical similarities without ensuring -overlap with a very large cross section of the internet's certificates. - -Certificate dating and validity issues - -TLS certificates found in the wild are generally found to be long-lived; -they are frequently old and often even expired. The current Tor certificate -validity time is a very small time window starting at generation time and -ending shortly thereafter, as defined in or.h by MAX_SSL_KEY_LIFETIME -(2*60*60). - -I propose that the certificate validity time length is extended to a period of -twelve Earth months, possibly with a small random skew to be determined by the -implementer. Tor should randomly set the start date in the past or some -currently unspecified window of time before the current date. This would -more closely track the typical distribution of non-Tor TLS certificate -expiration times. - -The certificate values, such as expiration, should not be used for anything -relating to security; for example, if the OR presents an expired TLS -certificate, this does not imply that the client should terminate the -connection (as would be appropriate for an ordinary TLS implementation). -Rather, I propose we use a TOFU style expiration policy - the certificate -should never be trusted for more than a two hour window from first sighting. - -This policy should have two major impacts. The first is that an adversary will -have to perform a differential analysis of all certificates for a given IP -address rather than a single check. The second is that the server expiration -time is enforced by the client and confirmed by keys rotating in the consensus. - -The expiration time should not be a fixed time that is simple to calculate by -any Deep Packet Inspection device or it will become a new Tor TLS setup -fingerprint. - -Proposed certificate form - -The following output from openssl asn1parse results from the proposed -certificate generation algorithm. It matches the results of generating a -default self-signed certificate: - - 0:d=0 hl=4 l= 513 cons: SEQUENCE - 4:d=1 hl=4 l= 362 cons: SEQUENCE - 8:d=2 hl=2 l= 9 prim: INTEGER :DBF6B3B864FF7478 - 19:d=2 hl=2 l= 13 cons: SEQUENCE - 21:d=3 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption - 32:d=3 hl=2 l= 0 prim: NULL - 34:d=2 hl=2 l= 69 cons: SEQUENCE - 36:d=3 hl=2 l= 11 cons: SET - 38:d=4 hl=2 l= 9 cons: SEQUENCE - 40:d=5 hl=2 l= 3 prim: OBJECT :countryName - 45:d=5 hl=2 l= 2 prim: PRINTABLESTRING :AU - 49:d=3 hl=2 l= 19 cons: SET - 51:d=4 hl=2 l= 17 cons: SEQUENCE - 53:d=5 hl=2 l= 3 prim: OBJECT :stateOrProvinceName - 58:d=5 hl=2 l= 10 prim: PRINTABLESTRING :Some-State - 70:d=3 hl=2 l= 33 cons: SET - 72:d=4 hl=2 l= 31 cons: SEQUENCE - 74:d=5 hl=2 l= 3 prim: OBJECT :organizationName - 79:d=5 hl=2 l= 24 prim: PRINTABLESTRING :Internet Widgits Pty Ltd - 105:d=2 hl=2 l= 30 cons: SEQUENCE - 107:d=3 hl=2 l= 13 prim: UTCTIME :110217011237Z - 122:d=3 hl=2 l= 13 prim: UTCTIME :120217011237Z - 137:d=2 hl=2 l= 69 cons: SEQUENCE - 139:d=3 hl=2 l= 11 cons: SET - 141:d=4 hl=2 l= 9 cons: SEQUENCE - 143:d=5 hl=2 l= 3 prim: OBJECT :countryName - 148:d=5 hl=2 l= 2 prim: PRINTABLESTRING :AU - 152:d=3 hl=2 l= 19 cons: SET - 154:d=4 hl=2 l= 17 cons: SEQUENCE - 156:d=5 hl=2 l= 3 prim: OBJECT :stateOrProvinceName - 161:d=5 hl=2 l= 10 prim: PRINTABLESTRING :Some-State - 173:d=3 hl=2 l= 33 cons: SET - 175:d=4 hl=2 l= 31 cons: SEQUENCE - 177:d=5 hl=2 l= 3 prim: OBJECT :organizationName - 182:d=5 hl=2 l= 24 prim: PRINTABLESTRING :Internet Widgits Pty Ltd - 208:d=2 hl=3 l= 159 cons: SEQUENCE - 211:d=3 hl=2 l= 13 cons: SEQUENCE - 213:d=4 hl=2 l= 9 prim: OBJECT :rsaEncryption - 224:d=4 hl=2 l= 0 prim: NULL - 226:d=3 hl=3 l= 141 prim: BIT STRING - 370:d=1 hl=2 l= 13 cons: SEQUENCE - 372:d=2 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption - 383:d=2 hl=2 l= 0 prim: NULL - 385:d=1 hl=3 l= 129 prim: BIT STRING - - -Custom Certificates - -It should be possible for a Tor relay operator to use a specifically supplied -certificate and secret key. This will allow a relay or bridge operator to use a -certificate signed by any member of any geographically relevant certificate -authority racket; it will also allow for any other user-supplied certificate. -This may be desirable in some kinds of filtered networks or when attempting to -avoid attracting suspicion by blending in with the TLS web server certificate -crowd. - -Problematic Diffie–Hellman parameters - -We currently send a static Diffie–Hellman parameter, prime p (or “prime p -outlaw”) as specified in RFC2409 as part of the TLS Server Hello response. - -The use of this prime in TLS negotiations may, as a result, be filtered and -effectively banned by certain networks. We do not have to use this particular -prime in all cases. - -While amusing to have the power to make specific prime numbers into a new class -of numbers (cf. imaginary, irrational, illegal [3]) - our new friend prime p -outlaw is not required. - -The use of this prime in TLS negotiations may, as a result, be filtered and -effectively banned by certain networks. We do not have to use this particular -prime in all cases. - -I propose that the function to initialize and generate DH parameters be -split into two functions. - -First, init_dh_param() should be used only for OR-to-OR DH setup and -communication. Second, it is proposed that we create a new function -init_tls_dh_param() that will have a two-stage development process. - -The first stage init_tls_dh_param() will use the same prime that -Apache2.x [4] sends (or “dh1024_apache_p”), and this change should be -made immediately. This is a known good and safe prime number (p-1 / 2 -is also prime) that is currently not known to be blocked. - -The second stage init_tls_dh_param() should randomly generate a new prime on a -regular basis; this is designed to make the prime difficult to outlaw or -filter. Call this a shape-shifting or "Rakshasa" prime. This should be added -to the 0.2.3.x branch of Tor. This prime can be generated at setup or execution -time and probably does not need to be stored on disk. Rakshasa primes only -need to be generated by Tor relays as Tor clients will never send them. Such -a prime should absolutely not be shared between different Tor relays nor -should it ever be static after the 0.2.3.x release. - -As a security precaution, care must be taken to ensure that we do not generate -weak primes or known filtered primes. Both weak and filtered primes will -undermine the TLS connection security properties. OpenSSH solves this issue -dynamically in RFC 4419 [5] and may provide a solution that works reasonably -well for Tor. More research in this area including the applicability of -Miller-Rabin or AKS primality tests[6] will need to be analyzed and probably -added to Tor. - -Practical key size - -Currently we use a 1024 bit long RSA modulus. I propose that we increase the -RSA key size to 2048 as an additional channel to signal support for the V3 -handshake setup. 2048 appears to be the most common key size[0] above 1024. -Additionally, the increase in modulus size provides a reasonable security boost -with regard to key security properties. - -The implementer should increase the 1024 bit RSA modulus to 2048 bits. - -Possible future filtering nightmares - -At some point it may cost effective or politically feasible for a network -filter to simply block all signed or self-signed certificates without a known -valid CA trust chain. This will break many applications on the internet and -hopefully, our option for custom certificates will ensure that this step is -simply avoided by the censors. - -The Rakshasa prime approach may cause censors to specifically allow only -certain known and accepted DH parameters. - - -Appendix: Other issues - -What other obvious TLS certificate issues exist? What other static values are -present in the Tor TLS setup process? - -[0] http://archives.seul.org/or/dev/Jan-2011/msg00051.html -[1] http://archives.seul.org/or/dev/Feb-2011/msg00016.html -[2] http://archives.seul.org/or/dev/Feb-2011/msg00039.html -[3] To be fair this is hardly a new class of numbers. History is rife with - similar examples of inane authoritarian attempts at mathematical secrecy. - Probably the most dramatic example is the story of the pupil Hipassus of - Metapontum, pupil of the famous Pythagoras, who, legend goes, proved the - fact that Root2 cannot be expressed as a fraction of whole numbers (now - called an irrational number) and was assassinated for revealing this - secret. Further reading on the subject may be found on the Wikipedia: - http://en.wikipedia.org/wiki/Hippasus - -[4] httpd-2.2.17/modules/ss/ssl_engine_dh.c -[5] http://tools.ietf.org/html/rfc4419 -[6] http://archives.seul.org/or/dev/Jan-2011/msg00037.html

1 0

r24292: {website} Updated page content to accurately reflect features for Orbo (website/trunk/docs/en)
by Nathan Freitas 02 Mar '11

02 Mar '11

Author: n8fr8 Date: 2011-03-02 21:16:07 +0000 (Wed, 02 Mar 2011) New Revision: 24292 Modified: website/trunk/docs/en/android.wml Log: Updated page content to accurately reflect features for Orbot 1.0.4.1. Modified information on related apps, supported devices, roms, etc. Modified: website/trunk/docs/en/android.wml =================================================================== --- website/trunk/docs/en/android.wml 2011-03-02 21:15:28 UTC (rev 24291) +++ website/trunk/docs/en/android.wml 2011-03-02 21:16:07 UTC (rev 24292) @@ -25,7 +25,7 @@ Orbot contains Tor, libevent and privoxy. Orbot provides a local HTTP proxy and the standard SOCKS4A/SOCKS5 proxy interfaces into the Tor network. Orbot has the ability to transparently torify all of the TCP traffic on your Android - device when it has the correct permissions. + device when it has the correct permissions and system libraries. </p> <a id="QrCode"></a> @@ -96,26 +96,22 @@ </p> <br> <p> - For standard Android 1.x devices (G1, MyTouch3G, Hero, Droid Eris, Cliq, Moment): + For standard Android 1.x devices: </p> <ul> - <li>The “ProxySurf” browser available in the Android Market allows for use - of a proxy. Simply set the HTTP Proxy to '127.0.0.1' and port '8118'. - <b>This only proxies some traffic and should not be considered secure.</b> + <li>The Orweb browser available in the Android Market integrates directly with Orbot, and offers a number of other privacy-oriented features. </li> - <li>For Instant Messsaging, try “Beem” in the market, and set the Proxy to SOCKS5 '127.0.0.1' and port '9050'.</li> + <li>For Instant Messsaging, try <a href="https://guardianproject.info/apps/gibber">Gibberbot</a>, which includes support for connecting via Tor and Off-the-Record encryption.</li> </ul> <p> - For Android 2.x devices: Droid, Nexus One + For Android 2.x devices: </p> <ul> - <li>You must root your device for Orbot to transparently proxy all TCP traffic.</li> - <li>For non-modified and non-rooted phones, you'll want to manually configure - your specific applications.</li> - <li>If you root your device, whether it is 1.x or 2.x based, Orbot will - automatically, transparently proxy all web traffic on port 80 and 443 - and all DNS requests. This includes the built-in Browser, Gmail, YouTube, - Maps and any other application that uses standard web traffic.</li> + <li>You must root your device and update the firmware to an iptables-capable ROM for Orbot to transparently proxy all TCP traffic.</li> + <li>For non-modified and non-rooted phones, you'll want to manually configure HTTP or SOCKS proxy settings for specific applications.</li> + <li>If you root your device and install an iptables-capable ROM (such as <a href="http://cyanogenmod.com">Cyanogen<a/>), Orbot can transparently proxy traffic on an app-by-app basis through Tor.</li> + <li>You can also install Firefox for Android from the market with the <a href="https://guardianproject.info/apps/proxymob">ProxyMob Add-on</a> or install the text-only “NDBrowser” from the Android Market. Both of these solutions all routing of web access through Tor on standard, un-rooted devices. + <li>For Instant Messaging, try <a href="https://guardianproject.info/apps/gibber">Gibberbot</a>, which includes support for connecting via Tor and Off-the-Record encryption.</li> </ul> <a id="Source"></a>

1 0

r24291: {website} modified version for new Android build (website/trunk/include)
by Nathan Freitas 02 Mar '11

02 Mar '11

Author: n8fr8 Date: 2011-03-02 21:15:28 +0000 (Wed, 02 Mar 2011) New Revision: 24291 Modified: website/trunk/include/versions.wmi Log: modified version for new Android build Modified: website/trunk/include/versions.wmi =================================================================== --- website/trunk/include/versions.wmi 2011-03-02 19:30:13 UTC (rev 24290) +++ website/trunk/include/versions.wmi 2011-03-02 21:15:28 UTC (rev 24291) @@ -47,8 +47,8 @@ <define-tag version-vidalia-stable whitespace=delete>0.2.10</define-tag> -<define-tag version-androidbundle-tor whitespace=delete>0.2.2.14-alpha</define-tag> -<define-tag version-androidbundle-orbot whitespace=delete>1.0.4</define-tag> +<define-tag version-androidbundle-tor whitespace=delete>0.2.2.22-alpha</define-tag> +<define-tag version-androidbundle-orbot whitespace=delete>1.0.4.1</define-tag> <define-tag version-androidbundle-privoxy whitespace=delete>privoxy-3.0.12-stable</define-tag> <define-tag version-androidbundle-libevent whitespace=delete>libevent-1.4.12-stable</define-tag> <define-tag package-androidbundle-alpha whitespace=delete>dist/android/<version-androidbundle-tor>-orbot-<version-androidbundle-orbot>.apk</define-tag>

1 0

[torsocks/master] Fix breakage from previous commit
by hoganrobert＠torproject.org 02 Mar '11

02 Mar '11

commit 2c126fe090e7402f68275855e1abbf2f74550818 Author: Robert Hogan <robert(a)roberthogan.net> Date: Wed Mar 2 20:23:02 2011 +0000 Fix breakage from previous commit Use $TORSOCKSLDFLAGS for libtorsocks and $TESTLDFLAGS for test/test_torsocks. --- configure.in | 20 +++++++++++--------- src/Makefile.am | 1 + test/Makefile.am | 1 + 3 files changed, 13 insertions(+), 9 deletions(-) diff --git a/configure.in b/configure.in index 4bc0e7b..75d5e1c 100644 --- a/configure.in +++ b/configure.in @@ -548,9 +548,10 @@ AC_DEFINE_UNQUOTED([SENDMSG_ARGNAMES],[${NAMES}],[Argument names]) # This variable is used for the LDFLAGS in test/Makefile.am TESTLDFLAGS="$LDFLAGS" +AC_SUBST(TESTLDFLAGS) # Version information for libtorsocks -LDFLAGS="$LDFLAGS -version-info 1:0:0" +TORSOCKSLDFLAGS="$LDFLAGS -version-info 1:0:0" dnl Linker checks for Mac OSX, which uses DYLD_INSERT_LIBRARIES dnl instead of LD_PRELOAD @@ -558,10 +559,10 @@ case "$host_os" in darwin*) dnl Check if the linker accepts -dynamiclib; necessary on Mac OS X AC_MSG_CHECKING(if the linker accepts -dynamiclib) - OLDLDFLAGS="$LDFLAGS" - LDFLAGS="$LDFLAGS -dynamiclib" + OLDLDFLAGS="$TORSOCKSLDFLAGS" + TORSOCKSLDFLAGS="$TORSOCKSLDFLAGS -dynamiclib" AC_TRY_COMPILE(,,AC_MSG_RESULT(yes),[ - LDFLAGS="$OLDLDFLAGS" + TORSOCKSLDFLAGS="$OLDLDFLAGS" AC_MSG_RESULT(no)]) # dnl Check if the linker accepts -multiply_defined suppress; necessary on Mac OS X @@ -574,17 +575,17 @@ darwin*) dnl Check if the linker accepts -single_module; necessary on Mac OS X AC_MSG_CHECKING(if the linker accepts -single_module) - OLDLDFLAGS="$LDFLAGS" + OLDLDFLAGS="$TORSOCKSLDFLAGS" SHLIB_EXT="so" LD_PRELOAD="LD_PRELOAD" - LDFLAGS="$LDFLAGS -single_module" + TORSOCKSLDFLAGS="$TORSOCKSLDFLAGS -single_module" AC_TRY_COMPILE(,, [ SHLIB_EXT="dylib" LD_PRELOAD="DYLD_INSERT_LIBRARIES" AC_MSG_RESULT(yes) ], [ - LDFLAGS="$OLDLDFLAGS" + TORSOCKSLDFLAGS="$OLDLDFLAGS" AC_MSG_RESULT(no) ] ) @@ -598,6 +599,7 @@ esac AC_SUBST(SHLIB_EXT) AC_SUBST(LD_PRELOAD) +AC_SUBST(TORSOCKSLDFLAGS) ############################################################################## # 7. Determine where the install should write the default configuration @@ -639,5 +641,5 @@ AC_ENABLE_SHARED AC_ENABLE_STATIC AC_CONFIG_FILES([src/usewithtor src/torsocks doc/torsocks.conf.5 doc/torsocks.8 doc/usewithtor.1 doc/torsocks.1]) -AC_CONFIG_FILES(Makefile src/Makefile doc/Makefile) -#AC_OUTPUT +AC_CONFIG_FILES(Makefile src/Makefile doc/Makefile test/Makefile) +AC_OUTPUT diff --git a/src/Makefile.am b/src/Makefile.am index 8d47fb6..5f13f47 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -6,6 +6,7 @@ libdir = @libdir@/torsocks bin_SCRIPTS = torsocks usewithtor INSTALL_SCRIPT = $(install_sh) -c -m 755 +libtorsocks_la_LDFLAGS= $(TORSOCKSLDFLAGS) # Install main library to $(prefix)/lib/tor (must match torsocks.in) lib_LTLIBRARIES = libtorsocks.la libtorsocks_la_SOURCES = torsocks.c common.c parser.c dead_pool.c darwin_warts.c socks.c diff --git a/test/Makefile.am b/test/Makefile.am index c04e5ea..159e3c9 100644 --- a/test/Makefile.am +++ b/test/Makefile.am @@ -1,5 +1,6 @@ noinst_PROGRAMS= test_torsocks test_torsocks_SOURCES= test_torsocks.c +AM_LDFLAGS= test_torsocks_LDFLAGS= $(TESTLDFLAGS) CLEANFILES= test_torsocks

1 0

[torsocks/master] Really fix multiple runs of config.status this time
by hoganrobert＠torproject.org 02 Mar '11

02 Mar '11

commit 339e9597fd77d9e84119f747e9158cb0fc4f4952 Author: Robert Hogan <robert(a)roberthogan.net> Date: Wed Mar 2 20:04:34 2011 +0000 Really fix multiple runs of config.status this time --- configure.in | 12 +++++------- src/Makefile.am | 2 -- test/Makefile.am | 1 + 3 files changed, 6 insertions(+), 9 deletions(-) diff --git a/configure.in b/configure.in index 0291f8f..4bc0e7b 100644 --- a/configure.in +++ b/configure.in @@ -546,8 +546,12 @@ AC_DEFINE_UNQUOTED([SENDMSG_ARGNAMES],[${NAMES}],[Argument names]) # we need to use DYLD_INSERT_LIBRARIES. ############################################################################## +# This variable is used for the LDFLAGS in test/Makefile.am TESTLDFLAGS="$LDFLAGS" +# Version information for libtorsocks +LDFLAGS="$LDFLAGS -version-info 1:0:0" + dnl Linker checks for Mac OSX, which uses DYLD_INSERT_LIBRARIES dnl instead of LD_PRELOAD case "$host_os" in @@ -636,10 +640,4 @@ AC_ENABLE_STATIC AC_CONFIG_FILES([src/usewithtor src/torsocks doc/torsocks.conf.5 doc/torsocks.8 doc/usewithtor.1 doc/torsocks.1]) AC_CONFIG_FILES(Makefile src/Makefile doc/Makefile) -AC_OUTPUT - -dnl Output the Makefile for test/test_torsocks. -dnl Dump any LDFLAGS that were only required for linking libtorsocks, such as -dynamiclib on OSX. -LDFLAGS="$TESTLDFLAGS" -AC_CONFIG_FILES(test/Makefile) -AC_OUTPUT +#AC_OUTPUT diff --git a/src/Makefile.am b/src/Makefile.am index d6da8f3..8d47fb6 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -9,8 +9,6 @@ INSTALL_SCRIPT = $(install_sh) -c -m 755 # Install main library to $(prefix)/lib/tor (must match torsocks.in) lib_LTLIBRARIES = libtorsocks.la libtorsocks_la_SOURCES = torsocks.c common.c parser.c dead_pool.c darwin_warts.c socks.c -libtorsocks_la_LDFLAGS = -version-info 1:0:0 -#libtorsocks_la_CFLAGS = -nostartfiles DISTCLEANFILES=parser.lo dead_pool.lo common.lo libtorsocks.lo torsocks.lo darwin_warts.lo socks.lo\ config.cache config.log config.h Makefile \ diff --git a/test/Makefile.am b/test/Makefile.am index 84e4859..c04e5ea 100644 --- a/test/Makefile.am +++ b/test/Makefile.am @@ -1,4 +1,5 @@ noinst_PROGRAMS= test_torsocks test_torsocks_SOURCES= test_torsocks.c +test_torsocks_LDFLAGS= $(TESTLDFLAGS) CLEANFILES= test_torsocks

1 0

r24290: {translation} some more text for the translation howto (translation/trunk/documentation)
by Runa Sandvik 02 Mar '11

02 Mar '11

Author: runa Date: 2011-03-02 19:30:13 +0000 (Wed, 02 Mar 2011) New Revision: 24290 Modified: translation/trunk/documentation/howto.txt Log: some more text for the translation howto Modified: translation/trunk/documentation/howto.txt =================================================================== --- translation/trunk/documentation/howto.txt 2011-03-02 17:16:57 UTC (rev 24289) +++ translation/trunk/documentation/howto.txt 2011-03-02 19:30:13 UTC (rev 24290) @@ -288,7 +288,7 @@ Start by checking out the following directory: https://svn.torproject.org/svn/projects/android/trunk/Orbot/. - You can use the following script to convert translated .po files to .xml files:: + You can use the following script to convert translated .po files to .xml files: https://svn.torproject.org/vidalia/vidalia/trunk/src/vidalia/help/content/p… NOTE: You need to have the package 'po4a' installed before running the script. @@ -369,14 +369,17 @@ directory and run 'tx pull'. Remember to commit the changes to SVN. - 2. Converting Translations to + 2. Updating the Translations on the Server Hosting Torcheck - # TODO: document how to convert translations to a useful format. + After pulling new translations from Transifex, someone will have + to put the .po files on the server where Torcheck is running so + that TorCheck.py can find them. 3. Creating/Updating Translation Template Files # TODO: document this as well - + (xgettext cgi-bin/TorCheck.py -dTorCheck -oi18n/TorCheck.pot) + 4. Adding New Translation Resources to Transifex To add new translation resources to Transifex, open up @@ -389,156 +392,59 @@ server, cd to the 'po' directory and run 'tx push' with either '-s' or '-t'. ----------------------------- TorCheck ------------------------------- +The Website: -TorCheck uses our translation portal to accept translations. Users use -the portal to check in their changes. To make use of the translations -that users have committed to the translations/ subversion module, you'll -need to ensure that you have a current checked out copy of TorCheck: + The Transifex configuration file, source file and translations can + be found here: + https://svn.torproject.org/svn/translation/trunk/projects/website/. + + You will also need to check out the wml files for the website: + https://svn.torproject.org/svn/website/trunk/. - cd check/trunk/i18n/ - check/trunk/i18n$ svn up + 1. Pulling Translations from the Transifex Server -You should see something like the following: + To pull new translations from the server, cd to the 'po' + directory in the translation module and run 'tx pull'. Remember + to commit the changes to SVN. - Fetching external item into 'pootle' - External at revision 15300. + 2. Converting Translations to WML - At revision 15300. + Simply pulling translations from the Transifex server is not + enough. To make use of the translations, you will need to convert + the .po files to .wml files. -Now if you had changes, you'd simply want to move the newly updated .po files -into the current stable directory. Moving the .po files from -'check/trunk/i18n/pootle/' into 'check/trunk/i18n' properly naming the files -for their respective locale. + You can use the 'po2wml.sh' script inside the website module to + convert translated .po files to .wml. Make sure that you check + out the two subversion modules in the same directory, so that you + have (for example) ~/tor/website and ~/tor/translation. + + NOTE: You need to have the package 'po4a' installed before running the script. -Here's an example of how to move all of the current pootle translations into -the svn trunk area of TorCheck: + 3. Creating/Updating Translation Template Files - cd check/trunk/i18n/ - for locale in `ls -1 pootle/|grep -v template`; - do - mv -v pootle/$locale/TorCheck_$locale.po TorCheck_$locale.po; - done + To create a .pot file from a new .wml file, or to update existing + .pot files when one or more website files are updated, run the + 'wml2po.sh' script. Make sure that you check out the two + subversion modules in the same directory, so that you have (for + example) ~/tor/website and ~/tor/translation. -Now check the differences (ensure the output looks reasonable): + 4. Adding New Translation Resources to Transifex - svn diff + To add new translation resources to Transifex, open up + 'po/.tx/config' and create entries for the new resources. Use an + existing entry as a template. Remember to commit the file to SVN. -Ensure that msgfmt has no errors: + 5. Pushing Files to the Transifex Server - msgfmt -C *.po + To push new/updated source files or translations to the Transifex + server, cd to the 'po' directory and run 'tx push' with either + '-s' or '-t'. -And finally check in the changes: +Tor Manual Pages: - svn commit + The Transifex configuration file, source file and translations can + be found here: + https://svn.torproject.org/svn/translation/trunk/projects/manpages/ ----------------------------- Torbutton ------------------------------- + 1. Pulling Translations from the Transifex Server -Torbutton uses our translation portal to accept translations. Users use -the portal to check in their changes. - -To make use of the translations that users have committed to the translations/ -subversion module, you'll need to ensure that you have a current checked out -copy of them in your torbutton git checkout: - - cd torbutton.git/trans_tools - torbutton.git/trans_tools$ svn co https://tor-svn.freehaven.net/svn/translation/trunk/projects/torbutton pootle - -You should see something like the following: - - Checked out revision 21092. - -If you made changes to strings in Torbutton, you need to rebuild the -templates in torbutton.git/trans_tools/pootle/templates. This is done with -the following command from within the torbutton.git checkout directory: - - moz2po -P -i src/chrome/locale/en/ -o trans_tools/pootle/templates/ - -You now have two options: - -Option 1 (The [shitty] Pootle Web UI Way): - -View then commit the changes to the template with: - - cd trans_tools/pootle - svn diff templates - svn commit templates - -Then poke Jake to 'svn up' on the Pootle side. If you do this enough -times, he may give you a button to click to update templates in Pootle, -or maybe even an account on the Pootle server. Persistence is a virtue. - -You then need to go to the Pootle website and click the checkbox next to -every language on: -https://translation.torproject.org/projects/torbutton/admin.html -and then click "Update Languages" at the bottom. - -You then need to go to each language and go to "Editing Options" and click -"Commit" for each one. - -You then need to 'svn up' locally, and follow the procedure above for -rebuilding your .dtd and .properties files. - -Yes, this sucks. :/ - -Option 2 (Use your own msgmerge: YMMV, may change .po flags and formatting): - -Run msgmerge yourself for each language: - - cd trans_tools - for i in `ls -1 pootle` - do - msgmerge -U ./pootle/$i/torbutton.dtd.po ./pootle/templates/torbutton.dtd.pot - msgmerge -U ./pootle/$i/torbutton.properties.po ./pootle/templates/torbutton.properties.pot - done - svn diff pootle - svn commit pootle - -Then poke Jake to 'svn up' on the Pootle side. If you do this enough times, -he may give you a button on Pootle, or maybe even an account on the Pootle -server. Persistence is a virtue. - -You may notice that some .po file flags and string formatting have changed -with this method, depending on your gettext version. It is unclear if this -is a problem. Please update this doc if you hit a landmine and everything -breaks :) - -After this process is done, you then need to regenerate the mozilla -.dtd and .properties files as specified above. - - -Regardless of whether or not you had changes in the torbutton strings, if there -were updated strings in pootle that you checked out from svn you now need to -convert from .po and move the newly updated mozilla files into the current -stable locale directory. First convert them with the 'mkmoz.sh' script and -then move the proper mozilla files from 'torbutton.git/trans_tools/moz/' into -'torbutton.git/src/chrome/locale/' directory while properly naming the files -for their respective locale. - -Here's an example of how to move all of the current pootle translations into -the svn trunk area of Torbutton: - - cd trans_tools - ./mkmoz.sh - for locale in `ls -1 moz/`; - do - mv -v moz/$locale/*.{dtd,properties} ../src/chrome/locale/$locale/ - done - -Now check the differences to your git branch to ensure the output looks -reasonable: - - cd .. - git diff - -And finally check in the changes: - - cd src/chrome/locale - git commit . - ----------------------------- Vidalia ------------------------------- - -Vidalia uses our translation portal to accept translations. Users use the -portal to check in their changes. No conversion or moving is required other -than normal pootle usage. -

1 0

[metrics-utils/master] Remove deprecated bridge descriptor sanitizer.
by karsten＠torproject.org 02 Mar '11

02 Mar '11

commit 96eb27ee126e01168245f6fc0713bfe2981202bb Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Wed Mar 2 18:20:02 2011 +0100 Remove deprecated bridge descriptor sanitizer. There is at least one known issue in this version of the bridge descriptor sanitizer: Bridge IP addresses contained in reject lines are not rewritten as 127.0.0.1. There may be further issues. People should use the bridge descriptor sanitizer that is part of metrics-db instead. --- bridge-desc-sanitizer/ConvertBridgeDescs.java | 461 ------------------------- bridge-desc-sanitizer/HOWTO | 124 ------- bridge-desc-sanitizer/LICENSE | 30 -- bridge-desc-sanitizer/extract-bridges.sh | 8 - 4 files changed, 0 insertions(+), 623 deletions(-) diff --git a/bridge-desc-sanitizer/ConvertBridgeDescs.java b/bridge-desc-sanitizer/ConvertBridgeDescs.java deleted file mode 100644 index a088695..0000000 --- a/bridge-desc-sanitizer/ConvertBridgeDescs.java +++ /dev/null @@ -1,461 +0,0 @@ -import java.io.*; -import java.util.*; -import org.apache.commons.codec.digest.DigestUtils; -import org.apache.commons.codec.binary.*; - -public class ConvertBridgeDescs { - - public static void main(String[] args) throws Exception { - - System.out.println("\n THIS SOFTWARE IS " - + "DEPRECATED !\n\nThere is at least one known issue in this " - + "software: Bridge IP addresses\ncontained in reject lines are " - + "not rewritten as 127.0.0.1. There may be\nfurther issues. " - + "Please use the bridge descriptor sanitizer that is part\nof " - + "metrics-db instead of this software:\n\n" - + " https://gitweb.torproject.org/metrics-db.git\n"); - System.exit(1); - - long started = System.currentTimeMillis(); - - if (args.length < 5) { - System.err.println("Usage: java " - + ConvertBridgeDescs.class.getSimpleName() - + " <input directory> <geoip.txt file> <YYYY> <MM> " - + "<output directory>"); - System.exit(1); - } - File inDir = new File(args[0]); - File geoipFile = new File(args[1]); - String year = args[2]; - String month = args[3]; - int yearInt = Integer.parseInt(year); - int monthInt = Integer.parseInt(month); - File outDir = new File(args[4]); - if (!outDir.exists()) { - outDir.mkdir(); - } - - SortedSet<File> statuses = new TreeSet<File>(); - Set<File> descriptors = new HashSet<File>(); - Set<File> extrainfos = new HashSet<File>(); - - System.out.print("Parsing geoip.txt file... "); - BufferedReader r = new BufferedReader(new FileReader(geoipFile)); - String line0 = null; - SortedMap<Long, String> geoipDatabase = new TreeMap<Long, String>(); - while ((line0 = r.readLine()) != null) { - if (!line0.startsWith("#")) - geoipDatabase.put(Long.parseLong(line0.split(",")[0]), - line0.substring(line0.indexOf(',') + 1)); - } - System.out.println("Found " + geoipDatabase.size() - + " entries (expected 100,000 +- 10,000)."); - - System.out.println("Checking files in " + inDir.getAbsolutePath() - + "..."); - Stack<File> directoriesLeftToParse = new Stack<File>(); - directoriesLeftToParse.push(inDir); - String currentYearAndMonth = "from-tonga-" + year + "-" + month; - String previousYearAndMonth = "from-tonga-" + (monthInt == 1 ? - "" + (yearInt - 1) + "-12" : - year + "-" + (monthInt < 11 ? "0" : "") + (monthInt - 1)); - String nextYearAndMonth = "from-tonga-" + (monthInt == 12 ? - "" + (yearInt + 1) + "-01" : - year + "-" + (monthInt < 9 ? "0" : "") + (monthInt + 1)); - while (!directoriesLeftToParse.isEmpty()) { - File directoryOrFile = directoriesLeftToParse.pop(); - String filename = directoryOrFile.getName(); - boolean addDirectory = false; - if (directoryOrFile.isDirectory()) { - if (/* base directory */ - filename.equals("in") || - /* current month */ - filename.startsWith(currentYearAndMonth) || - /* last days of previous month */ - (filename.startsWith(previousYearAndMonth) - && Integer.parseInt(filename.substring(19, 21)) > 24) || - /* first days of next month */ - (filename.startsWith(nextYearAndMonth) - && Integer.parseInt(filename.substring(19, 21)) < 6)) { - for (File fileInDir: directoryOrFile.listFiles()) { - directoriesLeftToParse.push(fileInDir); - } - } - continue; - } - if (filename.startsWith("cached-extrainfo")) { - extrainfos.add(directoryOrFile); - } else if (filename.equals("bridge-descriptors")) { - descriptors.add(directoryOrFile); - } else if (filename.equals("networkstatus-bridges")) { - statuses.add(directoryOrFile); - } - } - - int days = ((extrainfos.size() / 2 + descriptors.size() - + statuses.size()) + 3 * 24) / (3 * 48); - System.out.println("Found " + extrainfos.size() - + " cached-extrainfo[.new] files, " + descriptors.size() - + " bridge-descriptors files, and " + statuses.size() - + " networkstatus-bridges files, covering approximately " + days - + " days."); - - System.out.print("Parsing extra-info descriptors"); - String[] hex = new String[] { "0", "1", "2", "3", "4", "5", "6", "7", - "8", "9", "a", "b", "c", "d", "e", "f" }; - for (String x : hex) - for (String y : hex) - new File(outDir + File.separator + "extra-infos" + File.separator - + x + File.separator + y).mkdirs(); - Set<File> writtenExtrainfos = new HashSet<File>(); - Map<String, String> extrainfoMapping = new HashMap<String, String>(); - int parsed = 0; - for (File file : extrainfos) { - if (parsed++ > extrainfos.size() / days) { - System.out.print("."); - parsed = 0; - } - BufferedReader br = new BufferedReader(new FileReader(file)); - String line = null; - StringBuilder original = null, scrubbed = null; - boolean skipSignature = false; - while ((line = br.readLine()) != null) { - if (skipSignature && !line.equals("-----END SIGNATURE-----")) { - continue; - } else if (line.startsWith("extra-info ")) { - original = new StringBuilder(line + "\n"); - scrubbed = new StringBuilder("extra-info Unnamed " - + DigestUtils.shaHex(Hex.decodeHex( - line.split(" ")[2].toCharArray())).toUpperCase() + "\n"); - } else if (line.startsWith("published ") - || line.startsWith("write-history ") - || line.startsWith("read-history ") - || line.startsWith("geoip-start-time ") - || line.startsWith("geoip-client-origins ")) { - original.append(line + "\n"); - scrubbed.append(line + "\n"); - } else if (line.startsWith("router-signature")) { - String originalDesc = original.toString() + line + "\n"; - String originalHash = DigestUtils.shaHex(originalDesc); - String scrubbedDesc = scrubbed.toString(); - String scrubbedHash = DigestUtils.shaHex(scrubbedDesc); - if (extrainfoMapping.containsKey(originalHash) && - !extrainfoMapping.get(originalHash).equals(scrubbedHash)) { - System.out.println("We already have an extra-info mapping " - + "from " + originalHash + " to " - + extrainfoMapping.get(originalHash) + ", but we now want " - + "to add a mapping to " + scrubbedHash + ". Exiting"); - System.exit(1); - } - extrainfoMapping.put(originalHash, scrubbedHash); - File out = new File(outDir + File.separator + "extra-infos" - + File.separator + scrubbedHash.charAt(0) + File.separator - + scrubbedHash.charAt(1) + File.separator + scrubbedHash); - if (!out.exists()) { - BufferedWriter bw = new BufferedWriter(new FileWriter(out)); - bw.write(scrubbedDesc); - bw.close(); - writtenExtrainfos.add(out); - } - } else if (line.equals("-----BEGIN SIGNATURE-----")) { - skipSignature = true; - } else if (line.equals("-----END SIGNATURE-----")) { - skipSignature = false; - } else { - System.out.println("Unrecognized line '" + line + "'. Exiting"); - System.exit(1); - } - } - br.close(); - } - System.out.println("\nWrote " + writtenExtrainfos.size() - + " extra-info descriptors."); - - System.out.print("Parsing server descriptors"); - for (String x : hex) - for (String y : hex) - new File(outDir + File.separator + "descriptors" + File.separator - + x + File.separator + y).mkdirs(); - Set<File> writtenDescriptors = new HashSet<File>(); - Map<File, File> referencedExtraInfos = new HashMap<File, File>(); - Map<String, String> descriptorMapping = new HashMap<String, String>(); - int found = 0, notfound = 0; - parsed = 0; - String haveExtraInfo = null; - for (File file : descriptors) { - if (parsed++ > descriptors.size() / days) { - System.out.print("."); - parsed = 0; - } - BufferedReader br = new BufferedReader(new FileReader(file)); - String line = null, country = null; - StringBuilder original = null, scrubbed = null; - boolean skipCrypto = false, contactWritten = false; - while ((line = br.readLine()) != null) { - if (skipCrypto && !line.startsWith("-----END ")) { - original.append(line + "\n"); - continue; - } else if (line.startsWith("router ")) { - original = new StringBuilder(line + "\n"); - country = "zz"; - String[] ipParts = line.split(" ")[2].replace('.', ' ').split(" "); - long ipNum = Long.parseLong(ipParts[0]) * 256L * 256L * 256L - + Long.parseLong(ipParts[1]) * 256L * 256L - + Long.parseLong(ipParts[2]) * 256L - + Long.parseLong(ipParts[3]); - long intervalStart = -1; - if (ipNum >= geoipDatabase.firstKey()) { - intervalStart = geoipDatabase.subMap(0L, ipNum).lastKey(); - String dbContent = geoipDatabase.get(intervalStart); - long intervalEnd = Long.parseLong(dbContent.split(",")[0]); - if (ipNum <= intervalEnd) - country = dbContent.split(",")[1].toLowerCase(); - } - scrubbed = new StringBuilder("router Unnamed 127.0.0.1 " - + line.split(" ")[3] + " " + line.split(" ")[4] + " " - + line.split(" ")[5] + "\n"); - contactWritten = false; - haveExtraInfo = null; - } else if (line.startsWith("opt fingerprint ")) { - original.append(line + "\n"); - scrubbed.append("opt fingerprint"); - String fingerprint = DigestUtils.shaHex(Hex.decodeHex( - line.substring(16).replaceAll(" ", "").toCharArray())). - toUpperCase(); - for (int i = 0; i < fingerprint.length() / 4; i++) - scrubbed.append(" " + fingerprint.substring(4 * i, 4 * (i + 1))); - scrubbed.append("\n"); - } else if (line.startsWith("contact ")) { - original.append(line + "\n"); - scrubbed.append("contact somebody at example dot " + country - + "\n"); - contactWritten = true; - } else if (line.startsWith("router-signature")) { - String originalDesc = original.toString() + line + "\n"; - String originalHash = DigestUtils.shaHex(originalDesc); - String scrubbedDesc = scrubbed.toString(); - String scrubbedHash = DigestUtils.shaHex(scrubbedDesc); - if (descriptorMapping.containsKey(originalHash) && - !descriptorMapping.get(originalHash).equals(scrubbedHash)) { - System.out.println("We already have a descriptor mapping " - + "from " + originalHash + " to " - + descriptorMapping.get(originalHash) + ", but we now " - + "want to add a mapping to " + scrubbedHash - + ". Exiting"); - System.exit(1); - } - descriptorMapping.put(originalHash, scrubbedHash); - if (haveExtraInfo != null) { - File out = new File(outDir + File.separator + "descriptors" - + File.separator + scrubbedHash.charAt(0) + File.separator - + scrubbedHash.charAt(1) + File.separator + scrubbedHash); - if (!out.exists()) { - BufferedWriter bw2 = new BufferedWriter(new FileWriter(out)); - bw2.write(scrubbedDesc); - bw2.close(); - writtenDescriptors.add(out); - String extraInfoHash = haveExtraInfo.toLowerCase(); - File extrainfoFile = new File(outDir + File.separator - + "extra-infos" + File.separator - + extraInfoHash.charAt(0) + File.separator - + extraInfoHash.charAt(1) + File.separator - + extraInfoHash); - if (!extrainfoFile.exists()) { - System.out.println("Extra-info descriptor '" - + extrainfoFile + "' does not exist."); - System.exit(1); - } - referencedExtraInfos.put(out, extrainfoFile); - } - } - } else if (line.startsWith("opt extra-info-digest ")) { - String originalExtraInfo = line.split(" ")[2].toLowerCase(); - if (!extrainfoMapping.containsKey(originalExtraInfo)) { - notfound++; - } else { - found++; - original.append(line + "\n"); - haveExtraInfo = extrainfoMapping.get(originalExtraInfo). - toUpperCase(); - scrubbed.append("opt extra-info-digest " + haveExtraInfo - + "\n"); - } - } else if (line.startsWith("reject ") - || line.startsWith("accept ")) { - if (!contactWritten) { - scrubbed.append("contact nobody at example dot " + country - + "\n"); - contactWritten = true; - } - original.append(line + "\n"); - scrubbed.append(line + "\n"); - } else if (line.startsWith("platform ") - || line.startsWith("opt protocols ") - || line.startsWith("published ") - || line.startsWith("uptime ") - || line.startsWith("bandwidth ") - || line.startsWith("uptime ") - || line.startsWith("opt hibernating ") - || line.equals("opt hidden-service-dir") - || line.equals("opt caches-extra-info")) { - original.append(line + "\n"); - scrubbed.append(line + "\n"); - } else if (line.startsWith("family ")) { - StringBuilder familyLine = new StringBuilder("family"); - for (String s : line.substring(7).split(" ")) { - if (s.startsWith("$")) - familyLine.append(" $" + DigestUtils.shaHex(Hex.decodeHex( - s.substring(1).toCharArray())).toUpperCase()); - else - familyLine.append(" " + s); - } - original.append(line + "\n"); - scrubbed.append(familyLine.toString() + "\n"); - } else if (line.startsWith("@purpose ")) { - continue; - } else if (line.startsWith("-----BEGIN ") - || line.equals("onion-key") || line.equals("signing-key")) { - skipCrypto = true; - original.append(line + "\n"); - } else if (line.startsWith("-----END ")) { - skipCrypto = false; - original.append(line + "\n"); - } else { - System.out.println("Unrecognized line '" + line + "'. Exiting"); - System.exit(1); - } - } - br.close(); - } - System.out.println("\nWrote " + writtenDescriptors.size() - + " bridge descriptors. While parsing, we found that we parsed " - + found + " extra-info identifiers before, but are missing " - + notfound + ". (The number of missing identifiers should be " - + "significantly smaller.)"); - - System.out.print("Parsing network statuses"); - Set<File> referencedDescriptors = new HashSet<File>(); - parsed = notfound = found = 0; - for (File file : statuses) { - if (parsed++ > statuses.size() / days) { - System.out.print("."); - parsed = 0; - } - if (!file.getParent().substring(file.getParent(). - indexOf("from-tonga-")).startsWith(currentYearAndMonth)) { - continue; - } - BufferedReader br = new BufferedReader(new FileReader(file)); - String line = null; - StringBuilder scrubbed = new StringBuilder(); - boolean addSLine = false; - while ((line = br.readLine()) != null) { - if (line.startsWith("r ")) { - String[] parts = line.split(" "); - String bridgeIdentity = parts[2] + "=="; - String hexBridgeIdentity = Hex.encodeHexString( - Base64.decodeBase64(bridgeIdentity)); - String hashedBridgeIdentity2 = Base64.encodeBase64String( - DigestUtils.sha(Base64.decodeBase64(bridgeIdentity))). - replace("=", ""); - String hashedBridgeIdentity = Base64.encodeBase64String( - DigestUtils.sha(Base64.decodeBase64(bridgeIdentity))). - substring(0, 27); - String descIdentifier = parts[3] + "=="; - String hexDescIdentifier = Hex.encodeHexString( - Base64.decodeBase64(descIdentifier)); - if (!descriptorMapping.containsKey(hexDescIdentifier)) { - notfound++; - addSLine = false; - } else { - found++; - String refDesc = descriptorMapping.get(hexDescIdentifier). - toLowerCase(); - File descriptorFile = new File(outDir + File.separator - + "descriptors" + File.separator + refDesc.charAt(0) - + File.separator + refDesc.charAt(1) + File.separator - + refDesc); - if (!descriptorFile.exists()) { - System.out.println("Descriptor file '" - + descriptorFile.getAbsolutePath() + "' does not exist."); - } - String replacementDescIdentifier = Base64.encodeBase64String( - Hex.decodeHex(descriptorMapping.get(hexDescIdentifier). - toCharArray())).substring(0, 27); - scrubbed.append("r Unnamed " + hashedBridgeIdentity - + " " + replacementDescIdentifier + " " + parts[4] + " " - + parts[5] + " 127.0.0.1 " + parts[7] + " " + parts[8] - + "\n"); - addSLine = true; - referencedDescriptors.add(descriptorFile); - } - } else if (line.startsWith("s ")) { - if (addSLine) { - scrubbed.append(line + "\n"); - } - } else { - System.out.println("Unknown line: " + line); - System.exit(1); - } - } - String timeString = file.getParent().substring(file.getParent(). - indexOf("from-tonga-") + 11); - String[] date = timeString.substring(0, 10).split("-"); - String time = timeString.substring(11, 17); - File dir = new File(outDir + File.separator + "statuses" - + File.separator + date[0] + File.separator + date[1] - + File.separator + date[2] + File.separator); - dir.mkdirs(); - File out = new File(dir.getAbsolutePath() + File.separator + date[0] - + date[1] + date[2] + "-" + time + "-" - + "4A0CCD2DDC7995083D73F5D667100C8A5831F16D"); - if (!out.exists()) { - BufferedWriter bw3 = new BufferedWriter(new FileWriter(out)); - bw3.write(scrubbed.toString()); - bw3.close(); - } - } - System.out.println("\nWhile parsing, we found that we parsed " - + found + " bridge descriptors before, but are missing " - + notfound + ". (The number of missing identifiers should be " - + "significantly smaller.)"); - - Set<File> deleteFromReferencedExtraInfos = new HashSet<File>(); - for (File e : referencedExtraInfos.keySet()) { - if (!referencedDescriptors.contains(e)) { - deleteFromReferencedExtraInfos.add(e); - } - } - for (File e : deleteFromReferencedExtraInfos) { - referencedExtraInfos.remove(e); - } - SortedSet<File> deleteDescriptors = new TreeSet<File>(); - for (File e : writtenDescriptors) { - if (!referencedDescriptors.contains(e)) { - deleteDescriptors.add(e); - } - } - SortedSet<File> deleteExtraInfos = new TreeSet<File>(); - for (File e : writtenExtrainfos) { - if (!referencedExtraInfos.values().contains(e)) { - deleteExtraInfos.add(e); - } - } - System.out.println("Deleting " + deleteDescriptors.size() - + " unreferenced bridge descriptors and " - + deleteExtraInfos.size() + " extra-info descriptors (keeping " - + (writtenDescriptors.size() - deleteDescriptors.size()) - + " bridge descriptors and " + (writtenExtrainfos.size() - - deleteExtraInfos.size()) + " extra-info descriptors)."); - for (File e : deleteDescriptors) - e.delete(); - for (File e : deleteExtraInfos) - e.delete(); - - long finished = System.currentTimeMillis(); - System.out.println("Processing took " + ((finished - started) / 1000) - + " seconds."); - } -} - diff --git a/bridge-desc-sanitizer/HOWTO b/bridge-desc-sanitizer/HOWTO deleted file mode 100644 index 418dc5f..0000000 --- a/bridge-desc-sanitizer/HOWTO +++ /dev/null @@ -1,124 +0,0 @@ -Bridge descriptor sanitizer - ---------------------------------------------------------------------------- - - THIS SOFTWARE IS DEPRECATED ! - -There is at least one known issue in this software: Bridge IP addresses -contained in reject lines are not rewritten as 127.0.0.1. There may be -further issues. Please use the bridge descriptor sanitizer that is part -of metrics-db instead of this software: - - https://gitweb.torproject.org/metrics-db.git - ---------------------------------------------------------------------------- - -Introduction: - -The bridge authority Tonga keeps a list of bridges in order to serve bridge -addresses and descriptors to its clients. Every half hour, Tonga copies a -snapshot of the known bridge descriptors to moria where these descriptors -are archived for later statistical analysis. As a guiding principle, the -Tor project makes all data that it uses for statistical analysis available -to the interested public, in order to maximize transparency towards the -community. However, the bridge descriptors contain the IP addresses and -other contact information of bridges that must not be made public, or the -purpose of bridges as non-public entry points into the Tor network would be -obsolete. This script takes the half-hourly snapshots as input, removes all -possibly sensitive information from the descriptors, and puts out the -sanitized bridge descriptors that are safe to be published. - ---------------------------------------------------------------------------- - -Processing steps: - -The following steps are taken to remove all potentially sensitive -information from the bridge descriptors while keeping them useful for -statistical analysis. - -1. Replace the bridge identity with its SHA1 value - - Clients can request a bridge's current descriptor by sending its - identity string to the bridge authority. This is a feature to make - bridges on dynamic IP addresses useful. Therefore, the original - identities (and anything that could be used to derive them) need to be - removed from the descriptors. The bridge identity is replaced with its - SHA1 hash value. The idea is to have a consistent replacement that - remains stable over months or even years (without keeping a secret for a - keyed hash function). - -2. Remove all cryptographic keys and signatures - - It would be straightforward to learn about the bridge identity from the - bridge's public key. Replacing keys by newly generated ones seemed to be - unnecessary (and would involve keeping a state over months/years), so - that all cryptographic objects have simply been removed. - -3. Replace IP address with 127.0.0.1 - - Of course, the IP address needs to be removed, too. However, the IP - address is resolved to a country code first and the result written to - the contact line as "somebody at example dot de" for Germany, etc. The - ports are kept unchanged though. - -4. Replace contact information - - If there is contact information in a descriptor, the contact line is - changed to "somebody at ...". If there is none, a contact line is added - saying "nobody at ..." in order to put in the country code. - -5. Replace nickname with Unnamed - - The bridge nicknames might give hints on the location of the bridge if - chosen without care; e.g. a bridge nickname might be very similar to the - operators' relay nicknames which might be located on adjacent IP - addresses. All bridge nicknames are therefore replaced with the string - Unnamed. - -Note that these processing steps only prevent people from learning about -new bridge locations. People who already know a bridge identity or location -can easily learn more about this bridge from the sanitized descriptors. -This is useful for statistical analysis, e.g. to filter out bridges that -have been running as relays before. - ---------------------------------------------------------------------------- - -Quick Start: - -The following steps are necessary to process the half-hourly snapshots as -collected by moria: - -- Install Java 5 or higher. - -- Download Apache Commons Codec 1.4 or higher for Base 64 and hex encoding - from http://commons.apache.org/codec/ and place the .jar (in the - following assumed to be commons-codec-1.4.jar) in the same directory as - this HOWTO file. - -- Copy the half-hourly snapshots named from-tonga-YYYY-MM-DDThhmmssZ.tar.gz - in a directory called data/ in the same directory as this HOWTO file. - -- Run ./extract-bridges.sh to extract the half-hourly snapshots in data/ - to separate directories in the newly created subdirectory in/ . - -- Copy the geoip.txt from the Tor sources (from /src/config/) to the same - directory as this HOWTO file. - -- Compile the Java class using - - $ javac -cp commons-codec-1.4.jar ConvertBridgeDescs.java - -- Run the script, providing it with the parameters it needs: - - java -cp .:commons-codec-1.4.jar ConvertBridgeDescs - <input directory> <geoip.txt file> - <YYYY> <MM> <output directory> - - Note that YYYY and MM specify the month that shall be processed. The other - descriptors in the input directory are ignored. - - A sample invocation might be: - - $ java -cp .:commons-codec-1.4.jar ConvertBridgeDescs in/ geoip.txt - 2008 10 out/ - diff --git a/bridge-desc-sanitizer/LICENSE b/bridge-desc-sanitizer/LICENSE deleted file mode 100644 index ad177ea..0000000 --- a/bridge-desc-sanitizer/LICENSE +++ /dev/null @@ -1,30 +0,0 @@ -Copyright 2009-2010 The Tor Project - -Redistribution and use in source and binary forms, with or without -modification, are permitted provided that the following conditions are -met: - -* Redistributions of source code must retain the above copyright - notice, this list of conditions and the following disclaimer. - -* Redistributions in binary form must reproduce the above - copyright notice, this list of conditions and the following disclaimer - in the documentation and/or other materials provided with the - distribution. - -* Neither the names of the copyright owners nor the names of its - contributors may be used to endorse or promote products derived from - this software without specific prior written permission. - -THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS -"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT -LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR -A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT -OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, -SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT -LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, -DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY -THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT -(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE -OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - diff --git a/bridge-desc-sanitizer/extract-bridges.sh b/bridge-desc-sanitizer/extract-bridges.sh deleted file mode 100755 index 5f412c3..0000000 --- a/bridge-desc-sanitizer/extract-bridges.sh +++ /dev/null @@ -1,8 +0,0 @@ -#!/bin/bash -mkdir "in/" -for i in `ls data/ | cut -c 1-29` -do -mkdir "in/"$i -tar -C "in/"$i -xf "data/"$i".tar.gz" -done -

1 0

[torspec/master] ipv6-plan patch from ioerror
by nickm＠torproject.org 02 Mar '11

02 Mar '11

commit 2cb38a6ef43fd3b5de7508622a815d8810275e0b Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Mar 2 11:29:41 2011 -0500 ipv6-plan patch from ioerror --- proposals/ideas/xxx-ipv6-plan.txt | 21 +++++++++++++++------ 1 files changed, 15 insertions(+), 6 deletions(-) diff --git a/proposals/ideas/xxx-ipv6-plan.txt b/proposals/ideas/xxx-ipv6-plan.txt index e9ffb10..12bd4d4 100644 --- a/proposals/ideas/xxx-ipv6-plan.txt +++ b/proposals/ideas/xxx-ipv6-plan.txt @@ -18,13 +18,16 @@ Motivation: What needs to change: - Tor uses the Internet in many ways. There four main ways that + Tor uses the Internet in many ways. There are four main ways that will need to change for IPv6 support, from most urgent to least urgent. + 0. An unknown laundry list of issues that will supersede all other + listed issues in this list. + 1. Tor must allow connections from IPv6-only clients. (Currently, - routers do not listen on IPv6 addresses, and can't advertise - that they support IPv6 addresses, so clients can't learn that + routers and bridges do not listen on IPv6 addresses, and can't + advertise that they support IPv6 addresses, so clients can't learn that they do.) 2. Tor must transport IPv6 traffic and IPv6-related DNS traffic. @@ -35,8 +38,11 @@ What needs to change: 3. Tor must allow nodes to connect to one another over IPv6. Allowing IPv6-only clients is the most important, since unless we - do, these unable to connect to Tor at all. Next most - important is to allow IPv6 XXXX + do, these clients will be unable to connect to Tor at all. Next most + important is to support IPv6 DNS related dependencies and exiting to IPv6 + services. Finally, allowing Tor nodes to support a dual stack of both IPv4 + and IPv6 for interconnection seems like a reasonable step towards a fully + hybrid v4/v6 Tor network. Designs that we will need to do: @@ -51,13 +57,16 @@ Designs that we will need to do: for places that might assume that IPs are a scarce resource. For example, clients assume that any two routers occupying an IPv4 /16 network are "too close" topologically to be used in the same - circuit, and the bridgedb https distributor assumes that hopping + circuit, and the bridgedb HTTPS distributor assumes that hopping from one /24 to another takes a little effort for most clients. The directory authorities assume that blacklisting an IP is an okay response to a bad router at that address. These and other places will needed instead more appropriate notions of "closeness" and "similarity". + We'll want to consider geographic and political boundaries rather than + purely mathematical notions such as the size of network blocks. + We'll need a way to advertise IPv6 bridges, and to use them. For transporting IPv6-only traffic, we have another accepted design

1 0

[torspec/master] tweak ipv6 plan more
by nickm＠torproject.org 02 Mar '11

02 Mar '11

commit 2fa1377bdc200cecd0c36ba4104f3da156ba1ea8 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Mar 2 12:21:56 2011 -0500 tweak ipv6 plan more --- proposals/ideas/xxx-ipv6-plan.txt | 22 +++++++++++----------- 1 files changed, 11 insertions(+), 11 deletions(-) diff --git a/proposals/ideas/xxx-ipv6-plan.txt b/proposals/ideas/xxx-ipv6-plan.txt index 12bd4d4..73a21f1 100644 --- a/proposals/ideas/xxx-ipv6-plan.txt +++ b/proposals/ideas/xxx-ipv6-plan.txt @@ -18,17 +18,14 @@ Motivation: What needs to change: - Tor uses the Internet in many ways. There are four main ways that + Tor uses the Internet in many ways. There are three main ways that will need to change for IPv6 support, from most urgent to least urgent. - 0. An unknown laundry list of issues that will supersede all other - listed issues in this list. - 1. Tor must allow connections from IPv6-only clients. (Currently, routers and bridges do not listen on IPv6 addresses, and can't - advertise that they support IPv6 addresses, so clients can't learn that - they do.) + advertise that they support IPv6 addresses, so clients can't + learn that they do.) 2. Tor must transport IPv6 traffic and IPv6-related DNS traffic. (Currently, Tor only allows BEGIN cells to ask for connections @@ -38,11 +35,14 @@ What needs to change: 3. Tor must allow nodes to connect to one another over IPv6. Allowing IPv6-only clients is the most important, since unless we - do, these clients will be unable to connect to Tor at all. Next most - important is to support IPv6 DNS related dependencies and exiting to IPv6 - services. Finally, allowing Tor nodes to support a dual stack of both IPv4 - and IPv6 for interconnection seems like a reasonable step towards a fully - hybrid v4/v6 Tor network. + do, these clients will be unable to connect to Tor at all. Next + most important is to support IPv6 DNS related dependencies and + exiting to IPv6 services. Finally, allowing Tor nodes to support a + dual stack of both IPv4 and IPv6 for interconnection seems like a + reasonable step towards a fully hybrid v4/v6 Tor network. + + Of course, more issues may be discovered as we develop solutions for these + issues, some of which may need to take priority. Designs that we will need to do:

1 0

← Newer
1
...
62
63
64
65
66
67
68
69
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits March 2011