commit 2f3648942202ca9d965344b8d2128a7a7b2056fb Author: Jacob Appelbaum jacob@appelbaum.net Date: Mon Feb 21 13:45:57 2011 -0500
latest revision of cert normalization spec --- .../ideas/xxx-draft-spec-for-TLS-normalization.txt | 134 ++++++++++++-------- 1 files changed, 82 insertions(+), 52 deletions(-)
diff --git a/doc/spec/proposals/ideas/xxx-draft-spec-for-TLS-normalization.txt b/doc/spec/proposals/ideas/xxx-draft-spec-for-TLS-normalization.txt index 14546df..16484e6 100644 --- a/doc/spec/proposals/ideas/xxx-draft-spec-for-TLS-normalization.txt +++ b/doc/spec/proposals/ideas/xxx-draft-spec-for-TLS-normalization.txt @@ -1,6 +1,6 @@ Filename: xxx-draft-spec-for-TLS-normalization.txt Title: Draft spec for TLS certificate and handshake normalization -Author: Jacob Appelbaum +Author: Jacob Appelbaum, Gladys Shufflebottom Created: 16-Feb-2011 Status: Draft
@@ -94,32 +94,9 @@ An example of OpenSSL’s asn1parse over a typical Tor certificate: 308:d=2 hl=2 l= 0 prim: NULL 310:d=1 hl=3 l= 129 prim: BIT STRING
-I propose that the commonName field be generated to match a specific property -of the server in question. It is reasonable to set the commonName element to -match either the hostname of the relay, the detected IP address of the relay, -or for the relay operator to override certificate generation entirely by -loading a custom certificate. For custom certificates, see the Custom -Certificates section. - -I propose that the value for the commonName field be populated with the -fully qualified host name as detected by reverse and forward resolution of the -IP address of the relay. If the host name is in the DNS, this host name should -be set as the common name. When forward and reverse DNS is not available, I -propose that the IP address alone be used. - -The commonName field for the issuer should be set to known issuer names, -random words or omitted entirely. - -Since some host names may themselves trigger censorship keyword filters, -it may be reasonable to provide an option to override the defaults and -force certain values in the commonName field. - -Considerations for commonName normalization - -Any host name supplied for the commonName field should resolve - even if it -does not resolve to the IP address of the relay[0]. If the commonName field -does include an IP address, it should be the current IP address of the relay as -seen by other Internet hosts. +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
@@ -127,25 +104,35 @@ 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 truncated to a length chosen at -random within a finite set of bounds. The length of the serial number should be -chosen randomly at certificate generation time; it should be bound between the -most commonly found bit lengths[1] in the wild. 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. I propose that we choose a -byte length that is either 3, 4, or 16 bytes at certificate generation time. - -This randomly generated 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. +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. +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
@@ -190,16 +177,6 @@ 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.
-Other certificate fields - -It may be advantageous to also generate values for the O, L, ST, C, and OU -certificate fields. The C and ST fields may be populated from GeoIP information -that is already available to Tor to reflect a plausible geographic location -for the OR. The other fields should contain some semblance of a word or -grouping of words. It has been suggested[2] that we should look to guides for -certificate generation that use OpenSSL as a reasonable baseline for -understanding these fields, as well as other certificate properties. - Certificate dating and validity issues
TLS certificates found in the wild are generally found to be long-lived; @@ -231,6 +208,58 @@ 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 @@ -308,6 +337,7 @@ 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