1,用户隐私泄露的风险很大
2,HTTPS能有效保护用户隐私
2.1 数据保密性
2.1.1 非对称加密及密钥交换
这篇中文博客对RSA的原理解释得比较清楚易懂:RSA算法原理。
2.1.2 对称加密
2.2 数据完整性
这部分内容相对比较简单,openssl现在使用的完整性校验算法有两种:MD5或者SHA。由于MD5在实际应用中存在冲突的可能性比较大,所以尽量别采用MD5来验证内容一致性。SHA也不能使用SHA0和SHA1,中国山东大学的王小云教授在2005年就牛逼地宣布破解了SHA-1完整版算法。建议使用SHA2算法,即输出的摘要长度超过224位。
2.3 身份验证和授权
数字签名的签发。首先是使用哈希函数对证书数据哈希,生成消息摘要,然后使用CA自己的私钥对证书内容和消息摘要进行加密。
数字签名的校验。使用CA的公钥解密签名,然后使用相同的签名函数对证书内容进行签名并和服务端的数字签名里的签名内容进行比较,如果相同就认为校验成功。
数字签名签发和校验使用的密钥对是CA自己的公私密钥,跟证书申请者提交的公钥没有关系。
数字签名的签发过程跟公钥加密的过程刚好相反,即是用私钥加密,公钥解密。
现在大的CA都会有证书链,证书链的好处一是安全,保持根CA的私钥离线使用。第二个好处是方便部署和撤销,即如何证书出现问题,只需要撤销相应级别的证书,根证书依然安全。
根CA证书都是自签名,即用自己的公钥和私钥完成了签名的制作和验证。而证书链上的证书签名都是使用上一级证书的密钥对完成签名和验证的。
怎样获取根CA和多级CA的密钥对?它们是否可信?当然可信,因为这些厂商跟浏览器和操作系统都有合作,它们的公钥都默认装到了浏览器或者操作系统环境里。比如firefox就自己维护了一个可信任的CA列表,而chrome和IE使用的是操作系统的CA列表。
3,HTTPS对速度和性能的影响
HTTPS对速度的影响非常明显。每个HTTPS连接一般会增加1-3个RTT,加上加解密对性能的消耗,延时还有可能再增加几十毫秒。
HTTPS对CPU计算能力的消耗很严重,完全握手时,webserver的处理能力会降低至HTTP的10%甚至以下。
3.1 HTTPS对访问速度的影响
302跳转。为什么需要302?因为用户懒。我想绝大部分网民平时访问百度时都是输入www.baidu.com或者baidu.com吧?很少有输入http://www.baidu.com访问百度搜索的吧?至于直接输入https://www.baidu.com来访问百度的HTTPS服务的就更加少了。所以为了强制用户使用HTTPS服务,只有将用户发起的HTTP请求www.baidu.com302成https://www.baidu.com。这无疑是增加一个RTT的跳转延时。
上图第三阶段的SSL完全握手对延时的影响就更加明显了,这个影响不仅体现在网络传输的RTT上,还包含了数字签名的校验,由于客户端特别是移动端的计算性能弱,增加几十毫秒的计算延时是很常见的。
还有一个延时没有画出来,就是证书的状态检查,现在稍微新一点的浏览器都使用ocsp来检查证书的撤销状态,在拿到服务器的证书内容之后会访问ocsp站点获取证书的状态,检查证书是否撤销。如果这个ocsp站点在国外或者ocsp服务器出现故障,显然会影响这个正常用户的访问速度。不过还好ocsp的检查周期一般都是7天一次,所以这个对速度的影响还不是很频繁。另外chrome默认是关闭了ocsp及crl功能,最新版的firefox开启了这个功能,如果ocsp返回不正确,用户无法打开访问网站。
服务器端配置HSTS,减少302跳转,其实HSTS的最大作用是防止302HTTP劫持。HSTS的缺点是浏览器支持率不高,另外配置HSTS后HTTPS很难实时降级成HTTP。
设置ssl session 的共享内存cache. 以nginx为例,它目前只支持sessioncache的单机多进程共享。配置如下:
ssl_session_cache
shared:SSL:10m;
如果是前端接入是多服务器架构,这样的session cache是没有作用的,所以需要实现sessioncache的多机共享机制。我们已经在nginx 1.6.0版本上实现了多机共享的session cache。多机sessioncache的问题必须要同步访问外部sessioncache,比如redis。由于openssl目前提供的API是同步的,所以我们正在改进openssl和nginx的异步实现。
配置相同的session ticket key,部署在多个服务器上,这样多个不同的服务器也能产生相同的 sessionticket。session ticket的缺点是支持率不广,大概只有40%。而session id是clienthello的标准内容,从SSL2.0开始就被全部客户支持。
ssl_session_tickets
on;
ssl_session_ticket_key ticket_keys;
设置ocsp staplingfile,这样ocsp的请求就不会发往ca提供的ocsp站点,而是发往网站的webserver。ocsp的配置和生成命令如下:
上面是nginx配置,如下是ocsp_stapling_file的生成命令:
openssl s_client -showcerts -connect yourdomain:443 </dev/null | awk -v c=-1 '/-----BEGIN CERTIFICATE-----/{inc=1;c++}inc {print > ("level" c ".crt")} /---ENDCERTIFICATE-----/{inc=0}'
for i in level?.crt;
do
echo;
done
openssl ocsp -text -no_nonce -issuer level1.crt -CAfileCAbundle.crt -cert level0.crt -VAfile level1.crt -url $ocsp_url-respout domain.staple ,其中$ocsp_url等于ocsp站点的URL,可以通过如下命令求出:for i inlevel?.crt; do echo "$i:"; openssl x509 -noout -text -in "$i" |grep OCSP; done,如果是证书链,一般是最底层的值。
优先使用ecdhe密钥交换算法,因为它支持PFS(perfect forward secrecy),能够实现falsestart。
设置tls record size,最好是能动态调整record size,即连接刚建立时recordsize设置成msg,连接稳定之后可以将record size动态增加。
如果有条件的话可以启用tcp fast open。虽然现在没有什么客户端支持。
启用SPDY。SPDY是强制使用HTTPS的,协议比较复杂,需要单独的文章来分析。可以肯定的一点是使用SPDY的请求不仅明显提升了HTTPS速度,甚至比HTTP还要快。在无线WIFI环境下,SPDY比HTTP要快50ms左右,3G环境下比HTTP要快250ms。
3.2 HTTPS 对性能的影响
通过session cache和session ticket提升session reuse率,减少完全握手(fullhandshake)次数,提升简化握手(abbreviated handshake)率。
出于前向加密和falsestart的考虑,我们优先配置ecdhe用于密钥交换,但是性能不足的情况下可以将rsa配置成密钥交换算法,提升性能。
结论就是对称加密RC4的性能最快,但是RC4本身不安全,所以还是正常情况下还是采用AES。HASH函数MD5和SHA1差不多。数字签名是ecdsa算法最快,但是支持率不高。
4,HTTPS的支持率分析
tls协议版本客户端使用率握手时间 ms
tls 1.224.8)9.496
tls 1.10.9'9.383
tls 1.07407.077
ssl 3.00.3H4.564
加密套件客户端使用率握手时间
ECDHE-RSA-AES128-SHA58.5)4.36
ECDHE-RSA-AES128-SHA25621.103.065
DHE-RSA-AES128-SHA16.751.063
ECDHE-RSA-AES128-GCM-SHA2563.7'4.83
显然DHE对速度的影响比较大,ECDHE的性能确实要好出很多,而AES128-GCM对速度也有一点提升。
通过tcpdump分析client hello请求,发现有56.53%的请求发送了sessionid。也就意味着这些请求都能通过session cache得到复用。其他的一些扩展属性支持率如下:
tls扩展名支持率
server_name76.99%
session_tickets38.6%
next_protocol_negotiation40.54%
elliptic_curves 90.6%
ec_point_formats90.6%
这几个扩展都非常有意义,解释如下:
server_name,,即 sni (server name indicator),有77%的请求会在clienthello里面携带想要访问的域名,允许服务端使用一个IP支持多个域名。
next_protocol_negotiation,即NPN,意味着有40.54%的客户端支持spdy.
session_tickets只有38.6%的支持率,比较低。这也是我们为什么会修改nginx主干代码实现sessioncache多机共享机制的原因。
elliptic_curves即是之前介绍的ECC(椭圆曲线系列算法),能够使用更小KEY长度实现DH同样级别的安全,极大提升运算性能。
5,结论
原文地址:http://blog.sina.com.cn/s/blog_591c7a8f0102vdoa.html