法学网站阵地建设,公司如何建设网站首页,大数据营销案例,红酒商城网站建设本文邀请阿里云CDN HTTPS技术专家金九#xff0c;分享Tengine的一些HTTPS实践经验。内容主要有四个方面#xff1a;HTTPS趋势、HTTPS基础、HTTPS实践、HTTPS调试。 一、HTTPS趋势 这一章节主要介绍近几年和未来HTTPS的趋势#xff0c;包括两大浏览器chrome和firefox对HTTPS的… 本文邀请阿里云CDN HTTPS技术专家金九分享Tengine的一些HTTPS实践经验。内容主要有四个方面HTTPS趋势、HTTPS基础、HTTPS实践、HTTPS调试。 一、HTTPS趋势 这一章节主要介绍近几年和未来HTTPS的趋势包括两大浏览器chrome和firefox对HTTPS的态度以及淘宝天猫和阿里云CDN的HTTPS实践情况。 上图是 chrome 统计的HTTPS网页占比的趋势2015年的时候大多数国家的HTTPS网页加载次数只占了不到 50%2016年美国这个占比到了将近60%去年就已经超过 70%目前已经超过 80%。最下面是日本目前是60%左右这里面没有统计到中国的数据我估计中国的占比会更少空间还有很大但未来HTTPS趋势是明显的。 同样Firefox 浏览器加载HTTPS网页的统计跟 chrome 差不多全球 HTTPS网页加载占比在 70% 左右上升趋势也很明显。 更值得关注的是Google 在今年年初的时候在其安全博客上表明在今年7月份左右发布的 chrome68 浏览器会将所有HTTP网站标记为不安全现在是5月份底了离这个时间也就一个多月的时间了。右边的截图可以看出本来是绿色的小锁变成了不安全这种网页在输入密码时就很不安全了。 早期天猫淘宝只是在关键的登录和交易的环节上了HTTPS但随着互联网的发展劫持、篡改等等问题也越来越严重试想在天猫淘宝上看的商品图片被恶意人替换了或者价格被篡改了会怎么样这样用户、商家和平台都受到伤害只有上了 HTTPS才能从根本上解决这些问题。所以天猫和淘宝在2015年7月份的时候已经完成了全站HTTPS。 二、HTTPS基础 本章节主要介绍HTTPS为什么安全包括对称加密、非对称加密、签名、证书证书链、SSL是怎么握手的、以及私钥密钥在HTTPS中发挥什么样的作用、keyless又是解决什么样的问题等等。 HTTPS的定义 简单来讲HTTPS就是安全的HTTP我们知道HTTP是运行在TCP层之上的HTTPS在HTTP层和TCP层之间加了一个SSL层SSL向上提供加密和解密的服务对HTTP比较透明这样也便于服务器和客户端的实现以及升级。 HTTPS为什么安全 HTTPS安全是由一套安全机制来保证的主要包含这4个特性机密性、完整性、真实性和不可否认性。 机密性是指传输的数据是采用Session Key会话密钥加密的在网络上是看不到明文的。完整性是指为了避免网络中传输的数据被非法篡改使用MAC算法来保证消息的完整性。真实性是指通信的对方是可信的利用了PKIPublic Key Infrastructure 即『公钥基础设施』来保证公钥的真实性。不可否认性是这个消息就是你给我发的无法伪装和否认是因为使用了签名的技术来保证的。对称加密和非对称加密 HTTPS有对称加密和非对称加密两种算法目的都是把明文加密成密文区别是密钥的个数不一样对称加密是一把密钥这把密钥可以加密明文也可以解密加密后的密文常见的对称加密算法有AES、DES、RC4目前最常用的是AES。 非对称加密是两把密钥分别是公钥和私钥公钥加密的密文只有相对应的私钥才能解密私钥加密的内容也只有相对应的公钥才能解密其中公钥是公开的私钥是自己保存不能公开常见的非对称加密算法有RSA和ECC椭圆曲线算法。 SSL结合了这两种加密算法的优点通过非对称加密来协商对称加密的密钥握手成功之后便可使用对称加密来做加密通信对于RSA来说客户端是用RSA的公钥把预主密钥加密后传给服务器服务器再用私钥来解密双方再通过相同的算法来生成会话密钥之后的应用层数据就可以通过会话密钥来加密通信。 签名 SSL中还有一个使用非对称加密的地方就是签名签名的目的是让对方相信这个数据是我发送的而不是其他人发送的。 密钥安全强度与性能对比 加密之后的数据破解难度就体现在密钥的长度上密钥越长破解难度也越大但是运算的时间也越长性能也就越差。相同安全强度下对称密钥长度在最短ECC次之RSA密钥长度则最长。 目前比较常用的密钥长度是对称密钥128位、ECC 256位、RSA 2048位。 RSA和ECC在SSL中更多的是用来签名通过测试发现ECC 的签名性能比RSA好很多但是RSA的验签性能比ECC更好所以RSA更适合于验证签名频繁而签名频度较低的场景ECC更适合于签名频繁的场景在SSL场景中ECC算法性能更好。 公钥基础设施PKI 简单的说PKI就是浏览器和CACA是整个安全机制的重要保障我们平时用的证书就是由CA机构颁发其实就是用CA的私钥给用户的证书签名然后在证书的签名字段中填充这个签名值浏览器在验证这个证书的时候就是使用CA的公钥进行验签。 证书 那CA在PKI中又是怎样发挥作用的呢首先CA的作用就是颁发证书颁发证书其实就是使用CA的私钥对证书请求签名文件进行签名其次CA颁发的证书浏览器要信任浏览器只需要用CA的公钥进行验签成功就表示这个证书是合法可信的这就需要浏览器内置CA的公钥也就是内置CA的证书。一般来说操作系统都会内置权威CA的证书有的浏览器会使用操作系统内置的CA证书列表有的浏览器则自己维护的CA证书列表比如Firefox。 CA分为根CA二级CA三级CA三级CA证书由二级CA的私钥签名二级CA证书由根CA的私钥签名根CA是自签名的不会给用户证书签名我们平时用的证书都是由二级CA或者三级CA签名的这样就形成了一个证书链浏览器在验签的时侯一层层往上验证直到用内置的根CA证书的公钥来验签成功就可以表示用户证书是合法的证书。 根证书已经内置在浏览器或者操作系统里了在SSL握手时就不需要发根CA证书了只需要提供中间二级三级CA证书和用户证书就可以。 交叉证书 交叉证书的应用场景是这样的假如现在阿里云成为一个新的根CA机构那阿里云签发的证书想要浏览器信任的话阿里云的根证书就需要内置在各大操作系统和浏览器中这需要较长时间的部署那在没有完全部署完成之前阿里云签发的证书怎么才能让浏览器信任呢这就需要用到交叉证书了。 上图中根证书A是一个所有浏览器都内置了的根证书B是一个新的根证书用户证书D是由根证书 B的二级CA B1来签发的但是根证书B并没有在浏览器中内置所以浏览器不会信任用户证书D这是因为浏览器在验签时只验证到B1这一层然后找不到根证书B就无法验证下去了。 如果二级CA B1证书是由根证书A来签名那这个问题就解了所以新的根证书机构B会将二级CA证书准确地讲是二级CA的证书签名请求文件给老的根证书A来签名然后得到一个新的中间证书就是交叉证书。 浏览器在验证的时侯用了新的信任链这样就可以解决用户证书的信任问题。 当B的根证书全部部署完成后再替换成自己的二级CA就可以了。 证书分类 证书分有三类DV、OV、EV DV证书只校验域名的所有权所以我们在申请DV证书的时候CA会提供几种验证域名所有权的方法比如文件校验、DNS校验、邮件校验DV证书支持单域名、多域名和泛域名但不支持多个泛域名只支持一个泛域名一般价格比较便宜具体价格跟域名的数量有关域名越多价格越高。 OV证书要验证组织机构在申请证书时CA会打电话确认这个域名是否真的属于相应的公司或者机构OV证书是单域名、多域名、泛域名和多个泛域名都支持价格一般比DV证书要贵。 EV证书的校验就更细了比如组织机构的地址之类的EV证书会在地址栏上显示组织机构的名称EV证书只支持单域名或者多个域名不支持泛域名而且更贵所以普通用户一般不会用EV证书。 证书吊销 证书是有生命周期的如果证书的私钥泄漏了那这个证书就得吊销一般有两种吊销方式CRL和OCSP。 CRL是CA机构维护的一个已经被吊销的证书序列号列表浏览器需要定时更新这个列表浏览器在验证证书合法性的时候也会在证书吊销列表中查询是否已经被吊销如果被吊销了那这个证书也是不可信的。可以看出这个列表随着被吊销证书的增加而增加列表会越来越大浏览器还需要定时更新实时性也比较差。 所以后来就有了 OCSP 在线证书状态协议这个协议就是解决了 CRL 列表越来越大和实时性差的问题而生的。有了这个协议浏览器就可以不用定期更新CRL了在验证证书的时候直接去CA服务器实时校验一下证书有没有被吊销就可以是解决了CRL的问题但是每次都要去CA服务器上校验也会很慢在网络环境较差的时候或者跨国访问的时候体验就非常差了OCSP虽然解决了CRL的问题但是性能却很差。所以后来就有了OCSP stapling。 OCSP stapling主要解决浏览器OCSP查询性能差的问题本来由浏览器去CA的OCSP服务器查询证书状态的现在改由域名的服务器去查询将OCSP的结果告诉浏览器即可一般服务器的网络性能要好于用户电脑的网络所以OCSP stapling的性能是最好的。但是并不是所有的服务器都支持OCSP stapling所以目前浏览器还是比较依赖CRL证书吊销的实时性要求也不是特别高所以定期更新问题也不大。 HTTPS工作模式 对于客户端和服务器来讲应用层协议还是HTTP只是加了一个SSL层来做加密解密的逻辑对应用层来说是透明的在网络上传输的都是加密的请求和加密的响应从而达到安全传输的目的。 这是SSL层在网络模型的位置SSL属于应用层协议。接管应用层的数据加解密并通过网络层发送给对方。 更细地分SSL协议分握手协议和记录协议握手协议用来协商会话参数比如会话密钥、应用层协议等等记录协议主要用来传输应用层数据和握手协议消息数据以及做加解密处理。我们应用层的的消息数据在SSL记录协议会给分成很多段然后再对这个片段进行加密最后在加上记录头后就发送出去。 TLS握手协议 SSL/TLS 握手协议又细分为四个子协议分别是握手协议、密码规格变更协议、警告协议和应用数据协议。 完整的握手流程 首先是TCP握手TCP三次完成之后才进入SSL握手SSL握手总是以ClientHello消息开始就跟TCP握手总是以SYN包开始一样 ClientHello主要包含客户端支持的协议、密钥套件、session id、客户端随机数、sni、应用层协议列表http/1.1、h2、签名算法等等 服务器收到ClientHello之后会从中选取本次通信的协议版本、密钥套件、应用层协议、签名算法以及服务器随机数然后通过ServerHello消息响应如果没有session复用那将服务器的证书通过Certificate消息响应如果是选用了ECC算法来做密钥交换的话那还会将椭圆曲线参数以及签名值通过ServerKeyExchange消息发送给对方最后通过ServerHelloDone消息来结束本次协商过程 客户端收到这些消息之后会生成预主密钥、主密钥和会话密钥然后将椭圆曲线参数通过ClientKeyExchange发送给服务器服务器拿到客户端的椭圆曲线参数也会生成预主密钥如果是RSA的话ClientKeyExchange用来发送公钥加密的预主密钥服务器用私钥来解密一下就可以得到预主密钥再由预主密钥生成主密钥和会话密钥。最后双方都以ChangeCipherSpce和Finished消息来告知对方自己已经准备好了可以进行加密通信了然后握手完成。 可以看出完整的SSL握手需要2个RTT而且每次握手都用到了非对称加密算法签名或者解密的操作比较耗CPU所以后来就有了session复用的优化手段后面会做介绍。 SSL的握手消息虽然比较多但很多消息都是放在一个TCP包中发送的从抓包可以看出完整的SSL握手需要2个RTT。 刚才通过完整的SSL握手可以看出几个缺点 1、2个RTT首包时间较长 2、每次都要做非对称加密比较耗CPU影响性能 3、每次都要传证书证书一般都比较大浪费带宽 SSL握手的目的是协商会话密钥以及参数如果能把这些会话参数缓存那就可以没有必要每次都传证书和做非对称加密计算这样就可以提高握手性能而且可以将RTT减到1个提高用户体验。 所以就有了session id的复用方式每次完整握手之后都将协商好的会话参数缓存在服务器中客户端下次握手时会将上次握手的session id带上服务器通过session id查询是否有会话缓存有的话就直接复用没有的话就重新走完整握手流程。但是session id这种方式也有缺点比较难支持分布式缓存以及耗费服务器的内存。 而session ticket 方案其原理可以理解为跟 http cookie 一样服务器将协商好的会话参数加密成 session ticket然后发送给客户端客户端下次握手时会将这个session ticket带上服务器解密成功就复用上次的会话参数否则就重新走完整握手流程。可以看出session ticket这种方式不需要服务器缓存什么支持分布式环境有很大的优势。这种方式有一个缺点是并不是所有客户端都支持支持率比较低但随着客户端版本的更新迭代以后各种客户端会都支持。因为session id客户端支持率比较高所以目前这两种方式都在使用。 这是 session ticket 的复用跟 session id 的区别是 client hello 会带上 Session ticket 将近200个字节的加密数据服务器会用session ticket 密钥来解密解密成功则直接复用也简化了握手流程提升效率和性能。 这是我们上了分布式 Session id 复用的效果session id复用的比例在没有开启分布式缓存时只占了3%左右复用率很低上了分布式session缓存之后这个比例提升到20%多。握手时间也从75ms左右降低到65ms左右性能提升效果还是很明显的。 SSL/TLS握手时的私钥用途RSA、ECDHE 我们知道私钥是整个SSL中最重要的东西那私钥在SSL握手里面又是怎么使用的呢两种使用方式分别是使用RSA来做密钥交换和使用ECDHE来做密钥交换。对于RSA来说客户端生成预主密钥然后用公钥加密再发给服务器服务器用私钥来解密得到预主密钥然后由预主密钥生成主密钥再由主密钥生会话密钥最后用会话密钥来通信。 对于ECDHE来说客户端和服务器双方是交换椭圆曲线参数私钥只是用来签名这是为了保证这个消息是持有私钥的人给我发的而不是冒充的。双方交换完参数之后生成预主密钥再生成主密钥和会话密钥。这就跟刚才RSA后面的流程一样了。 可以看出RSA和椭圆曲线密钥交换算法的私钥用途是不一样的RSA密钥交换时是用来做加解密的椭圆曲线密钥交换时是用来做签名的。 SSL/TLS中的密钥 预主密钥、主密钥和会话密钥这几个密钥都是有联系的。 对于RSA来说预主密钥是客户端生成加密之后发给服务器服务器用私钥来解密。对于ECDHE来说预主密钥是双方通过椭圆曲线算法来生成。 主密钥是由预主密钥、客户端随机数和服务器随机数通过PRF函数来生成会话密钥是由主密钥、客户端随机数和服务器随机数通过PRF函数来生成会话密钥里面包含对称加密密钥、消息认证和CBC模式的初始化向量但对于非CBC模式的加密算法来说就没有用到这个初始化向量。 session 缓存和session ticket里面保存的是主密钥而不是会话密钥这是为了保证每次会话都是独立的这样才安全即使一个主密钥泄漏了也不影响其他会话。 Keyless 刚才提到RSA和ECDHE的私钥用途对于服务器来说密钥交换算法是RSA时私钥是用来做解密的ECDHE时私钥是用来签名的。 Keyless就是将私钥参与运算的部分分离远程服务器这样可以解决两个问题 1公私钥分离用户不需要将私钥给第三方减少私钥泄露的风险。 2将非对称加密运算这种cpu密集型运算剥离到keyserver可以在keyserver中安装ssl加速卡做硬件加速提高性能。 HTTP/2 HTTP/2主要有这几个特性 一、二进制协议可以做更多的优化 二、多路复用一定程度上解决了队头阻塞的问题提高并发和总的加载时间 三、头部压缩很多请求头或者响应头都没有必要重复传输浪费带宽比如user-agent、cookie还有其他没有必要每次都传的头部在http2中都做了优化 四、安全虽然RFC规定HTTP/2可以运行在明文之上但目前所有浏览器都只支持https之上的http/2所以是安全的。 开启HTTP/2会有这几个收益 一、加载时间的提升我们做了这么一个测试一张大图片分割成几百个小图片然后用http/1.1和http/2打开http/1.1加载完所有小图片用了五六秒但http/2加载完所有小图片只需要不到1s的时间有5倍左右的提升效果还是很明显的具体提升百分之多少这得具体看具体的业务类型。 二、头部压缩有95%左右的提升http/1.1的平均响应头大小有500个字节左右而http/2的平均响应头大小只有20多个字节提升非常大所以http/2非常适合小图片小文件的业务类型因为小文件的http头部比重较大而http/2对头部的压缩做了非常好的优化。 三、服务器QPS的性能有60%多的提升这是因为http/2的连接复用和多路复用机制可以处理更多的并发请求。 三、HTTPS实践 本章节会重点给大家讲讲 Tengine 如何配置 https、HTTP/2、TLSv1.3以及如何实现动态证书。 Tengine如何开启HTTPS http{ ssl_session_tickets on; ssl_session_ticket_key ticket.key; server {
listen 443 ssl; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers
EECDHCHACHA20:EECDHCHACHA20-draft:EECDHECDSAAES128:EECDHaRSAAES128:RSAAES128:EECDHECDSAAES256:EECDHaRSAAES256:RSAAES256:EECDHECDSA3DES:EECDHaRSA3DES:RSA3DES:!MD5;ssl_prefer_server_ciphers on; ssl_certificate www.alicdn.com.crt;
ssl_certificate_key www.alicdn.com.key; ssl_session_cache
shared:SSL:256M; ssl_session_timeout 15m; #…… }} 在Tengine中开启http2只需要在listen的后面加上http2参数就可以了。 但是有一个场景需要注意因为有些域名并不想开启http2比如上面这个配置的b.com并不想开http2但是因为a.com开启了http2所以b.com也被自动开启了这是因为http2这个参数作用在ip和端口上在ssl握手时用了a.com的配置参数所以tengine针对这种情况做了一个域名级别的开关来做控制。 TLSv1.3——更快、更安全 1、1-RTT 0-RTT 2、只支持完全前向安全性的密钥交换算法 3、ServerHello 之后的所有消息都是加密的 4、淘汰 Session ID 和 Session Ticket用 PSK 代替 5、Chrome 63, Firefox 58 Tengine也支持了TLSv1.3开启方式 server{ ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; ssl_ciphers
TLS13-AES-128-GCM-SHA256:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-256-GCM-SHA384:TLS13-AES-128-CCM-8-SHA256:TLS13-AES-128-CCM-SHA256:EECDHCHACHA20:EECDHCHACHA20-draft:EECDHECDSAAES128:EECDHaRSAAES128:RSAAES128:EECDHECDSAAES256:EECDHaRSAAES256:RSAAES256:EECDHECDSA3DES:EECDHaRSA3DES:RSA3DES:!MD5;#……} Tengine 实现与配置动态证书 动态证书主要解决的问题是接入域名太多server块过多导致tengine reload慢的问题lua-nginx模块提供了一个证书的lua阶段可以在这个阶段来做证书的热加载不需要reload tengine这样可以提高效率和性能。 配置也比较简单在ssl_cert.lua里面做证书的管理在ssl握手时拿到sni去拿这个域名的证书和私钥再调用lua ffi接口就可以完成证书和私钥的切换。 ssl_cert.lua: 调用 lua ffi 接口设置证书和私钥 四、HTTPS调试 我们知道HTTP是明文传输调试就很简单抓包就可以看得清清楚楚但HTTPS是加密的抓包看到的是密文这一节我告诉大家怎么去解密HTTPS抓包文件。 抓包解密 方法一 配置Wireshark Wireshark preferences… Protocols SSL (Pre)-Master-Secret log filename /tmp/sslkey.txt 一 export SSLKEYLOGFILE/tmp/sslkey.txt 二 openssl s_client -connect 127.0.0.1:443 -servername www.alicdn.com -keylogfile /tmp/sslkey.txt 三 echo“CLIENT_RANDOM
7EC0498BCF09E8300A1E9F8BA6C81E2A4383D7CDCFB10907B4074520FA8DF680
FA2457782F6FAECE47CF8E01BF9E0A441CEA8DCC91664F42F45F1EF5AB18ED902E35825713FF2D4D9651CE51ED885BB4”/tmp/sslkey.txt 方法二 强制使用RSA密钥交换算法Wireshark配置私钥。 抓包解密-wireshark设置 常用命令及参数 curl 写在最后 证书的购买和申请是非常复杂耗时的为了缩短开通周期为开发者提供最大化便利简化HTTPS加速设置环节目前阿里云CDN已经支持控制台可实现一键开通HTTPS后台将完成代理免费证书购买、证书节点部署以及证书到期之前自动续签帮助开发者更便捷的完成全站HTTPS访问加速。 转自 阿里云技术专家金九Tengine HTTPS原理解析、实践与调试 https://www.toutiao.com/i6561389530765591047/ 转载于:https://www.cnblogs.com/paul8339/p/9121975.html
