xxx-draft-spec-for-TLS-normalization.txt
Chris Palmer
chris at eff.org
Tue Feb 1 00:48:33 UTC 2011
On Jan 31, 2011, at 3:59 PM, Nick Mathewson wrote:
> I'm not sure that an IP address is better than a random hostname. Do
> any CAs issue certs where the CN is an IP address? Do many
> self-signed certificates actually look that way?
>
> If the answers are "no" and "not many", then we'll probably be better
> off with randomly generated hostnames when we can't find a real
> hostname to use.
The answer is "yes and yes".
valid_names is CA-validated CNs from observed certs that browsers would consider valid:
mysql> select name from valid_names where name rlike '^([0-9]{1,3}\\.){3}[0-9]{1,3}$' limit 10 offset 1000;
+-----------------+
| name |
+-----------------+
| 213.221.122.163 |
| 213.222.193.229 |
| 213.23.117.165 |
| 213.23.120.186 |
| 213.239.192.102 |
| 213.239.193.166 |
| 213.239.223.66 |
| 213.239.223.68 |
| 213.239.223.70 |
| 213.239.223.72 |
+-----------------+
10 rows in set (1.03 sec)
all_names is all names, not just names from valid certificates:
mysql> select name from all_names where name rlike '^([0-9]{1,3}\\.){3}[0-9]{1,3}$' limit 10 offset 10000;
+-------------+
| name |
+-------------+
| 10.1.28.254 |
| 10.1.29.4 |
| 10.1.3.1 |
| 10.1.3.1 |
| 10.1.3.1 |
| 10.1.3.1 |
| 10.1.3.1 |
| 10.1.3.1 |
| 10.1.3.1 |
| 10.1.3.1 |
+-------------+
10 rows in set (3.28 sec)
> There are two certificate profiles to imitate here: self-signed and
> CA-issued. For self-signed ones, both DNs typically match, I think.
> This is worth checking too
I don't know, but I suspect, that mimicking a typical self-signed cert for an Apache HTTPS server install will blend in well. Certainly, there are many more self-signed certs than CA-signed certs. It might even work just fine to set the CN to an RFC 1918 address, rather than going to the trouble to sign the true publically-visible/-routable IP. There are TON of 10.* IPs in here.
>> Certificate serial numbers
>>
> I'd want to back off here to see what certificates look like in the
> wild. Do they look random? Do they look like timestamps? Do they
> increase sequentially? Are they typically small for self-signed
> certificates?
Here are some examples from all_certs; you can see that they are kind of wackadoodle:
mysql> select `Serial Number` from all_certs limit 10 offset 10000;
+-------------------------------------------------+
| Serial Number |
+-------------------------------------------------+
| 0a:bb:68:a0:59:18:bf:41:b9:e0:ca:77:78:1e:81:d8 |
| 945343 (0xe6cbf) |
| 2 (0x2) |
| 1129306560 (0x434fd9c0) |
| c0:21:49:06:50:74:85:9e:c0:26:c0:82:38:0c:52:d9 |
| 33:e4:41:16:d4:92:b0:db:cc:5f:a4:48:cd:8a:15:67 |
| 04:37:f8:4c:1b:8f:91 |
| 0 (0x0) |
| 1171916762 (0x45da07da) |
| 31:47:86:bf:68 |
+-------------------------------------------------+
10 rows in set (0.59 sec)
mysql> select `Serial Number` from all_certs limit 10 offset 100;
+-------------------------------------------------+
| Serial Number |
+-------------------------------------------------+
| 269 (0x10d) |
| 1 (0x1) |
| 23:2d:97:f0:0f:2a:44:85:e0:4c:40:7a:81:2a:bd:57 |
| 1879052797 (0x700011fd) |
| 1879051733 (0x70000dd5) |
| 7 (0x7) |
| 1158643580 (0x450f7f7c) |
| 0 (0x0) |
| a9:4f:56:e5:27:0a:c2:7c |
| -1606448784 (-0x5fc07690) |
+-------------------------------------------------+
10 rows in set (0.01 sec)
(love that negative one)
Serial numbers for valid_certs are more uniform and random-looking:
mysql> select `Serial Number` from valid_certs limit 10 offset 10000;
+-------------------------------------------------+
| Serial Number |
+-------------------------------------------------+
| a1:ea:33:78:c4:80:ee:b1:f7:27:5a:0b:60:c7:b0:ef |
| 03:fd:e4:a0:4a:8e:6f:21:e8:03:69:38:7f:66:66:5a |
| 3b:b0:dd:a9:4a:db:c9:e7:c2:03:69:5c:f6:8c:ba:35 |
| 6d:9f:45:41:fe:80:9a:ea:75:bb:6a:25:45:e6:ec:c7 |
| a7:27:09:e9:2d:bb:ef:72:06:fc:78:b4:e5:4f:5d:31 |
| 1d:c3:ea:d4:8a:96:bb:95:0c:5e:47:3a:ae:68:ce:37 |
| 7c:4c:e4:45:bf:e2:96:63:0a:8e:1f:62:8d:0b:df:6f |
| 2b:33:c8:dc:ff:8a:e9:a3:99:65:4d:32:1a:90:f6:97 |
| 1260410972 (0x4b20585c) |
| 04:72:74:a1:f2:a1:fc |
+-------------------------------------------------+
10 rows in set (0.13 sec)
>> Practical key size
>
> Possibly; we should get data on this before we guess. Also, as we
> start to support longer sizes, we may want a way to advertise "maximum
> allowed keysize" in the consensus to keep some wiseguy from making a
> 16384-bit key as a DOS attack.
I suspect a serious inquiry will find that the sizes between 1024 and 2048 are much less common than 1024 and 2048. Here is more anecdotal entertainment for you:
mysql> select RSA_Modulus_Bits from all_certs limit 10;
+------------------+
| RSA_Modulus_Bits |
+------------------+
| 1024 |
| 2048 |
| 2048 |
| 1024 |
| 768 |
| 1024 |
| 2048 |
| 2048 |
| 1024 |
| 2048 |
+------------------+
10 rows in set (0.00 sec)
mysql> select RSA_Modulus_Bits from all_certs limit 10 offset 3000;
+------------------+
| RSA_Modulus_Bits |
+------------------+
| 1024 |
| 1024 |
| 1024 |
| 1024 |
| 1024 |
| 1024 |
| 1024 |
| 1024 |
| 1024 |
| 1024 |
+------------------+
10 rows in set (0.05 sec)
Anyway, I think a serious drive around in the database would help you guys nail down these practical concerns. Overall, I think this "normalize our OR certs" effort makes good sense.
--
Chris Palmer
Technology Director, Electronic Frontier Foundation
More information about the tor-dev
mailing list