mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-24 04:13:28 +01:00
latest revision of cert normalization spec
This commit is contained in:
Jacob Appelbaum
Nick Mathewson
parent
0a69355794
commit
2f36489422
@ -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.
|
||||
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.
|
||||
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
|
||||
|
||||
Loading…
Reference in New Issue
Block a user