深入学习 GRPC – 2. 加密非流式的字节结构

本篇主要进行加密非流式 GRPC 的通信在字节层面的讨论，使用带 TLSv1.2 的 nginx 节点代理非加密的 golang 服务端节点，密钥交换使用椭圆曲线，在服务端使用自签名证书，不使用客户端证书，假设读者对 TLS 等已有基本的了解。
使用以下命令生成椭圆曲线密钥和服务端自签名证书：

openssl ecparam -genkey -name secp256r1 | openssl ec -out  hot.key -aes128
openssl req -new -x509 -days 365 -key hot.key -out hot.crt

上一篇的 proto 和 golang 服务端代码不变，golang 客户端代码变为：

package main

import (
    "context"
    "crypto/tls"
    "os"

    "grpc_hot/pb"

    "google.golang.org/grpc"
    "google.golang.org/grpc/credentials"
)

func main() {
    port := "30080"
    if len(os.Args) >= 2 {
        port = os.Args[1]
    }

    creds := credentials.NewTLS(&tls.Config{
        InsecureSkipVerify: true,
    })
    conn, err := grpc.Dial("127.0.0.1:"+port, grpc.WithTransportCredentials(creds))
    if nil != err {
        println(err.Error())
        return
    }
    defer conn.Close()
    cli := pb.NewHotClient(conn)
    resp, err := cli.Inc(context.Background(), &pb.IntReq{I: 6})
    if nil != err {
        println(err.Error())
        return
    }
    println("resp:", resp.GetI())
}

nginx 配置文件变为：

upstream grpc_hot {
    server 127.0.0.1:30081;
    server 127.0.0.1:30082;
}
server {
    listen 30080 ssl http2;
    ssl_protocols TLSv1.2;
    ssl_certificate hot.crt;
    ssl_certificate_key hot.key;
    ssl_password_file hot.pass;
    ssl_prefer_server_ciphers on;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256;
    ssl_session_cache shared:grpc_hot_sess:32m;
    ssl_session_timeout 10m;
    keepalive_timeout 60;
        
    location / {
        grpc_pass grpc://grpc_hot;
    }
}

2.1. TLS

启动上述 golang 的服务端和 nginx，调用一次客户端，在客户端连接 30080
端口。使用 wireshark 抓包，总共抓到 40 帧，基本上比第 1 篇多了一倍。
在 OSI 七层结构中，TCP、TLS、HTTP 分别位居第 4、6、7 层，这里第 5 层为空。本篇中我们当然只关心 TCP 的荷载为 TLS 层的帧。TLS 层的结构如下：

+---------------+-------------------------------+------------------------------+
| Cont Type (8) |         Version (16)          |         Length (16)          |
+---------------+-------------------------------+------------------------------+
|                                   Data (*)                                 ...
+------------------------------------------------------------------------------+

在第 4、6、8、9 帧，两端完成了 10 步的 TLS 握手：

• Client Hello
  / Server Hello
  ：两端各生成一个 随机串
  告知对方，并由服务端决定使用套件 ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• Certificate
  ：服务端下发证书，包括公钥。客户端验证证书，这里选择不验证
• Server Key Exchange
  / Server Hello Done
  ：服务端随机生成一个 服务端临时私钥
  ，根据该私钥在椭圆曲线上计算出一个 服务端临时公钥
  ，下发给客户端
• Client Key Exchange
  / Client Change Cipher Spec
  / Client Finished
  ：同样，客户端随机生成一个 客户端临时私钥
  ，根据该私钥在椭圆曲线上计算出一个 客户端临时公钥
  ，上传给服务端。同时，客户端根据 hello 步的两个随机串、客户端临时私钥和服务端临时公钥，计算出两端分别使用的 对称密钥
• Server Change Cipher Spec
  / Server Finished
  ：同样，服务端根据 hello 步的两个随机串、服务端临时私钥和客户端临时公钥，计算出两端分别使用的对称密钥。数学的魔力保证了两端分别计算出的对称密钥必然相同，感觉这很浪漫啊。

2.2 HTTP/2

接下来抓到 9 个 TLS 层的帧，它们的 Content type
均为 Application Data (23)
，显然，其中的 Data
字段均为已被对称密钥加密的内容，解密之后即是 HTTP 层的内容。

这里我们修改了 golang 标准库的 crypto/tls.(*halfConn).encrypt
和 crypto/tls.(*halfConn).decrypt
函数，分别在其中打印出加密前和解密后的数据。我们还是逐帧看看它们：

拨云见日，熟悉的亚子又回来了。可以看到，服务端的 SETTINGS
帧早于客户端的试探帧，其他差不都不大。
其中，第 16、33、35 帧的首部解码出来分别如下：

:method POST
:scheme https
:path /pb.Hot/Inc
:authority 127.0.0.1:30080
content-type application/grpc
user-agent grpc-go/1.25.1
te trailers

:status 200
server openresty/1.15.8.2
date Sat, 07 Dec 2019 07:45:07 GMT
content-type application/grpc

grpc-status 0
grpc-message

请求首部的 :scheme
字段变为了 https
，其它都没有什么变化。而两个 DATA
帧也还是我们熟悉的样子。

References

Licensed under CC BY-SA 4.0