工作中需要建立一套HSM的HTTPS双向认证通道,即通过硬件加密机(Ukey)进行本地加密运算的HTTPS双向认证,和银行的UKEY认证类似。
NodeJS可以利用openSSL的HSM plugin方式实现,但是需要编译C++,太麻烦,作者采用了利用Node Socket接口,纯JS自行实现Https/Http协议的方式实现
具体实现可以参考如下 node-https-hsm
TLS规范自然是参考RFC文档 The Transport Layer Security (TLS) Protocol Version 1.2
概述
本次TLS双向认证支持以下加密套件(*为建议使用套件):
TLS_RSA_WITH_AES_128_CBC_SHA256(TLS v1.2) * TLS_RSA_WITH_AES_256_CBC_SHA256(TLS v1.2) * TLS_RSA_WITH_AES_128_CBC_SHA(TLS v1.1) TLS_RSA_WITH_AES_256_CBC_SHA(TLS v1.1)四种加密套件流程完全一致,只是部分算法细节与报文略有差异,体现在
AES_128/AES_256的会话AES密钥长度分别为16/32字节。 TLS 1.1 在计算finish报文数据时,进行的是MD5 + SHA1的HASH算法,而在TLS v1.2下,HASH算法变成了单次SHA256。 TLS 1.1 处理finish报文时的伪随机算法(PRF)需要将种子数据为分两块,分别用 MD5 / SHA1 取HASH后异或,TLS 1.2 为单次 SHA256。 TLS 1.2 的 CertificateVerify / ServerKeyExchange 报文末尾新增2个字节的 Signature Hash Algorithm,表示 hash_alg 和 sign_alg。目前业界推荐使用TLS v1.2, TLS v1.1不建议使用。
流程图
以下为 TLS 完整握手流程图
* =======================FULL HANDSHAKE====================== * Client Server * * ClientHello --------> * ServerHello * Certificate * CertificateRequest * <-------- ServerHelloDone * Certificate * ClientKeyExchange * CertificateVerify * Finished --------> * change_cipher_spec * <-------- Finished * Application Data <-------> Application Data
流程详解
客户端发起握手请求
TLS握手始于客户端发起 ClientHello 请求。
struct { uint32 gmt_unix_time; // UNIX 32-bit format, UTC时间 opaque random_bytes[28]; // 28位长度随机数} Random; //随机数struct { ProtocolVersion client_version; // 支持的最高版本的TLS版本 Random random; // 上述随机数 SessionID session_id; // 会话ID,新会话为空 CipherSuite cipher_suites<2..2^16-2>; // 客户端支持的所有加密套件,上述四种 CompressionMethod compression_methods<1..2^8-1>; // 压缩算法 select (extensions_present) { // 额外插件,为空 case false: struct {}; case true: Extension extensions<0..2^16-1>; };} ClientHello; // 客户端发送支持的TLS版本、客户端随机数、支持的加密套件等信息
服务器端回应客户端握手请求
新闻热点
疑难解答
图片精选