ssl的消息读写以及和tcp语义的异同-阿里云开发者社区

开发者社区> 安全> 正文
登录阅读全文

ssl的消息读写以及和tcp语义的异同

简介:
SSL实现必须读取整条记录,哪怕select返回了一个字节可读,那么ssl也要读取整个记录,这种基于纪录的读写方式就是为了正确的加密个解密。因此如果用select模型的话可能会出现一些莫名其妙的问题,事实上也正是ssl消息需要加密解密从而需要整个消息整个消息读写才使得ssl协议的行为和tcp的有了少有的不一致。
     tcp的特点是流式传输,流式的特点就是没有消息边界,一个连接就是一个流,需要应用程序自己去划分自己的数据,举个例子就是一端写入x字节,对端可能读出y字节,具体多少要看网络状况和窗口情况,tcp在这一点上是相当复杂的,应用程序的发送只是简单的将数据放入tcp的发送缓冲区,而接收只是简单的从接收缓冲区中取回数据,反观udp就不是这样子,udp是基于数据报的,就是说不能分段,一端写入多少另一端就读出多少,当然也可能永远收不到,也可能乱序等等。现在看看ssl,它看起来好像是结合了tcp和udp的特点,它是有连接的,必须可靠传输并且按照顺序收发,但是却不是流式的,每次调用SSL_read必须读入一个ssl纪录,一个ssl纪录有一个固定大小的头部(5字节),该头部指示了消息类型,ssl版本号以及消息长度,首先需要读出一个ssl消息头部,接下来就要在该头部的消息长度字段的指导下进行消息体的读取,而且必须读取完整个完整消息之后才能返回成功,否则均返回失败,并且什么都不做,ssl读操作中,带有头的消息是read的最小单位。ssl3_read_bytes是openssl中SSL_read最终要调用的函数,它内部调用了ssl3_get_record:
static int ssl3_get_record(SSL *s)
{
...
    rr= &(s->s3->rrec);
    sess=s->session;
...

again:
    if ((s->rstate != SSL_ST_READ_BODY) ||
    (s->packet_length < SSL3_RT_HEADER_LENGTH)) {
        n=ssl3_read_n(s, SSL3_RT_HEADER_LENGTH, s->s3->rbuf.len, 0);
        if (n <= 0) return(n); 
        s->rstate=SSL_ST_READ_BODY;
        p=s->packet;
        rr->type= *(p++);   //得到消息头中的消息类型
        ssl_major= *(p++);  //得到消息头中的主版本号
        ssl_minor= *(p++);  //得到消息头中的次版本号
        version=(ssl_major<<8)|ssl_minor; //组合成版本号
        n2s(p,rr->length);  //得到消息的长度
...
    }
    if (rr->length > s->packet_length-SSL3_RT_HEADER_LENGTH) {
        i=rr->length;
        n=ssl3_read_n(s,i,i,1); //按照消息长度读取消息
        if (n <= 0) return(n); 
    }
    s->rstate=SSL_ST_READ_HEADER;
...
    
}
在ssl3_read_n的主要逻辑很简单:
while (newb < n) {
    clear_sys_error();
    s->rwstate=SSL_READING;
    i=BIO_read(s->rbio, &(s->s3->rbuf.buf[off+newb]), max-newb);
    if (i <= 0) {    //只要没有读到数据,那么就返回
        s->s3->rbuf.left = newb;
        return(i);
    }
    newb+=i;
}
int ssl3_pending(const SSL *s)
{
    if (s->rstate == SSL_ST_READ_BODY)
        return 0;
    return (s->s3->rrec.type == SSL3_RT_APPLICATION_DATA) ? s->s3->rrec.length : 0;
}
通过SSL_pending可以判断是否有消息数据还在缓冲区或者还没有到缓冲区,它实际上返回的就是消息的长度,因此如果使用select调用的话,很有可能select检测到的可读情况仅仅只有tcp送来的很少的数据量,远远不够ssl需要的数据量,那么只要SSL_pending返回非0,那么就需要循环调用SSL_read继续读取,否则你会认为这是一个莫名其妙的错误,明明select返回了,为何SSL_read却读不到数据,注意,在ssl读缓冲区被完全的消息填满前,SSL_read是不会返回任何数据的。同样的,SSL_write也是一样的道理,总之在openssl的实现中,一个ssl拥有一个SSL3_BUFFER类型的结构体(v3):
typedef struct ssl3_buffer_st {
    unsigned char *buf;     /* at least SSL3_RT_MAX_PACKET_SIZE bytes,
    size_t len;             /* buffer size */
    int offset;             /* where to 'copy from' */
    int left;               /* how many bytes left */
} SSL3_BUFFER;

可以看到在ssl_st结构体中有ssl3_state_st类型的字段,ssl3_state_st中有SSL3_BUFFER类型的rbuf和wbuf,它们并不是链表,而是只有一个缓冲区,并且在ssl_write中并没有看到有线程保护的措施,因此每一个ssl连接存在且仅存在一对SSL3_BUFFER,也就是说每次只能由一个线程操作一个读缓冲或者一个写缓冲,这就迎合了openssl文档中的一个FAQ:Is OpenSSL thread-safe? Yes (with limitations: an SSL connection may not concurrently be used by multiple threads).这就是不能在多个线程操作同一个ssl指针的原因,当初这个问题可害得我加了好几个周末的班啊。特别要注意的是,如果用select模型来写基于ssl的程序,一定要弄清楚ssl和tcp语义的不同,也正是这种不同点使得将传统套接字程序移植成ssl套接字程序并不是我一年前认为的那么简单。



 本文转自 dog250 51CTO博客,原文链接:http://blog.51cto.com/dog250/1271983

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
+ 订阅

云安全开发者的大本营

其他文章
最新文章
相关文章