xxx-draft-spec-for-TLS-normalization.txt
Jacob Appelbaum
jacob at appelbaum.net
Wed Feb 2 17:18:09 UTC 2011
On 01/31/2011 04:48 PM, Chris Palmer wrote:
> 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)
That's good - that seems to weight putting (current relay) IP addresses
into certificates.
>
> 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)
This also seems to suggest that any IP address we choose may be
reasonable - perhaps we can mix it up with RFC1918 and likely routed IP
addresses?
>
>> 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)
That's wacky (the negative one) but not too unexpected.
>
> 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)
That's likely because some CAs but not all CAs will insert random data
into the serial number field as a method of injecting entropy into
issued certificates. Can you dump the CA names with those?
>
>
>>> 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)
>
It does seem that 1024 bit certs are the most popular and 2048 is likely
the next reasonable jump.
> 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.
>
>
Awesome. Thanks for your input Chris!
All the best,
Jake
More information about the tor-dev
mailing list