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将数据发送了出去。
有几个重要的结构体先了解一下：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)。
本文转自 dog250 51CTO博客，原文链接:http://blog.51cto.com/dog250/1271800
