7.10 Key分发系统
-
7.10.4 高级话题
-
时钟同步的考虑
既然服务本身依赖了时钟，不论服务器，客户端，都应该使用ntp同步时钟。这里讨论时钟误差的容忍限度。
1. 服务器时钟不同步, 理论上, masterKey寿命变为配置寿命减去机器间时钟差异。 也就是机器间masterKey寿命区间的交集。 非常长的配置寿命有助于容忍时钟的不同步。
2. 客户端时钟不同步，nonce由系统时间除以配置精度取整获得。(timestamp,nonce,group)组合而成的keyIdent作为客户端cache的key, 不同步的结果即是cache中(timestamp,nonce)的项变多, 换言之，客户端时钟不同步将导致客户端cache使用量变大，网络请求变多。
-
masterKey的分发
masterKey在P2P网络中分发。因为应用环境的不同，所以采用修改过的Kademlia算法。因为没有Kademlia参数的现实评估结果，所以这里涉及到许多可以配置的系统参数。
1. 使用HTTPS代替UDP，保证服务器间的严格认证。
2. DHT查找过程中的协议交互, 附带交换服务器间masterKey。 查找发起服务器发送自己节点信息的同时发送已知的timestamp集合。 接收服务器返回邻居信息的同时, 通过diff操作, 附带返回对方没有的masterKey集合, 以及自己缺少的timestamp。 查找发起服务器解析返回的邻居信息, merge返回的masterKey集合, 向对方upload缺少的mastreKey集合。
3. Node地址长度通过limax.p2p.DHTAddress.HASH决定，默认配置SHA-256
4. 单个k-Bucket尺寸通过limax.p2p.Neighbors.BUCKET_SIZE决定，参考BT，默认配置为8。
5. k-Bucket更新方法不同于Kademlia, 以距离优先为标准, 因为服务器不需要过多考虑偶尔在线的问题。新加入k-Bucket的node, 设置PING定时器, 如果node已经存在, cancel之前的定时器。k-Bucket溢出, 删除最后一个条目，cancel对应的定时器。PING采用连接HTTPS端口的方式实现, PING定时器周期由limax.p2p.Neighbors.ENTRY_AGE_MAX决定，默认20分钟。PING超时由limax.key.KeyServer.NETWORK_TIMEOUT决定，默认3秒。
6. Refresh做2次查找，查找自己，查找一个随机地址。Refresh周期由limax.key.KeyServer.NEIGHBORS_REFRESH_PERIOD决定，默认配置20分钟。
7. 查找动作使用的本地初始集合大小由limax.key.P2pHandler.BASE_LIMIT决定, 默认8。 被查找的服务器返回集合大小由limax.key.P2pHandler.REPORT_SIZE决定, 默认16。 查找并行度由limax.key.P2pHandler.CONCURRENCY_LEVEL决定, 默认64。 期望的查找结果集最大尺寸由limax.key.P2pHandler.ANTICIPANTION决定，默认8。
8. 如果查找结果数量无法满足预期，则从配置文件中master属性配置的服务器开始再执行一轮查找。这些配置指定服务器类似于BT环境中的超级种子，随着邻居表逐渐增大，可以预期这些超级种子被访问的频率逐渐降低。
9. 发布服务器向邻居表中所有地址，所有master配置属性指定的地址分发masterKey。
10. 既然refresh频率为20分钟，每次refresh在本地选择8个最近node，也就是不到4层，算作3层（Kademlia使用基于地址前缀的二叉树划分地址空间），地址算法使用SHA-256，总共256层，256 / 3 * 20 / 60 / 24 = 1.19天，作最保守的估计masterKey同步到最远端需要2天，配置文件中publishPeriod属性配置为3天。正因为如此，服务器优先使用第二新的masterKey提供服务，严格来说，整个网络的启动至少需要提供2天的初始静默期。实际运营，通过指定合适的master配置，这个问题就不再重要了。
11. 正确处理NAT。实现上DHTAddress关联InetSocketAddress表示为NetworkID，InetSocketAddress作为查找时的secondaryKey。NAT内部服务器如果没有分配外部IP，应该适当提高Refresh频率，配置较多的master。
-
多个masterKey分发服务器
1. 理论上分发服务器只能有一个。
2. 实现上，分发服务器启动时，向邻居服务器同步所有masterKey，记录最新masterKey的timestamp，然后启动分发定时器。定时器到期时检查当前最新timestamp是否与之前的记录相等，如果相等，执行分发；不相等，不执行，最后依据当前最新timestamp启动下一轮定时。
3. 从实现来看，启用多分发服务器需要满足两个条件。其一，分发服务器间网络通讯良好，分发服务器集共享master配置，包括所有的分发服务器地址，这样就保证了最新生成的masterKey能立即同步。其二，分发服务器的启动设定一个时间差，保证其中一台服务器的分发动作，发送到其它服务器，设置它们的最新timestamp之前，它们的分发定时器没有到期。
4. 实际上，timestamp的精度为毫秒，就算两台服务器同时分发，生成的timestamp碰撞的概率也非常小，顶多让所有服务器多记录一个masterKey。
-
不使用P2P的资源存取模型
1. 理论上，可以通过timestamp在P2P网络中搜索对应的masterKey，而不必等待一个较长的发布周期。事实上这不可行。
2. 搜索是一个高开销行为，恶意客户端可以伪造timestamp向服务器发起请求，如果提供搜索就给这些恶意客户端提供了攻击P2P网络的机会。
3. 如果要避免攻击，就只能给timestamp签名，服务器在发起搜索操作之前作一次过滤，这样做需要一个签名Key，整个服务网络本身就是为了提供Key而存在，这个问题就变成了一个循环。
-
孤立服务器，孤立网络
1. 脱离P2P网络的服务器称为孤立服务器，与分发服务器网络断开的网络称为孤立网络。
2. 孤立服务器，或者孤立网络中的服务器可以为客户端生成key, 但有可能不能还原客户端访问非孤立网络中服务器后生成的keyIdent, 原因很简单, 新的timestamp关联的masterKey没有收到。
3. 孤立服务器可以通过日志确认，“Neighbors save NNN entries”记录条目中NNN = 0，应该怀疑服务器已经孤立。
4. 现实环境中，证书不能及时renew，过期之后可能导致服务器孤立。事实上就算签署30天短期服务器证书，80%寿命开始renew，也就是说有6天的时间可以renew，每小时重试一次，一共可以重试144次，过期的情况几乎不可能发生，除非CA 6天不在线。
5. 服务器证书被CA回收，这种情况下，应该关闭服务器。
6. 孤立网络可以通过日志确认，“MasterKeyContainer CurrentDigester”记录了masterKey更新事件，两条这样的日志之间的时间差大致等于发布周期，如果该超出2倍发布周期的该记录还没有出现，意味着该服务器及其邻居都处于孤立网络内。
7. 现实环境中，除非大范围网络故障，孤立网络不会存在，配置文件中使用比较大的publishPeriod可以增加网络故障耐受容限。
-
客户端的高可用性
1. 较大的nonce设置可以有效利用cache，大大减少网络访问。
2. 尽管客户端不加入服务器的P2P网络，但是也提供同样级别的高可用实现，有效减少网络失败。
3. 设定网络访问优先级。证书提供的DNSName地址具有低优先级；KeyAllocator.setHost设置的地址具有中优先级；每次向服务器发起Key请求，服务器会连带返回一个随机的服务器地址列表，该列表具有高优先级，客户端测量这些地址的RTT（limax.key.KeyAllocator.TIMEOUT决定的超时限度内, 超过该限度的服务器直接放弃）。后续Key请求按RTT排序的高优先级列表, 中优先级列表，低优先级列表，逐一访问，直到成功，失败的IP从高优先级列表中删除。
4. 证书提供的DNSName与KeyAllocator.setHost提供的域名，映射的IP地址可能改变，客户端定期解析这些地址，limax.key.ServerEvaluate.DOMAIN_UPDATE设置了解析频率，默认5分钟。
5. 服务器返回的地址列表，每次都可能更新，实现上选择RTT最小的8个IP提供使用，可以通过系统属性limax.key.ServerEvaluate.DYNAMIC_SERVERS修改。
6. 服务器提供给客户端的最大随机地址列表个数由limax.key.P2pHandler.ANTICIPANTION决定，默认8个。
7. limax.key.KeyAllocator.ISOLATED_SERVER_THRESHOLD默认为0，该属性提供了孤立服务器过滤能力，如果服务器返回的随机列表个数小于该值，则认为该服务器不可靠，继续访问下一IP。小心配置该值，绝不能大于limax.key.P2pHandler.ANTICIPANTION。
-
安全考虑
1. 服务器使用HTTPS交互，接收请求一方验证对方的证书的Subject中CN是否与自己证书相同，同时验证Issuer名字是否相同。（这里不能比较CA证书，因为CA自身可能renew，CA的renew规则要求Subject不能改变，见上一章《PKIX支持》）
2. 每一台接入网络的服务器都必须保证私钥安全，任何一台服务器私钥被盗都可能导致masterKey被盗，危害整个网络，可以考虑采用硬件方式，足够的冗余保证了硬件失效可接受。
3. 配置文件中revocationCheckerOptions属性不要选择DISABLE，CA正常运转的情况下，至少考虑使用SOFT_FAIL。
-
运营维护
1. Key分发网络应该看作是与CA同级别的基础设施，直接由CA维护是最合理的选择。
2. 配置文件中，master属性可以配置成层次结构或者网状结构（环不是问题），这样做的实质是把P2P网络从动态网络，局部调整为静态，可以进一步提高健壮性。（见《多个masterKey分发服务器》一节）
3. 关注服务器孤立，网络孤立的情况。
-
Key分发系统本质是key的离线协商
1. Key协商是系统间安全通讯的基础。
2. 常见安全协议例如SSL，必须在通讯双方同时在线的情况下完成key协商。
3. 在线协商不可能覆盖所有应用场景。
4. Limax提供的Key分发系统通过提供一个能够保证持续在线的第三方机构来实现客户之间的离线协商。
5. 从建立信任的角度看，可信第三方是保障安全的前提，这一点和CA完全一致。
-