Re: xxx-draft-spec-for-TLS-normalization.txt

[Jacob Appelbaum <jacob@xxxxxxxxxxxxx>]

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