阿里云 CDN HTTPS 最佳实践系列——动态证书(一)

背景

了解阿里云 CDN 架构的朋友应该知道,阿里云 CDN 7层的接入组件是 Tengine,我们知道 Tengine 原生是支持 SSL 的,只需要在配置文件中配置证书和私钥即可。在 CDN HTTPS 产品化以前,要开通 HTTPS 的域名需要把证书私钥给我们,我们在 Tengine 静态配置中配置,然后再同步到所有 CDN 边缘节点,显然这种方式在越来越多的域名开通 HTTPS 后,Tengine 静态配置文件会越来越大,难以管理,同时也会导致 Tengine reload 变得很慢,这样配置生效的时间就很糟糕,还有私钥安全等等一系列问题。所以 CDN HTTPS 产品化时就必须采用动态证书的方式,目前阿里云 CDN HTTPS 证书配置之后1分钟内生效,极大的提高了证书管理效率和用户体验。这两种方式的简单对比如下:

架构

动态配置的同步有两种方式:

  1. 主动同步
        当用户在用户控制台上配置证书和私钥之后主动向下同步到 CDN 所有节点的 Tengine 中,这样当配置同步成功后用户域名的 https 访问就正常了,但是这种方式有很多缺点,因为 Tengine 机器有几千台,甚至上万台,把证书私钥同步到这么多机器用时较大,生效时间较慢,另外其他一些域名并不是访问到所有的 CDN 机器,如果把证书私钥同步到这台机器并没有什么用,白白浪费内存,以及影响证书的搜索性能。这种方式适合在少量机器群集中使用。
  2. Lazy pull
        当 https 请求到达 Tengine 后,Tengine 再去拉取配置,这样就只拉取该机器有访问的域名配置,其他域名配置不需要拉取,解决了 Tengine 静态配置过多的问题,也避免了 Tengine reload,从而生效时间更快。

综合以上两种方式的优点,阿里云 CDN 在节点机房内部采用了 Lazy pull 方式拉取配置,在节点机房和中心机房之前采用主动同步的方式。以下是简化的 HTTPS 动态配置架构图。

实现

主动同步有很多种方式可以选择,比如 redis、zoomkeeper等等,这里只讲 Lazy pull 的实现,其关键技术是基于 Tengine 的指令 ssl_certificate_by_lua_file,这个指令是 lua-nginx 模块提供的,其用途就是在 openssl 中查找证书时的一个 lua 回调,然后在 lua 中动态设置证书和私钥。总之,如果 Tengine 的 server 块中配置了这个指令的话,当 openssl 在处理 SSL 握手消息 ClientHello 时会调用到这个指令配置的 lua 代码,在 lua 中我们可以做我们想做的事情,比如发 http 请求去远程拉取证书和私钥,做配置缓存,私钥加解密处理,动态设置证书和私钥等等一系列业务逻辑。

以下是 Tengine 的配置:

server {
    listen  0.0.0.0:443 default_server ssl http2;
    ssl_protocols                     TLSv1 TLSv1.1 TLSv1.2;
    #ssl_ciphers                      [xx];
    ssl_prefer_server_ciphers         on;
    ssl_certificate                   default.crt;
    ssl_certificate_key               default.key;
    ssl_certificate_by_lua_file       dycert.lua;
    include                           dyconf.cfg;
}

如上配置,dycert.lua 是阿里云 CDN 实现的动态证书模块,在 SSL 完整握手时会调用到这个模块,在 Session 复用的握手情况下不会调用到这个模块,这是因为 Session 复用时不需要证书和私钥,这是 openssl 回调接口的官方实现,但是阿里云 CDN 的实现中,还有很多 HTTPS 的动态配置需要在 dycert 模块中来设置,所以我们修改了 openssl,让其在 Session 复用时也调用到 dycert 模块,这为我们实现很多 HTTPS 动态配置(比如: HTTP/2 开关,客户端认证,TLS record size 配置)提供了方便。

如下图所示,dycert 模块是所有 HTTP(S) 业务模块的第一个重要模块,当 https 请求到达 CDN Tengine 时,dycert 模块会去远程拉取 HTTPS 动态配置(证书、私钥、HTTP/2 开关、客户端证书、TLS record size 配置等等),然后解密私钥,将证书和私钥设置到 openssl 中,让其恢复 SSL 握手流程。握手成功后会将该请求交给 Tengine 的后续业务模块处理。

下面是 dycert 模块的实现原理图:

众所周知,Tengine 是多 worker 的,我们需要使用共享内存来缓存拉取到的动态配置,这样可以防止多个 worker 进程同时去远程拉取同一份配置,并且在 worker 进程内存中也同时做了缓存以提高效率。

当一个 https 请求调用到 Tengine dycert 模块时,先在本 worker 缓存中查询是否存在配置,如果没有就去共享内存中查询,如果还是没有就得去远程拉取了(远程拉取采用 http 的 resty api 方式),拉取到动态配置之后在本 worker 中缓存,同时也在共享内存中缓存,为了防止共享内存暴增,加了一个定时器来删除该域名的配置,下次从共享内存中查询不到配置再重新从远程拉取。

另外一个重点就是配置的更新后如何实时生效了:配置管理系统 agent 是可以实时发现域名的配置变化的,并且提供了配置变更注册机制,dycert 会定时的去注册 HTTPS 配置变更,并提供一个 purge resty api,当配置管理系统 agent 发现配置更新之后会回调到该接口,然后该接口会从共享内存中删除该域名的配置,下次该域名的 https 请求到达 dycert 模块后,发现共享内存中没有配置会再去配置管理系统 agent 中拉取,从而解决了配置更新后实时生效的问题。

以上为本文内容。目前,阿里云CDN HTTPS已经全面降价,后付费HTTPS 0.05元/万次请求。为了迎接双11,预付费资源包也推出新购特惠:双十一当天30元购买1千万次HTTPS请求数资源包。欢迎大家登录双11会场进行选购。

下一篇我们将介绍HTTPS最佳实践——HTTP/2,敬请期待。

时间: 2024-08-04 00:18:03

阿里云 CDN HTTPS 最佳实践系列——动态证书(一)的相关文章

阿里云 CDN HTTPS 最佳实践系列——HTTP/2(二)

背景 HTTP/2 是最新的 HTTP 协议,已于2015年5月份正式发布,Chrome. IE11.Safari 以及 Firefox 等主流浏览器已经支持 HTTP/2 协议.阿里云 CDN 在2016年7月份开始全网支持 HTTP/2,是国内第一家全网支持 HTTP/2 的 CDN 提供商. HTTP/2 是新技术,一些底层代码库在实现时可能不完善,在一些特殊场景下可能就出问题,我们遇到过一些 android 库实现有问题,导致开启 HTTP/2 就经常访问失败,关闭 HTTP/2 就完全

阿里云 CDN HTTPS 最佳实践——动态密钥套件(三)

背景 在 ssllabs 中可以测试域名的 SSL 安全等级: 影响这个测试等级的最主要因素就是密钥套件,在接入阿里云 CDN 的所有域名中,绝大多数域名评级都是 A,但是有少数域名为了兼容一些老浏览器或者客户端,需要支持比如 RC4 这样的加密算法,这样就导致评级为 B,但用户体验更重要,这就需要为这些对密钥套件有特殊需求的域名特殊配置密钥套件. 另外,当我们调试 https 时,比如抓包分析数据包时,发现应用数据都是加密的,无法分析 HTTP 协议的问题,但是如果我们有私钥,那就有办法可以通

【满屏干货】阿里云CDN HTTPS最佳实践汇总

(一)动态证书 了解阿里云 CDN 架构的朋友应该知道,阿里云 CDN 7层的接入组件是 Tengine,我们知道 Tengine 原生是支持 SSL 的,只需要在配置文件中配置证书和私钥即可.在 CDN HTTPS 产品化以前,要开通 HTTPS 的域名需要把证书私钥给我们,我们在 Tengine 静态配置中配置,然后再同步到所有 CDN 边缘节点,显然这种方式在越来越多的域名开通 HTTPS 后,Tengine 静态配置文件会越来越大,难以管理,同时也会导致 Tengine reload 变

阿里云 CDN HTTPS 最佳实践——客户端证书认证(六)

背景 我们在使用 HTTPS 时经常接触到的是服务器证书认证(单向认证),很少用到客户端证书认证(双向认证),这是因为对于 web 网站来说,用户数目广泛,使用服务器证书认证就够了,无需在 SSL 层做用户身份验证,对于需要验证的页面再在应用逻辑层来做用户身份验证(比如常见的账号密码登录),使用客户端证书认证反而影响用户体验.但是对于一些特殊企业客户,在涉及到资金.股票等等金融业务交易时,考虑到其业务的安全性,他们在原有业务可能已经用了客户端证书认证,对于这类客户在接入 CDN 时,必然也要支持

阿里云 CDN HTTPS 最佳实践——TLS record size(五)

原理 TLS 协议由两层协议组成:TLS 握手协议和 TLS 记录协议(TLS Record),TLS Record 协议在 TLS 握手协议之下.下面是 SSL/TLS 的分层结构: 所有的 TLS 上层数据(包含 TLS 握手协议消息以及更上层的应用协议数据)都由 TLS Record 来封装和传输.下面是 TLS Record 协议的消息封装流程: 一个消息会在 TLS Record 协议层被分段,然后对每个分段分别压缩(已废弃)和加密,最后加上 TLS Record 协议头再通过网络层发

医疗大健康行业案例(老人健康实时监测和预警) - 阿里云RDS PostgreSQL最佳实践

标签 PostgreSQL , pipelineDB , 流式计算 , 独立事件相关性 , 舆情分析 , 实时状态分析 , 递归查询 , 时序数据 背景 人的身体和机器差不多,随着年龄的增长,器官逐渐老化,毛病也会越来越多,注意保养是一方面,另一方面也需要注意实时的监测和发出预警,在问题萌芽状态就解决掉. 以往我们检查身体得去医院或专业的体检机构,很麻烦,随着科技的进步,一些健康指标的监测变得更加方便,例如手环也是一个普及很快的监控检测终端(目前已能够检测心跳.温度.运动等各项指标),未来这种终

(新零售)商户网格化运营 - 阿里云RDS PostgreSQL最佳实践

标签 PostgreSQL , PostGIS , 地理位置 , KNN , 近邻检索 , 网格检索 , polygon中心点 , 半径搜索 背景 伟大的马老师说: "纯电商时代很快会结束,未来的十年.二十年,没有电子商务这一说,只有新零售这一说,也就是说线上线下和物流必须结合在一起,才能诞生真正的新零售" 线上是指云平台,线下是指销售门店或生产商,新物流消灭库存,减少囤货量. 电子商务平台消失是指,现有的电商平台分散,每个人都有自己的电商平台,不再入驻天猫.京东.亚马逊大型电子商务平

时间、空间、对象 海量极速多维检索 - 阿里云RDS PostgreSQL最佳实践

标签 PostgreSQL , 时间 , 空间 , 对象属性 , 多维度检索 , 海量 , 空间索引 , 数据分区 , 块级索引BRIN , 多级索引 , GIN倒排索引 , JSON索引 , 多列索引 , 多索引扫描合并 , bitmapAnd , bitmapOr , 物理扫描 , ctid扫描 , intersect , partial index , partition index 背景 人类或者其他对象的活动产生了海量的时间.空间数据,如果有科技能实现回到过去,过去的世界状态会是什么样

数据寻龙点穴(空间聚集分析) - 阿里云RDS PostgreSQL最佳实践

标签 PostgreSQL , Greenplum , PostGIS , K-Mean , 热力图 背景 最近鬼吹灯热播,胡八一的<十六字阴阳风水秘术>到底是什么武功秘籍?寻龙点穴又是什么?别问我,不知道. PS:截取自互联网.- 寻龙点穴是风水学术语.古人说:三年寻龙,十年点穴.意思就是说,学会寻龙脉要很长的时间,但要懂得点穴,并且点得准则难上加难,甚至须要用"十年"时间. 但是,若没正确方法,就是用百年时间,也不能够点中风水穴心聚气的真点,这样一来,寻龙的功夫也白费了