SSL技术是很常用的, 无处不在, 在你SSH的时候, 在你HTTPS的时候, 在任何一款想兼具身份认证与加密通信的应用中, 你可以随处看到它的身影.
本人之前只是用用脚本, SSL接口都被透明化了, 而且还是阻塞接口, 或者会使用Libevent支持的SSL体验一番异步的感觉, 也曾经读过Https的源码, 当时并没有在SSL方面引起重视, 直到我希望把Https引入到我的开源Http Server中, 终于有机会来编码实现异步SSL啦.
要理解与正确的编程实践异步SSL, 需要对Feed工作模式的原理有一定的理解, 还需要对网络事件编程有掌握, 最后最重要的还是对SSL握手的过程有清晰的认识, 对SSL的原理有清晰的认识, 这样才不至于在编程时出现逻辑问题, 我们要清楚的明白每一步调用的目的与作用, 而不是胡猜或者模仿.
代码说明:可以通过浏览器访问或者使用curl/wget进行访问, 记住使用https访问指定端口.
逻辑说明:
1, SSL握手阶段, 很明显的使用了feed模式, 调用链:read -> bio_write(rbio) -> ssl_accept, 即将读到的数据feed给ssl_accept使用.
feed后根据bio_pending(wbio)确定ssl是否产生了一些待回复的握手数据, 如果有, 我们注册写事件帮ssl发送出去, 此时调用链为: bio_read -> write
2, 数据交互阶段, 注意SSL握手阶段是绝对不可能交互普通数据的, 因为交互普通数据依赖于SSL彻底完成后获得的对称密钥.
在SSL完全结束前, 是不可能有正常数据到来的, 客户端与服务端是默契的一问一答, 直到SSL握手结束, 我们可以看一下握手交互时序图来看一下这个关系, 客户端在接受到服务端最后一次MAC应答之前是不会操作普通数据的, 服务端在接收到客户端发来的MAC后进入了最后一步握手输出阶段, 在最后一步时我们送出MAC兵彻底进入了数据交互阶段, 这些逻辑在代码里有所体现.
在代码中, SSL_accept意味着客户端MAC被接受, 此时SSL会在wbio中pending上最后一步要发送给客户端的MAC, 我们进行了状态的记录, 在MAC送给客户端后, 我们立即将HTTP应答送出而不等待客户端HTTP请求, 因为我不想解析与理解HTTP协议, 所以在这时候发送是最佳的时机, 并且一定是附带了connection:close来让客户端主动的关闭掉, 因为我们没有主动关闭客户端的逻辑. 在我们消耗掉wbio中的pending MAC后, 客户端发送HTTP请求到来, 服务端读事件将会检测ssl握手完成(因为我们的wbio pending的MAC已经被消耗掉了), 于是我们接下来的数据都被当作普通交互数据, 经历调用链: read -> bio_write -> ssl_read -> print to screen.
我不确定SSL的使用方法一定是完全正确的, 但至少目前运行还没有出过问题, 欢迎大家批评指正, 感兴趣的同学又有福了.(PS:懒得弄证书和prikey的同学可以直接拷走.)
SSL基础知识与握手流程观看:http://www.cnblogs.com/happyhippy/archive/2007/05/14/746476.html