mozilla的安全架构

晨曦之光 发布于 2012/04/10 14:59
阅读 227
收藏 0

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)。


原文链接:http://blog.csdn.net/dog250/article/details/5717133
加载中
返回顶部
顶部