commit 3a85a3afac30dc8a2433a6e06508ac57c964f820 Author: Jacob Appelbaum <jacob@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