mozilla的安全架构

mozilla在安全方面主要分为三大块：1.SSL协议的实现；2.Crypto库的实现；3.PKCS#11的实现最顶层是ssl的实现，和openssl不同，mozilla是自上而下设计的，因此mozilla并没有抽象出诸如BIO或者EVP之类的通用机制，可以它实现了一个PRFileDesc结构体，和BIO是很类似的；涉及到安全的实现就是2和3了，其中3定义了接口，2给与了软实现，当然你可以加载plugin使用硬件实现。三者合一形成了mozilla的安全架构。
     有几个重要的结构体先了解一下：sslSocketStr结构和openssl中的ssl_st结构体非常类似：
struct sslSocketStr {
        PRFileDesc *    fd;  //一个文件IO分发表，类似linux内核的file_operations，仅仅作为接口定义。
        const sslSocketOps * ops //实现PRFileDesc的接口定义; 
    ...
    sslSecurityInfo  sec; //操作ssl信道的方式，比如加密，解密之类
    ...
        const char      *url;    //目的地址，浏览器接受的url
    ...
    sslHandshakeFunc handshake;        //函数可以作为锁来使用
    sslHandshakeFunc nextHandshake;               
    sslHandshakeFunc securityHandshake;   
      //回调函数，timeout，lock，暂存缓冲，线程，ssl握手方法，状态
};
上面的一个sslSocketStr代表了一个连接，并且描述了表示层即ssl协议，和openssl类似，mozilla也永术语“PUSH”来将一个安全描述符压入一个普通的传输层套接字(类似OpenSSL的BIO机制，后面会说)，比如你访问http://www.google.com.hk，那么敲下回车的时候就会建立一个sslSocketStr，其中url就是你要访问的google的网址，某些网站需要安全连接，如果需要安全的话随之就会初始化sslSocketStr中的fd中的PRIOMethods为ssl_methods，它完成了套接字IO的几乎所有的语义，在openssl中，该结构体由SSL_METHOD实现，原理和此处的mozilla几乎一致：
static const PRIOMethods ssl_methods = {
    PR_DESC_LAYERED,
        ...
    ssl_Read,                //read
    ssl_Write,               //write
   ssl_Recv,                //recv
    ssl_Send,                //send
    ...
};
static const sslSocketOps ssl_secure_ops = {
    ...
        ssl_SecureRecv,
        ssl_SecureSend,
        ...
};
为何要有PRIOMethods和sslSocketOps两个结构体呢？看起来一个就够了，答案是为了实现分层模型，PRIOMethods并没有具体的实现策略，只是表示一个“协议层”的语义，对于ssl的具体实现当然没有必要在ssl层就全做掉，因为即使选择ssl也可以有不同的策略，也就需要再来一个结构体了，特别是，这样可以不加区分地统一使用一致的SSL接口，在不实现ssl的情况下，可以再实现一个ssl_default_ops(security/nss/lib/ssl/sslsock.c)。
     ssl_Do1stHandshake完成了ssl握手时的状态机转换，mozilla并不区分client方法和server方法，而是完全按照RFC2246的规定来实现ssl，对于client端，在ssl_SecureConnect中会发起对server的连接，也就是发送一个ClientHello消息，此时会将sslSocketStr的securityHandshake设置为ssl2_BeginClientHandshake(仅对ssl2来说)，接下来任何的读写ssl，都会调用PRIOMethods中的recv/send函数，然后就回进入到ssl_Do1stHandshake状态机，在其中client会调用到这个刚刚设置的ssl2_BeginClientHandshake函数，在该函数最后，按照RFC2246的规定，会进行如下设置：
ss->handshake     = ssl_GatherRecord1stHandshake;
ss->nextHandshake = ssl2_HandleServerHelloMessage;
握手回调函数handshake自己维护状态机，这一点和openssl不同，在handshake的调用最后，函数根据调用结果和当前状态将nexthandshake按照RFC2246设置成下一个状态，然后在ssl_Do1stHandshake将状态机向前推进：
int ssl_Do1stHandshake(sslSocket *ss)
{
    do {
        if (ss->handshake == 0) {
            ss->handshake = ss->nextHandshake;
            ss->nextHandshake = 0;
        }
        if (ss->handshake == 0) {
                ss->handshake = ss->securityHandshake;
                ss->securityHandshake = 0;
        }
        ...
        //握手完毕时要退出循环
        rv = (*ss->handshake)(ss);
        ++loopCount;
        } while (rv != SECFailure); 
        ...
}
ssl握手的后半部分会根据协商内容设置cipher，设置cipher也就部分初始化了sslSocketStr的sec字段，在ssl2_CreateSessionCypher(由状态处理函数ssl2_XYZSetupSessionCypher调用)确定ss->sec.enc函数指针PK11_CipherOp，从此，所有的数据传输都要经过加密，加密的方法就是PK11_CipherOp，mozilla通过封装p11接口来统一处理安全通道的配置以及使用过程。
     PRFileDesc作为一个解耦层(很重要，不仅仅解除了各个模块耦合，而且还实现了一个分层的模型)，将操作路由到sslSocketOps，而sslSocketOps中同样可以根据ssl的不同状态或者不同配置将操作继续路由，比如在ssl_SecureSend中会调用：
rv = (*ss->sec.send)(ss, buf, len, flags);
可见sec字段的send也是一个可变更的回调函数，总体的过程就是：
首先ss->fd->methods->send[ssl_Send]:
rv = (*ss->ops->send)(ss, (const unsigned char*)buf, len, flags);[ssl_SecureSend]:
rv = (*ss->sec.send)(ss, buf, len, flags);[ssl2_SendBlock]:
ssl_DefSend.
最终ssl_DefSend将数据发送了出去，通过socket将数据发送了出去。
     上述的过程不是很难理解，而且实现的很合理，mozilla更合理的一个地方就是通过PKCS#11接口来统一封装所有的安全操作，为何通过p11封装呢？我觉得p11主要用于客户端，解决了客户端安全加密的一系列问题，而浏览器也在客户端，因此使用p11会十分方便，虽然可能机器上没有usbkey，但是软实现的P11一样好用，毕竟p11只是一个规范，p11的软实现会调用mozilla安全框架的另一部分，那就是crypto接口(类似openssl的EVP)。