前面讨论的基本认证方式和摘要认证以及报文完整性检查都是轻量级的方法,但对于重要的如银行业务处理,大规模网上购物来说,这还不够,我们需要一种能够提供下列功能的HTTP安全技术:
- 服务器验证,客户端验证服务器是真的还是伪造的
- 客户端认证,服务器验证客户端是真的还是伪造的
- 完整性,客户端和服务器的数据不被修改
- 加密,无需担心会话被窃听
- 效率,算法的运行要求足够快
- 普适性,基本上所有的客户端和服务器都支持这种协议
- 其他
https
https是最流行的HTTP安全形式,它的URL以** https:// ** 而不是 http:// 开头。所有的HTTP请求和响应数据在发送到网络之前都要进行加密,HTTPS在HTTP下面提供了一个安全层,可以使用SSL,也可以使用其后继者TSL(Transport Layer Security,传输层安全),由于二者十分类似,所以一般不太严格地用SSL来表示SSL和TSL。
数字加密
概念
密码:对文本进行编码的算法。
密钥:改变密码行为的数字化参数
对称密钥加密系统:编/解码使用相同密钥的算法
不对称密钥加密系统:编/解码使用不同密钥的算法
公开密钥加密算法:一种能够使数百万计算机便捷地发送机密报文的系统
数字签名:用来验证报文是否被改动的校验和。
数字证书:由可信的组织验证和签发的识别信息
假如使用rot3(循环移位3字符)方式对报文加密,则 明文 meet 加密后为 phhw,示意图如下:
那在概念中,密码就是 “循环移位N字符” ,N的值是由密钥控制的,在这里N的值是3。 改变密钥的值就能产生不同的密文。编码算法和编码机器都可能落入敌人手中,但是只要没有正确的号盘设置(密钥值),也无法实现解码。这种属于使用了密钥的密码。
数字密码:数字密码只是一些数字,这些数字密钥值是编码/解码算法的输入,编码算法就是一些函数,这些函数会读取一块数据,并根据算法和密钥的值对其进行编码/解码。给定一段明文P、一个编码函数E和一个数字编码密钥e,就可以生成一段经过编码的密文C,通过解码函数D和解码密钥d,就可以将密文C解码为原始的明文P,当然,编码/解码函数互为反函数。
对称密钥加密技术
对称密钥加密在编码时候使用的密钥值和解码时候的密钥值一样的。保持密钥的机密很重要,在很多情况下,编码解码算法都是众所周知的,因此密钥是唯一保密的东西了。可用密钥的数量取决于密钥中的位数,以及可能的密钥中有多少是有效的。就对称加密而言,通常所有的密钥值都是有效的(知名的非对称密钥加密系统RSA中,有效密钥必须以某种方式与质数相关,因此并非所有的密钥都有效)。8位的密钥只有256个可能,40位的密钥可以有2的40次方个可能的密钥值等等。
流行的对称密钥加密算法有:DES/Triple-DES、RC2、RC4
缺点:发送者和接收者在对话前一定要有一个共享的保密密钥,服务器与每个客户端都需要有一个独立的密钥,以致如果客户端数量过多的情况下,服务器保存的密钥数量可观。如果N个节点,每个节点都要和其他所有N-1个节点通信,总共大概会保存N的平方个密钥,这将是一个管理噩梦。
公开密钥加密技术
公开密钥加密技术使用了两个非对称密钥,一个用来对报文编码,一个用来对报文解码。编码密钥是可以公之于众的,每个不同的客户端可以用相同的编码密钥进行加密,但是只有主机自己才知道私有的解密密钥,只有解密密钥才能解码。
在引入公钥加密机制之前,可以先看两个问题:
问题1:314159265358979 × 314159265358979 的结果是多少?
问题2: 3912571506419387090594828508241 的平方根是多少?
如果不用计算器,第一个问题,相信大多数人花上一两个小时用纸笔能够计算出来,而第二个问题,即使花上一两天,估计也基本上没人能解出来。虽然平方和开方互为逆运算,但是它们的复杂度差异却很大,这种不对称性构成了公钥密码体系的基础。一种叫做RSA的公钥机制表明,对计算机来说,大数的乘法比对大数进行因式分解要容易得多。所有公开密钥非对称加密系统的要求是,即便拥有以下线索:
- 公开密钥(共有的,每个人都可以获得)
- 一小片拦截下来的密文(可以网络嗅探获得)
- 一条报文以及与之相关的密文(对一段文本使用公钥加密就可以得到)
也无法计算出保密的私有密钥。
RSA 就是满足这些条件的流行的公开机密要加密系统。RSA的算法是公开的,源代码也可以获得,破解的难度与一个极大的数字进行质因数分解的难度一样。
混合加密系统和会话密钥
任何人只要知道了公开密钥,就可以向一台公共服务器发送安全报文,所以非对称的公开密钥加密系统是很好用的,两个节点无须为了进行安全的通信而先交换私有密钥。但公开密钥加密算法的计算可能会很慢,比较常见的做法是在两个节点之间通过便捷的公开密钥加密技术建立起安全通信,然后再利用那条安全通道产生并发送临时的随机对称密钥,通过更快的对称加密技术对其余的数据进行加密。
数字签名
除了加密/解密报文之外,还可以用加密系统对报文进行签名(sign),以说明是谁编写的报文,同时证明报文未被篡改过,这种技术被称为数字签名(digital signing)。签名是加了密的校验和,使用数字签名有以下两个好处:
签名可以证明是作者编写了这条报文。
只有作者才有最机密的私有密钥,因此只有作者才能计算出这些校验和。
签名可以防止报文被篡改。
如果恶意攻击者在传输过程中修改了报文,则校验和就不再匹配了,攻击者没有私钥,无法为篡改的报文伪造正确的验证码。
以下例子说明了节点A是如何向节点B发送一条报文,并对其进行签名:
- 节点A将变长报文提取为定长摘要。
- 节点A对摘要应用一个“签名”函数,这个函数会将用户的私有秘钥作为参数。因为只有A知道私有密钥,所以正确的签名函数会说明签名者就是所有者。在下图中,由于解码函数D中包含了用户的私有密码,所以我们将其作为签名函数使用。
- 一旦计算出签名,节点A就将其附加在报文末尾,并将报文和签名都发给B
- 在接收端,如果B需要确定报文确实是A写的,而且没有被篡改过,节点B就可以对签名进行检查。节点B接收经过私有秘钥扰码的签名,并应用了使用公开密钥的反函数,如果拆包后的摘要与节点B自己的摘要版本不匹配,就说明要么被篡改了,要么发送者不是A。
数字证书
数字证书都是由可信任的颁发机构颁发,它通常包括 对象的名称、过期时间,证书颁发者,来自证书发布者的数字签名、通常还包括对象的公开密钥以及对象使用签名算法的描述性信息。典型的数字签名格式如下:
数字证书没有单一的全球标准,但现在大多数证书都以一种标准格式 ——X.509 v3 描述。
用证书对服务器进行认证
通过https建立一个安全的web事务之后,现代的浏览器会自动获取所连接服务器的数字证书,如果如武器没有证书,安全连接就会失败,服务器证书中包含很多字段,包括:
- web站点的名称和主机名;
- web站点的公开密钥;
- 颁发机构的名称;
- 颁发机构的签名。
浏览器收到证书时会对签名颁发机构进行检查,如果这个机构是很权威的公司,那浏览器一般已经知道其公开密钥了(浏览器会预先安装很多签名颁发机构的证书),就能像之前那样验证签名了。如果对签名颁发机构一无所知,浏览器就无法确定是否应该信任这个签名颁发机构,它通常会向用户展示一个对话框,看用户是否相信这个签名发布者,因为发布者可能是本地IT部门。以下展示了验证签名的过程:
HTTPS-细节介绍
https就是在安全的传输层上发送的http,它在将http报文发送给TCP之前,先将其发送给一个安全层,对其进行加密。对web服务器发起请求时,我们需要一种方式来告知web服务器去执行http的安全协议版本,这是在URL的方案中实现的,对web资源执行某事务时,它会检查URL方案:
- 如果URL方案是http,客户端会打开一条到服务器端口80的连接(默认情况下),并发送http命令。
- 如果URL的方案是https,客户端就会打开一条到服务器端口443(默认情况)的连接,然后与服务器握手,以二进制格式与服务器交换一些SSL安全参数,附上加密的http命令。
在https中,客户端首先打开一条到web服务器端口443(默认情况)的连接,一旦建立了TCP连接,客户端和服务器就会初始化SSL层,对加密参数进行沟通,并交换密钥,握手完成后,SSL就初始化完成了,客户端就可以将请求报文发送给安全层了,在将这些报文发送给TCP之前,要先对其进行加密。http和https的对比:
SSL握手
在发送已加密的HTTP报文之前,客户端和服务端要进行一次SSL握手,主要完成以下工作:
- 交换协议版本号
- 选择一个两端都了解的密码
- 对两端身份进行验证
- 生成临时会话密钥,以便加密信道
SSL握手简化版示意图如下:
在一个web服务器上执行安全事务,比如提交银行卡信息时,总是希望在于你所认为的那个组织对话,因此https事务总是要求使用服务器证书的。站点证书有效性检查步骤如下:
- 日期检测。检查证书的起始日期和结束日期。
- 签名颁发者可信度检测。每个证书是由某个证书颁发机构(CA)签发的,它们负责位服务器担保,证书有不同的等级,每种证书都要求不同级别的背景验证。比如申请某个电子商务服务证书,通常要求提供一个营业的合法证明。
- 签名检测。一旦判定签名授权是可信的,浏览器就要对签名使用颁发机构的公开密钥,并将其与校验码比较,以查看证书的完整性。
- 站点身份检测。为防止服务器复制其他人的证书,或拦截他人流量,大部分浏览器都会试着去验证证书中的域名与它们所对话的服务器的域名是否匹配。
虚拟主机与证书
对于虚拟主机(一台服务器上有多个主机名),有些流行的web服务器程序只支持一个证书,如果用户请求的是虚拟主机名,与证书名称并不完全匹配,浏览器就会显示警告框。比如cajun-shop.com网站,站点的托管服务提供商提供的官方名称位 cajun-shop.securesites.com。 用户进入http://www.cajun-shop.com时,服务器证书中列出的官方主机名(*.securesites.com)与用户浏览的虚拟主机名(www.cajun-shop.com)不匹配,以至于出现警告。
为了防止出现这个问题,cajun-shop.com的所有者会在开始处理安全事务时,将所有用户都重定向到cajun-shop.securesites.com。
通多代理以隧道形式传输安全流量
很多公司都会在公司网络和公共因特网的安全边界上放置一个代理,代理是防火墙路由器唯一允许进行http流量交换的设备,它可能会进行病毒检测或者其他的内容控制工作。
但只要客户端开始用服务器的公开密钥对发往服务器的数据进行加密,代理就再也不能读取http首部了!代理不能读取首部,意味着无法知道应该将请求转向何处。
这种情况一种常用的技术就是https SSL 隧道协议,客户端首先要告知代理,他想要连接的安全主机和端口,这是在开始加密之前以明文形式告知的,所以代理可以理解这条信息。
http通过新的名为connect的扩展方法来发送明文形式的端点信息,connect方法会告诉代理,打开一条到期望主机和端口号的连接,这项工作完成之后,直接在客户端和服务器之间以隧道形式传输数据。
以下示意了一个connet: