从gRPC安全设计理解双向证书方案

  • A+
所属分类:安全闲碎


  • 序言

  • 安全需求

  • 安全方案

    • 敏感数据加密传输

    • 认证

    • 鉴权

    • 数据完整性和一致性

  • 证书的基本原理

    • 单向证书

    • 双向证书

  • gRPC安全机制

    • SSL/TLS认证

    • GoogleOAuth2.0

    • 自定义安全认证策略

序言

网络安全领域在攻和防对抗规模群体已经成熟,但是两端从业者对于安全原理掌握程度参差不齐,中间鸿沟般的差距构成了漏洞研究领域的主战场。笔者“三省吾身”,在工作中会犯错误把一些加密、认证、鉴权的概念和实现方案搞混,尤其是加解密涉及算法和公私钥机制的概念不深入细节。

最近的几个影响颇大的安全漏洞,Apache Shiro 权限绕过漏洞、CVE-2020-14882weblogic 绕过登录、微软ZeroLogon,这些漏洞原理的共同点都是和基本的安全算法、认证鉴权方案缺陷有关。也许未来的漏洞攻防将转移到安全基础领域的对抗,从业人员除了要求推进安全方案的必要性,涉及安全建设的可用性更为重要,所以特此开专栏系列,为大家普及一些安全基本功。

本文主要通过介绍gRPC的双向认证方案,理清证书领域的知识。

安全需求

RPC是一种技术思想,实现有阿里的 Dubbo/SOFA、Google gRPC、Facebook 的 Thrift,实现时的远程通信规范和协议可以用RMI、Socket、SOAP(HTTP XML)、REST(HTTP JSON)。这种服务间通信机制为企业内部各系统、模块之间的微服务和接口之间互相调用,RPC实现需要考虑安全性,RPC 调用安全主要涉及如下三点:

  1. 个人 / 企业敏感数据加密:例如针对个人的账号、密码、手机号等敏感信息进行加密传输,打印接口日志时需要做数据模糊化处理等,不能明文打印;

  2. 对调用方的身份认证:调用来源是否合法,是否有访问某个资源的权限,防止越权访问;

  3. 数据防篡改和完整性:通过对请求参数、消息头和消息体做签名,防止请求消息在传输过程中被非法篡改。

安全方案

常见的安全攻防重视rpc协议的反序列漏洞,但是如果业务方问道如果做以上的安全需求,SDL同学就傻眼了,正确的做法是区分加密传输、认证、鉴权、数据完整性和一致性四个方向:

敏感数据加密传输

基于SSL/TLS的通道加密

当存在跨网络边界的 RPC 调用时,往往需要通过 TLS/SSL 对传输通道进行加密,以防止请求和响应消息中的敏感数据泄漏。跨网络边界调用场景主要有三种:

  1. 后端微服务直接开放给端侧,例如手机 App、TV、多屏等,没有统一的 API 网关/SLB 做安全接入和认证;
  2. 后端微服务直接开放给 DMZ 部署的管理或者运维类 Portal;
  3. 后端微服务直接开放给第三方合作伙伴 / 渠道。

除了跨网络之外,对于一些安全等级要求比较高的业务场景,即便是内网通信,只要跨主机 /VM/ 容器通信,都强制要求对传输通道进行加密。在该场景下,即便只存在内网各模块的 RPC 调用,仍然需要做 SSL/TLS。

使用 SSL/TLS 的典型场景如下所示:从gRPC安全设计理解双向证书方案

通道加密的的实现技术难度稍大,对性能有损耗,定制化程度高,但是效果显著,建设收益明显

针对敏感数据的单独加密

有些 RPC 调用并不涉及敏感数据的传输,或者敏感字段占比较低,为了最大程度的提升吞吐量,降低调用时延,通常会采用 HTTP/TCP + 敏感字段单独加密的方式,既保障了敏感信息的传输安全,同时也降低了采用 SSL/TLS 加密通道带来的性能损耗,对于 JDK 原生的 SSL 类库,这种性能提升尤其明显。

它的工作原理如下所示:

从gRPC安全设计理解双向证书方案
敏感数据加密

通常使用 Handler 拦截机制,对请求和响应消息进行统一拦截,根据注解或者加解密标识对敏感字段进行加解密,这样可以避免侵入业务。

采用该方案的缺点主要有两个:

  • 对敏感信息的识别可能存在偏差,容易遗漏或者过度保护,需要解读数据和隐私保护方面的法律法规,而且不同国家对敏感数据的定义也不同,这会为识别带来很多困难;
  • 接口升级时容易遗漏,例如开发新增字段,忘记识别是否为敏感数据。

认证

内部 RPC 调用的身份认证场景,主要有如下两大类:

  • 防止对方知道服务提供者的地址之后,绕过注册中心 / 服务路由策略直接访问 RPC 服务提供端;
  • RPC 服务只想供内部模块调用,不想开放给其它业务系统使用(双方网络是互通的)。

身份认证的方式较多,例如 HTTP Basic Authentication、OAuth2 等,比较简单使用的是令牌认证(Token)机制,它的工作原理如下所示:从gRPC安全设计理解双向证书方案

工作原理如下:

  • RPC 客户端和服务端通过 HTTPS 与注册中心连接,做双向认证,以保证客户端和服务端与注册中心之间的安全;
  • 服务端生成 Token 并注册到注册中心,由注册中心下发给订阅者。通过订阅 / 发布机制,向 RPC 客户端做 Token 授权;
  • 服务端开启身份认证,对 RPC 调用进行 Token 校验,认证通过之后才允许调用后端服务接口。

鉴权

身份认证可以防止非法调用,如果需要对调用方进行更细粒度的权限管控,则需要做对 RPC 调用做鉴权。例如管理员可以查看、修改和删除某个后台资源,而普通用户只能查看资源,不能对资源做管理操作。

在 RPC 调用领域比较流行的是基于 OAuth2.0 的权限认证机制,它的工作原理如下:从gRPC安全设计理解双向证书方案

OAuth2.0 的认证流程如下:

  • 客户端向资源拥有者申请授权(例如携带用户名 + 密码等证明身份信息的凭证);
  • 资源拥有者对客户端身份进行校验,通过之后同意授权;
  • 客户端使用步骤 2 的授权凭证,向认证服务器申请资源访问令牌(access token);
  • 认证服务器对授权凭证进行合法性校验,通过之后,颁发 access token;
  • 客户端携带 access token(通常在 HTTP Header 中)访问后端资源,例如发起 RPC 调用;
  • 服务端对 access token 合法性进行校验(是否合法、是否过期等),同时对 token 进行解析,获取客户端的身份信息以及对应的资源访问权限列表,实现对资源访问权限的细粒度管控;
  • access token 校验通过,返回资源信息给客户端。

步骤 2 的用户授权,有四种方式:

  • 授权码模式(authorization code)
  • 简化模式(implicit)
  • 密码模式(resource owner password credentials)
  • 客户端模式(client credentials)

需要指出的是,OAuth 2.0 是一个规范,不同厂商即便遵循该规范,实现也可能会存在细微的差异。大部分厂商在采用 OAuth 2.0 的基础之上,往往会衍生出自己特有的 OAuth 2.0 实现。

对于 access token,为了提升性能,RPC 服务端往往会缓存,不需要每次调用都与 AS 服务器做交互。同时,access token 是有过期时间的,根据业务的差异,过期时间也会不同。客户端在 token 过期之前,需要刷新 Token,或者申请一个新的 Token。

考虑到 access token 的安全,通常选择 SSL/TLS 加密传输,或者对 access token 单独做加密,防止 access token 泄漏。

关于oauth作为安全基本功系列今后还会有专栏。

数据完整性和一致性

RPC 调用,除了数据的机密性和有效性之外,还有数据的完整性和一致性需要保证,即如何保证接收方收到的数据与发送方发出的数据是完全相同的。

利用消息摘要可以保障数据的完整性和一致性,它的特点如下:

  1. 单向 Hash 算法,从明文到密文的不可逆过程,即只能加密而不能解密;
  2. 无论消息大小,经过消息摘要算法加密之后得到的密文长度都是固定的;
  3. 输入相同,则输出一定相同。

目前常用的消息摘要算法是 SHA-1、MD5 和 hmac,MD5 可产生一个 128 位的散列值。SHA-1 则是以 MD5 为原型设计的安全散列算法,可产生一个 160 位的散列值,安全性更高一些。hmac 除了能够保证消息的完整性,还能够保证来源的真实性。

由于 MD5 已被发现有许多漏洞,在实际应用中更多使用 SHA 和 hmac,而且往往会把数字签名和消息摘要混合起来使用。微信支付、阿里云调用是大家常用的签名机制,注意消息摘要不是加密,不是加密,不是加密。

证书的基本原理

目前使用最广的 SSL/TLS 工具 / 类库就是 OpenSSL,它是为网络通信提供安全及数据完整性的一种安全协议,囊括了主要的密码算法、常用的密钥和证书封装管理功能以及 SSL 协议。注意SSL和TLS有不同的历史和标准,HTTPS的意思是HTTP +SSL/ TLS,现在的安全方案一般是tls实现,SSL标准正被淘汰。只是因为沿袭历史称呼,所以经常混用两次名词, SSL被发现存在过 POODLE, DROWN协议算法本身的漏洞,注意区分大名鼎鼎的心脏滴血漏洞Heartbleed是OpenSSL的实现TLS和DTLS的心跳处理逻辑时有bug,而不是利用SSL/TLS协议本身的缺陷。

单向证书

https是大家最熟悉的单项证书方案,由浏览器、ca中心、服务端三方实现。单向认证的过程,客户端从服务器端下载服务器端公钥证书进行验证,然后建立安全通信通道。单向认证流程中,服务器端保存着公钥证书和私钥两个文件,整个握手过程如下:

从gRPC安全设计理解双向证书方案
单向认证流程
  1. 客户端发起建立HTTPS连接请求,将SSL协议版本的信息发送给服务器端;
  2. 服务器端将本机的公钥证书(server.crt)发送给客户端;
  3. 客户端读取公钥证书(server.crt),取出了服务端公钥;
  4. 客户端生成一个随机数(密钥R),用刚才得到的服务器公钥去加密这个随机数形成密文,发送给服务端;
  5. 服务端用自己的私钥(server.key)去解密这个密文,得到了密钥R
  6. 服务端和客户端在后续通讯过程中就使用这个密钥R进行通信了。

双向证书

双向通信流程,客户端除了需要从服务器端下载服务器的公钥证书进行验证外,还需要把客户端的公钥证书上传到服务器端给服务器端进行验证,等双方都认证通过了,才开始建立安全通信通道进行数据传输。

从gRPC安全设计理解双向证书方案
双向认证流程
  1. 客户端发起建立HTTPS连接请求,将SSL协议版本的信息发送给服务端;
  2. 服务器端将本机的公钥证书(server.crt)发送给客户端;
  3. 客户端读取公钥证书(server.crt),取出了服务端公钥;
  4. 客户端将客户端公钥证书(client.crt)发送给服务器端;
  5. 服务器端解密客户端公钥证书,拿到客户端公钥;
  6. 客户端发送自己支持的加密方案给服务器端;
  7. 服务器端根据自己和客户端的能力,选择一个双方都能接受的加密方案,使用客户端的公钥加密后发送给客户端;
  8. 客户端使用自己的私钥解密加密方案,生成一个随机数R,使用服务器公钥加密后传给服务器端;
  9. 服务端用自己的私钥去解密这个密文,得到了密钥R
  10. 服务端和客户端在后续通讯过程中就使用这个密钥R进行通信了。

整个双向认证的流程跑通,最终需要五个证书文件:

  • 服务器端公钥证书:server.crt
  • 服务器端私钥文件:server.key
  • 客户端公钥证书:client.crt
  • 客户端私钥文件:client.key
  • 客户端集成证书(包括公钥和私钥,用于浏览器访问场景):client.p12

生成这一些列证书之前,我们需要先生成一个CA根证书,然后由这个CA根证书颁发服务器公钥证书和客户端公钥证书。

从gRPC安全设计理解双向证书方案
证书生成

证书实现的核心是加密,但是也可以被用来做认证,比如istio实现展示了如何用双向证书解决身份、通讯安全,:服务器身份(Server identities)被编码在证书里,但服务名称(service names)通过服务发现或 DNS 被检索。安全命名信息将服务器身份映射到服务名称。身份 A 到服务名称 B 的映射表示“授权 A 运行服务 B“。在双向 TLS 握手期间,客户端Envoy做了安全命名检查,以验证服务器证书中显示的服务帐户是否被授权运行目标服务。

gRPC安全机制

谷歌提供了可扩展的安全认证机制,以满足不同业务场景需求,它提供的授权机制主要有四类:

  • 通道凭证:默认提供了基于 HTTP/2 的 TLS,对客户端和服务端交换的所有数据进行加密传输;
  • 调用凭证:被附加在每次 RPC 调用上,通过 Credentials 将认证信息附加到消息头中,由服务端做授权认证;
  • 组合凭证:将一个频道凭证和一个调用凭证关联起来创建一个新的频道凭证,在这个频道上的每次调用会发送组合的调用凭证来作为授权数据,最典型的场景就是使用 HTTP S 来传输 Access Token;
  • Google 的 OAuth 2.0:gRPC 内置的谷歌的 OAuth 2.0 认证机制,通过 gRPC 访问 Google API 时,使用 Service Accounts 密钥作为凭证获取授权令牌。

SSL/TLS认证

用go语言显示下服务端和客户端的调用过程:

服务端使用了证书文件

func main() {
    lis, err := net.Listen("tcp", port)
    if err != nil {
        log.Fatalf("failed to listen: %v", err)
    }
    // create the TLS credentials from files
    creds, err := credentials.NewServerTLSFromFile("../cert/server.crt""../cert/server.key")
    if err != nil {
        log.Fatalf("could not load TLS keys: %s", err)
    }
    // create a gRPC option array with the credentials
    opts := []grpc.ServerOption{grpc.Creds(creds)}
    // create a gRPC server object with server options(opts)
    s := grpc.NewServer(opts...)
    pb.RegisterSimpleMathServer(s, &rpcimpl.SimpleMathServer{})
    reflection.Register(s)
    if err := s.Serve(lis); err != nil {
        log.Fatalf("failed to serve: %v", err)
    }
}

客户端使用

func GreatCommonDivisor(first, second string) {
    // create the client TLS credentials
    creds, err := credentials.NewClientTLSFromFile("../cert/server.crt""")
    // initiate a connection with the server using creds
    conn, err := grpc.Dial(address, grpc.WithTransportCredentials(creds))
    if err != nil {
        log.Fatalf("did not connect: %v", err)
    }
    defer conn.Close()
    c := pb.NewSimpleMathClient(conn)
    a, _ := strconv.ParseInt(first, 1032)
    b, _ := strconv.ParseInt(second, 1032)
    ctx, cancel := context.WithTimeout(context.Background(), time.Second)
    defer cancel()
    r, err := c.GreatCommonDivisor(ctx, &pb.GCDRequest{First: int32(a), Second: int32(b)})
    if err != nil {
        log.Fatalf("cound not compute: %v", err)
    }
    log.Printf("The Greatest Common Divisor of %d and %d is %d", a, b, r.Result)
}

GoogleOAuth2.0

gRPC 默认提供了多种 OAuth 2.0 认证机制,假如 gRPC 应用运行在 GCE 里,可以通过服务账号的密钥生成 Token 用于 RPC 调用的鉴权,密钥可以从环境变量 GOOGLE_APPLICATION_CREDENTIALS 对应的文件里加载。如果使用 GCE,可以在虚拟机设置的时候为其配置一个默认的服务账号,运行时可以与认证系统交互并为 Channel 生成 RPC 调用时的 access Token。

自定义安全认证策略

参考 Google 内置的 Credentials 实现类,实现自定义的 Credentials,可以扩展 gRPC 的鉴权策略。

从gRPC安全设计理解双向证书方案


本文始发于微信公众号(安全乐观主义):从gRPC安全设计理解双向证书方案

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: