大纲
进程间通信所引发的安全问题
我们知道不同主机进程间的通信可以通过socket(ip:port)来实现.这里主要以C/S模型来介绍, 服务器端为了能让任何人随时能够访问自己,因此有一个固定的ip和port,时刻保持在监听状态. 而客户端想要去访问时,会在自己linux内核中随机注册一个socket,进而通过TCP/IP协议,以及交换机和路由器层层递进.将消息发生至服务器端,而后服务器端将本地磁盘的文件信息再次以同意层层递进的方式返回给客户端.以达到双方进程间通信. 以上的通信过程,完全是基于明文发生,也就是可以被所有人看见,且能获取其内容的.由于此问题的出现,ITSEC这一组织,首次提出信息安全的保密性、完整性、可用性的概念. 安全威胁 保密性威胁：通过窃听等手段窃取信息. 完整性威胁: 通过修改、伪装、重放来进行攻击. 可用性威胁: 使用某种手段让目标机器停止提供服务,也称为拒绝服务.(Dos)
安全通信的ssl协议
在此需求下,之后有网景公司写出ssl协议.Secure Socket layer,是安全套接字层协议. 其是处于TCP/IP协议的应用层及传输层之间,当数据需要进行通信保密时,可以借用此ssl层,进而达到保密的功用. ssl版本有(Netscape,1994)ssl1.0,ssl2.0,ssl3.0,在之后又有了将其标准化后的协议tls(transport layer security),tls的版本有tls1.0(相当于ssl3.0;IETF:1999),tls1.1,tls1.2(常用版本),tls1.3(草案阶段).
预防以上安全威胁的解决方案(加密解密技术与协议)
安全机制有:访问控制(安全服务)和密码学(加密解密). 加密解密的方式: 对称加密: 加密和解密使用同一密钥的方法. 采用的是块密码,将数据分成固定大小的块,逐个进行加密、解密. 常见的算法: DES(Data Encryption Standard) 3DES(tripe DES) AES(Advanced Encryption Standard) Twofish、Blowfish、IDEA、RC6、CAST5等 用途： 数据的加密解密； 缺陷: 1 密钥过长(由于密钥安全性跟所给的密钥相关,密钥越复杂,则其加密算法安全性更高) 2 由于密钥过长,导致了分发的难度
非对称加密(公开密钥加密): 非对称加密也加公开密钥加密,也就是俗称的公钥加密.使用一对密钥进行加密解密,分别为公钥(public key)、私钥(private key). 特征: 私钥自己保留,公钥由私钥提取出来可公开给所有人. 公钥加密的数据只能由与之对应的私钥解密.反之,私钥加密的数据只能由与之对应的公钥解密. 常见算法: RSA、DSA、ELGamal、DH DSS: Digital Signature Standard DSA：Digital Signature Algorithm 用途： 1 身份验证; 2 密钥交换; 3 加密(不常用)：加密数据 缺陷: 对数据的加密比对称加密要慢3个数量级
单向加密（哈希函数)： 给定一个数据,根据其算法定长输出一个固定长度的值. 特征: 1 定长输出(不管数据大小,输出的特征码长度不变) 2 雪崩效应(数据改变一个微小的字符,导致其特征码大幅变化) 3 只能加密不能解密(单向加密) 常见算法: MD5(Message Digest 5),128bits SHA1(Secure Hash Algorithm 1),160bits SHA224、SHA256、SHA384、SHA512 用途： 用于提取数据的特征码,验证数据完整性.
加密解密的详细步骤:
发送方： 1 提取数据的特征码,将其附加在数据后面(用于数据完整性验证) 2 使用发送方自己的私钥对特征码进行加密,加密后的密文称为数字签名(用于身份验证) 3 生成一个临时密钥,用此密钥对数据以及签名一起加密(对称加密,用于加强保密性) 4 将临时密钥用接受方的公钥进行加密(用于密钥交换) 接受方: 1 将收到的数据用自己的私钥解密,获取临时密钥(密钥交换实现) 2 用临时密钥解密,获取数字签名(数据保密性实现) 3 用发送方的公钥进行解密,获取特征码.(若能够解密则证明是发送方本人,也就是验证身份) 4 对数据进行提取特征码,与解密的特征码比对.(如果两者的特征码相同,则说明数据没有变动.也就是完整性得以验证) 看完上述过程不知有何不妥呢?发送方与接受方之间存在不确定关系.为什么这样说,如果是一个第三方的用户,像告诉"发送方"我是"接受方",反之,告诉"接收方"我是"发送方".在此场景下,完全无法确定通信对象,就是我想要通信的对象.因而我们需要这么一个能够保证,与我通信的人就是我想要通信的对象,这么一个功能.于是有了一个名为CA的机构. 认证协议: CA是PKI(public key infrastructure)公钥基础设施的一个组成部分.CA是一个证书颁发机构,使用数字证书的形式,为双方提供可信、可靠的通信. 证书作用机制: 首先要想提供一个可信、可靠的通道.那么首先此CA机构自身,必须要能够被信任.因此证书机构自己先给自己颁发证书,再给注册者发放证书.证书有此机构的公钥,用于验证证书来源可靠性.还有一点,所有的CA都是由根CA所衍生,只有是可信机构发布的证书,则都能够被认同. 先来看一下PKI的组成: 签证机构:CA (办理认证的机构) 注册机构:RA (申请办证的机构) 证书吊销列表:CRL (证书丢失,用于挂失) 证书存取库 (当别人请求认时的资料库) 由于每个CA的证书格式的理解都有所不同,因而有了x.509这个数字证书标准,常用版本为x.509.v3此标准定义了证书所需要: 1 证书的版本号; 2 证书的序列号,每个证书的序列号唯一; 3 证书所使用的签名算法; 4 证书的发行机构名称; 5 证书的有效期限; 6 证书所有人的名称; 7 证书所有人的公钥; 8 发行商的唯一标识; 9 证书所有人的唯一标识; 10 扩展; 11 签名:CA对此证书的签名;
ssl会话主要三步:
客户端向服务器端索要并验证证书; 双方协商生成"会话密钥"; 双方采用"会话密钥"进行加密通信;
基于ssl通讯的过程具体阶段是这样(以下基于公钥的密钥交换): 第一阶段 客户端发出握手请求(client_hello): 发送信息包括: 客户端支持的加密算法(如RSA), 支持的ssl协议的版本(如TLS2.0,如果对方支持版本不同,中断通讯) 生成一个随机数并发送给服务器(用于生成"会话密钥") 支持的压缩算法. 服务器端回复握手请求(server_hello): 确认加密算法、协议版本、支持压缩算法信息,并生成一个随机数(用于生成"会话密钥"). 第二阶段 服务器端将自己的证书发送给客户端,并请求客户端证书. 客户端检查证书,检查项目: 证书是否可靠,证书内容的完整性,证书的名称是否与我访问目标名称一致,证书是否过期,证书是否被吊销. 检查通过进入下一阶段. 第三阶段 客户端将自己的证书发送给服务器端,并将上述所有信息用hash算法计算并使用私钥进行数字签名发送给服务器端(用于验证数据的完整性) 客户端生成名为pre-master-secret的随机数,将其通过服务器端公钥加密并发送至服务器端. 服务器端检查证书,检查标准与客户端一致.解密数字签名提取hash值来,确定数据完整性. 客户端和服务器端同时使用三组随机数生成相同的密钥,成为Master-secret. 第四阶段 双方通过Master-secret作为通信密钥,同时结束握手. 以后则进入加密通信的阶段. 注意:如果是用DH算法进行密钥交换,则过程有所不同. 以下转自http://blog.csdn.net/dog250/article/details/5717162,解决上述过程某些细节. ssl3_send_client_key_exchange是openssl中客户端确定密钥的函数，同时也发送了“一部分”数据给服务器，这一部分数据就是所谓的pre_master，不管是客户端还是服务器都根据对端传过来的pre_master和自己计算出来的另一部分数据来生成最终的对称密钥，生成过程中需要hello消息中的随机数，这样生成的密钥才不会每次都一样。由于ssl协议中dh份额来源于证书，而证书又是静态的，因此十分有必要引入一种随机因素来保证通过静态证书导出的密钥份额协商出来的密钥的随机性。同时这也是pre_master的意义，那就是随机，对于rsa密钥交换算法来说，pre-master-key本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥，但是对于dh，包括ecdh算法(不考虑匿名dh和瞬时dh)，就只有hello消息中的两个随机数因子了。 pre master的存在在于ssl协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre master secret就有可能被猜出来，那么仅适用pre master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。
openssl工具
-text:以文本格式输出
本文转自 撒旦搞时间 51CTO博客，原文链接：http://blog.51cto.com/12074120/1887831，如需转载请自行联系原作者
