设计文档

1 设置默认版本 contrib/pgcrypto/pgcrypto.control defaultl_version = '2.0' dbcompatibilities = 'A, B, PG' 生成同名的sql文件 touch contrib/pgcrypto/pgcrypto-2.0.sql 安装sql文件 # pgcrypto.control与pgcrypt.*.sql文件 ll $GAUSSHOME/share/postgresql/extension | grep pgcrypto 加载插件 # 执行：CREATE EXTENSION pgcrypto .. CreateExtension check_valild_extension_name # 检查插件名：要求不含 '-'、不含'..'等路径字符 get_extension_oid heap_open('pg_extension') systable_beginscan # 遍历系统表 pg_extension：确保插件存在 read_extension_control_file parse_extension_control_file get_extension_control_filename sprintf("{share}/extension/{extension_name}.control") ParreConfigFp # 获取 directory, default_version, module_pathname, dbcompatibilities 等参数 get_extension_script_filename get_extension_script_direcotry if name is 'pgcrypto': sprintf("{script_dir}/crypto-a.sql") read_extension_script_file InsertExtensionTuple # 插入系统表 pg_extension execute_extension_script ApplyExtensionUpdates

1 Oracle兼容性-支持profile功能 1.1 功能简述 本特性实现与oracle profile相同的功能，支持为不同用户设置7个不同的配置参数： failed_login_attempts password_lock_time password_life_time password_grace_time password_reuse_time password_reuse_max idle_time 简单使用示例如下： CREATE PROFILE pro1 LIMIT failed_login_attempts 10; CREATE USER u1 PASSWORD 'u1.pass1'; ALTER USER u1 PROFILE u1; 1.2 实现方案 一、元数据 本特性的关键实现为：对用户提供DDL接口，在内核中存储配置数据。因此，在介绍代码流程前，先介绍接口与元数据。 新增GUC参数resource_limit (与oracle参数名一致) 控制是否启用oracle profile功能。 如果该参数为on，以下5个guc参数则不再生效：[failed_login_attempts, password_lock_time, password_effect_time, password_reuse_time, password_reuse_max]。另外，对于已经过身份认证的连接，session_timeout也不再生效，相关功能均由profile中的用户级参数控制。 对于新安装的集群、旧版本升级的集群，该参数的值存在差异： 新安装：新安装的数据库，即3.0.8版本及之后，该guc参数值默认为on（初始值为off，由initdb自动设置为on） 升级：从3.0.8之前版本，升级到3.0.8版本时，在升级的过程中，该参数的值仍然是off，即升级上来默认不可用profile功能 SELECT * FROM pg_settings WHERE name = 'resource_limit'; -[ RECORD 1 ]------------------------------------------- name | resource_limit setting | on -- 默认为on （由initdb设置为on，从旧版本升级到新版本时，升级脚本会将该参数设置为off） unit | category | Ungrouped short_desc | Used to enable profile feature extra_desc | default on context | postmaster -- 需重启生效 vartype | bool source | default min_val | max_val | enumvals | boot_val | off reset_val | off sourcefile | sourceline | 修改6个GUC参数的生效条件 当GUC参数resource_limit取值为on时，以下6个GUC参数不再生效：[failed_login_attempts, password_lock_time, password_effect_time, password_reuse_time, password_reuse_max, session_timeout] ...

2 代码 新增试图 SELECT * FROM pg_user_settings; -- 新增视图 pg_user_settings SELECT rolname,profile FROM pg_authid WHERE rolcanlogin = true LEFT JOIN vb_profile ON rolname | setname | setting | settype | settype | setsource --------+-----------------------+----------+---------+-------------+---------------- u1 | password_effect_time | 90 | int | profile guc | pro1 | cluster guc | postgresql.conf 参数1: failed_login_attempts # opegauss使用1个内存中的hash表，存储密码失败次数 ClientAuthentication # 进行身份认证时，如果认证失败，则更新hash表中的失败次数值 UpdateFailCountToHashTable InitAccountLockHashTable hash_search # 如果失败次数超过GUC限制，则锁定账户 if failed_login_attempts： lockflag = True 参数2: password_lock_time 参数3: password_effect_time # 通过内置函数，主动查看密码剩余天数 gs_password_deadline GetCurrentUserId # 1 获取当前用户 GetUserCurrentPwdtime # 2 从系统表pg_auth_history中，获取密码创建时间passwordtime heap_open('pg_auth_history') systable_beginscan floor(u_sess->attr.attr_security.Password_effect_time) # 3 从guc参数password_effect_time中获取密码有效天数 # 计算步骤2和3中的时间，返回剩余过期天数 参数4: password_reuse_max AddAuthHistory systable_beginscan('pg_auth_history') # 1 从系统表pg_auth_history中，获取曾用过的密码rolpassword，获取生成密码的时间passwordtime systable_getnext_back # 倒着从系统表扫描，即先扫描不太古老的旧密码，再扫描更古老的旧密码 pg_sha256_encrypt # 使用旧密码的salt，加密新密码 if strncmp : # 比较新密码是否与旧密码相等 hasSame = True # 如果新旧密码相等，计算新旧密码间隔天数，与GUC参数password_reuse_time比较，判断是否满足密码重用时间限制 if now - pg_auth_history.passwordtime > 'password_reuse_time'： isTimeSafe = True # 计算这是倒数第几个密码 changeTimes++ if changeTimes > 'password_reuse_max': isMaxSafe # 满足 password_reuse_time 和 password_reuse_max 中任意一个条件，都可以修改密码 # - 要么用好几次之前的密码（满足 password_reuse_max 条件） # - 要么用很旧之间使用的密码（满足 password_reuse_time 条件） if hasSame and not isTimeSafe and not isMaxSafe: # 报错 参数5: password_reuse_time

G100审计功能重构 1 功能简述 在需求文档中，已详细介绍需求背景，此处不在重复介绍。 G100 309之前版本，审计特性存在较多问题，因此，在本版本，将重新设计与实现审计特性，解决功能、性能、易用性、可维护性、可扩展性等问题，使审计特性达到大规模商用的标准。 2 实现方案 一、审计架构 审计特性，核心子功能如下： 配置审计：通过GUC参数，配置审计参数：日志目录、目录大小、日志文件淘汰策略等 设置范围：通过SQL语法，设置审计策略，控制哪些事件需审计。在策略中，可按用户、操作、对象、操作结果等过滤事件 收集事件：在代码关键节点，收集事件 过滤事件：根据审计策略，过滤无需审计的事件 生成日志：提取事件关键信息，生成日志 传输日志：工作线程，通过共享内存，传输日志给审计线程 存储日志：审计线程，组织日志，并将其存储至文件中。文件存放在单独的日志目录 查询日志：通过内置FUNCTION，在线查询日志，通过TOOL，离线查询日志 其中，设置范围、过滤事件子功能相对独立，可单独设计与实现，所以，拆分到另一个的设计文档中。 审计特性整体架构图如下： 二、工作流程 收集事件的主体、操作、客体等信息时，因为需收集操作结果，即操作成功或失败，所以，很多场景中，收集事件需分为2个阶段： 执行操作前：收集事件基本信息，包括操作类型等 执行操作后：收集事件的操作结果。对于出现ERROR的场景，则在异常处理函数中收集操作结果。 在所有事件中，DML语句的事件稍复杂一点，此处主要以该类语句为例，梳理整体执行流程： 三、详细流程 阶段1 配置审计（进程启动） 首先，用户通过GUC参数，配置审计文件管理等功能。然后，在系统启动阶段，审计模块将根据配置，初始化的各类关键资源，包括： 日志文件：日志存储目录，初始日志文件等 审计内存：日志缓存区，内存上下文等 审计线程：信号处理函数等 事件收集节点：hook函数注册等 详细启动过程如下： main # 1. 启动vastbase进程 knl_instance_init MemoryContextInit PostmasterMain # 2. 启动postmaster线程 SelectConfigFiles # 3. 加载GUC参数 checkDataDir 'audit_dir_init' # 4. 创建审计日志文件目录 'audit_hook_init' # 5. 注册审计回调函数：身份认证等 load_hba reset_shared CreateSharedMemoryAndSemaphores # （日志缓冲区不是共享内存，后文阶段6详细介绍） GlobalSysDBCache::Init CreateLocalSysDBCache InitRoleIdHashTable 'audit_comm_init' # 6. 初始化审计内存上下文、日志缓存区，创建审计日志文件 'initialize_util_thread(AUDIT_WRITER)' # 7. 启动audit-writer 线程，持续读取日志缓冲区，等待接收与存储日志 initialize_thread .. # ===== audit-writer 线程 ============== GaussDbThreadMain InitShmemAccess InitAuxiliaryProcess CreateSharedMemoryAndSemaphores GaussDBAuxiliaryThreadMain BaseInit 'adt_writer_main' # ===== audit-writer 线程 ============== ServerLoop for (;;) comm_select ConnCreate # 9. 接收客户端连接 BackendStartup initialize_util_thread(WORKER) initialize_thread .. # ===== postgres 线程 ============== GaussDbThreadMain knl_thread_init InitializeGUCOptions CreateLocalSysDBCache 'audit_hook_init' # 10. 注册事件收集回调函数：计划执行、函数执行等回调点 BackendInitialize BackendRun PostgresMain # ===== postgres 线程 ============== 'initialize_util_thread(AUDIT_WRITER)' # 11. 检查audit-writer 线程状态与自动重启 阶段2 设置范围 向用户提供SQL接口，用于创建审计策略。（见另一个设计文档） ...

1 审计特性介绍 1.1 核心功能 1.2 整体架构（308.3） 1.3 工作流程（308.3） 1.4 文件组织 2 使用审计特性 2.1 配置审计特性 2.2 启动数据库 2.3 生成审计日志 2.4 查询审计日志 2.5 异常管理 3 审计特性变更点 3.1 问题分析 2.2 重构目标 2.3 问题分析（当前版本） 一、存储日志慢 二、检索日志慢 三、文件问题多 2.4 重构方案 一、存储日志重构 二、检索日志 2.5 重构开销 2.6 重构影响 2.7 性能测试 3 审计特性详细设计 3.1 架构设计 一、整体架构 二、工作流程 三、文件组织 3.2 详细设计 一、配置审计特性 二、审计文件管理 三、 启动数据库 四、生成审计日志 五、存储审计日志 六、审计日志一致性 七、归并审计日志 八、查询审计日志 4 审计后续重构计划 摘要 介绍审计特性，分析性能问题，提出优化方案，评审优化方案，规划其他计划 1 审计特性介绍 1.1 核心功能 审计特性：记录数据库内的各种事件，事件包括： ...

1 需求分析 透明加密 主密钥 动态脱敏 和统一审计共用resource lable模块 全密态 密态等值 密态非等值 范围查询：OPE保序加密 模糊查询 内置函数 排序 .. 防篡改 分布式：有点麻烦，区块链记录在每个节点上 哈希函数：md5 1.1 透明加密 模块分析 密钥管理 设置主密钥 定义加密属性 表：普通表、临时表、分区表、toast表 索引 xlog 加密数据 加密算法：aes-256-ctr, sm4-ctr 备机加密 -- 创建主密钥 -- 设置表加密 CREATE TABLE t1 (c1 INT, c2 TEXT) WITH (enable_tde=on); -- 验证数据加密存储 INSERT INTO t1 VALUES (1, 'bbbcccddd'); 1.2 动态脱敏 -- 开启脱敏功能 gs_guc reload -D $GAUSSHOME/data -c "enable_security_policy=on" -- 创建表 CREATE TABLE t1 (c1 TEXT, c2 TEXT); INSERT INTO t1 VALUES ('bbccdd', 'bbccdd'); -- 创建用户 CREATE USER u1 PASSWORD 'u1.password'; CREATE USER u2 PASSWORD 'u2.password'; GRANT SELECT ON t1 TO u1; GRANT SELECT ON t1 TO u2; -- 创建资源标签（只对u1脱敏） CREATE RESOURCE LABEL l1 ADD COLUMN(t1.c1); CREATE MASKING POLICY m1 randommasking ON LABEL(l1) FILTER ON ROLES(u1); -- 验证脱敏：只有u1脱敏 SET ROLE u1 PASSWORD 'u1.password'; SELECT * FROM t1; RESET ROLE; SET ROLE u2 PASSWORD 'u2.password'; SELECT * FROM t1; RESET ROLE; -- 清理环境 DROP MASKING POLICY m1; DROP RESOURCE LABEL l1; DROP TABLE t1; DROP USER u1,u2; 1.3 全密态 模块分析 客户端 语法解析 语义分析 加密 服务端 .. 1.4 防篡改 hash算法：md5 2 greenplum yum install zstd libzstd-devel krb5-devel krb5-libs cyrus-sasl-gssapi libevent-devel libyaml-devel libxml2 libxml2-devel curl libcurl-devel yum install apr apr-devel apr-util apr-util-devel yum install expat-devel openldap-devel bzip2 bzip2-devel xerces-c xerces-c-devel python36-devel ln -s /usr/include/python2.7/Python.h /usr/include/Python.h # 报错就降级 yum downgrade expat-2.1.0-12.el7 mkdir install cd install # echo ''使用单引号可防止变量$PATH等展开 echo ' export GPHOME=`pwd`/install export BINARYLIBS=`pwd`/../third export GCC_PATH=$BINARYLIBS/buildtools/gcc10.3 export CC=$GCC_PATH/gcc/bin/gcc export CXX=$GCC_PATH/gcc/bin/g++ export LD_LIBRARY_PATH=$GCC_PATH/gcc/lib64:$GCC_PATH/isl/lib:$GCC_PATH/mpc/lib/:$GCC_PATH/mpfr/lib/:$GCC_PATH/gmp/lib/:$LD_LIBRARY_PATH export PATH=$GCC_PATH/gcc/bin:$PATH ' > genv # 建议把环境变量再在~/.bashrc中写一份，因为初始化集群时，需要ssh登录，以初始化segment节点 ./configure --with-python --with-libxml --with-gssapi --without-zlib --with-gpcc --prefix=$GPHOME make -sj 16 make install -sj 16 echo " ARRAY_NAME="Greenplum Cluster" SEG_PREFIX=gpseg #segment数据库前缀名 PORT_BASE=40000 #segment数据库起始端口号 declare -a DATA_DIRECTORY=(//home/shenkun/gp/install/segdata) #segments数据目录，有几个DATA_DIRECTORY, 每个节点上便会启动几个segment，本例为2个segment MASTER_HOSTNAME=master #master主机名 MASTER_DIRECTORY=/home/shenkun/gp/install/master #master数据目录 MASTER_PORT=5000 #master端口号，也是对外业务端口号 TRUSTED_SHELL=ssh CHECK_POINT_SEGMENTS=8 ENCODING=UNICODE DATABASE_NAME=gpdb MACHINE_LIST_FILE=/home/shenkun/gp/install/hostfile #集群配置文件，hostfile对应7中创建的文件名 " > gpcfg echo "master" > hostfile gpinitsystem -c gpcfg -a psql -p 5000 -d gpdb PGOPTIONS='-c gp_session_role=utility' psql -p 40000 -d gpdb # @ master exec_simple_query pg_parse_query pg_analyze_and_rewrite pg_plan_queries pg_plan_querie planner standard_planner subquery_planner cdbllize_adjust_top_path create_plan cdbpathtoplan_create_flow makeFlow cdbllize_decorate_subplans_with_motions PortalStart ExecutorStart standard_ExecutorStart CdbDispatchPlan # @ segment exec_mpp_query deserializeNode PortalStart PortalRun PortalDrop PortalRun PortalRunMulti ProcessQuery ExecutorStart ExecutorRun standard_ExecutorRun ExecutePlan ExecutorFinish ExecutorEnd PortalDrop

假设集群里已经存在表级透明加密模块，在此基础上设计一个高性能、高易用性的 WAL 加密模块。 WAL 加密的难点几乎不在"加密"本身，而在两件事：同一个 8KB 页会被反复重写，以及恢复路径要在拿不到 catalog 的时候就能解密。下面按设计决策的顺序展开。 1 威胁模型 先划清边界，因为它直接决定后面几个取舍。 要防的：磁盘 / 备份 / 归档介质被拖走；DBA 之外的运维人员直接读 pg_wal/；WAL 归档到对象存储。 不防的：有 root 权限的在线攻击者（内存里必然有明文）、旁路攻击。 1.1 为什么不用 dm-crypt 了事 如果只是防"介质丢失"，块设备加密（LUKS/dm-crypt）性价比高得多。在数据库内核里做 WAL 加密，真正的理由只有三个： 密钥要由数据库自己管，不能落在 OS 层（密评 / 国测要求）； 归档件要天然带密； 和已有的表级 TDE 共用一套密钥体系。 设计要始终对齐这三个理由，否则很容易做成一个又慢、又没多大意义的模块。 1.2 FPI 是必须堵的洞 既然表级 TDE 已经存在，那么 FPI（full page image）就是个必堵的泄漏点。 如果 TDE 是在 smgr 层做的（缓冲区里是明文、写盘时加密），那么 WAL 里的 FPI 记录的是明文页 —— 加密表的数据会原封不动地漏进 WAL。 只要集群里存在任何一张加密表，WAL 加密就必须强制开启，不能是两个独立开关。 实现上做成一个集群级的 data_encryption = on，或者至少让 CREATE ENCRYPTION POLICY 在 WAL 加密未开启时直接报错。这是易用性设计里最重要的一条：不要把一个"配错了就静默泄密"的组合留给用户。 ...

1 E100审计功能 1.1 功能简述 【审计功能】 审计是重要的安全特性，核心功能是收集数据库内的事件，例如：登录用户、创建对象、查询数据等，根据事件生成与审计日志，存储审计日志，向用户提供日志查询接口。使用方式请看需求文档。 【审计架构】 审计整体架构如下图所示：（“线程“替换为“进程”，原图不小心弄丢了，不好修改了，将就看） 【审计流程】 1.2 实现方案 一、启动审计进程 1. 启动postmaster进程 # PostmasterMain 2. 加载GUC参数 # SelectConfigFiles 2.1 '---加载审计GUC---' 3. 创建共享内存和信号量 # reset_shared -> CreateSharedMemoryAndSemaphores 3.1 计算共享内存总大小 '计算审计共享内存大小：根据GUC配置' 3.2 创建共享内存 # PGSharedMemoryCreate 3.3 创建LwLock # CreateLWLocks 3.4 初始化wal-buffer共享内存 # XLOGShmemInit 3.5 初始化share-buffer共享内存 # InitBufferPool 3.6 '如果开启审计：初始化审计共享内存：划分共享内存，包括audit-buffer' 4. 启动sys-log进程 # SysLogger_Start 5. '如果开启审计：初始化审计模块' 5.1 '日志目录：检验与创建审计日志目录' 5.2 '日志文件：每次重启，使用新的日志文件，方便用户单个删除日志文件' 5.3 '内存上下文：创建审计全局内存上下文' 5.4 '审计缓存区：初始化audit-buffer' 5.5 '审计文件：初始化审计文件（并发write, read, delete日志）' 5.6 '回调函数：在执行DDL、计划、函数等关键函数中，注册生成审计事件、日志的回调函数' # 后面详细介绍 6. '如果开启审计：启动审计进程' 6.1 '信号：注册信号处理函数：sighup, sigquit, sigusr1' 6.2 '显示：设置ps命令显示的进程信息' 6.3 主循环 6.4 '等待事件：关键是timeout' 6.5 '存储日志：读取audit-buffer中待落盘的日志，并存储' # 后面详细介绍 6.6 '调整速率：按照每次落盘数据的长度，动态调整timeout' 连续多次为0，timeout依次变为1ms, 100ms, 1s 单次落盘长度大于16m，timeout=0 7. '主循环' # ServerLoop 7.1 接收客户端连接 # select 7.2 创建postgres进程 # BackendStartup -> BackendRun -> PostgresMain 7.3 检查与重启sys-log进程 # SysLogger_Start 7.4 '检查与重启审计进程' 7.5 检查与重启checkpointer进程 # StartCheckpointer 7.6 检查与重启wal-writer进程 # StartWalWriter 二、收集审计事件 目前，只有以下2类进程，会生成审计事件： ...

1 简介 1.1 分享的主题 分享一些编写需求、设计文档经验 1.2 分享的背景 背景：我写的需求文档，（相对）还算详细，所以有此次分享 308.1，profile功能的需求文档：https://www.tapd.cn/60475194/markdown_wikis/show/#1160475194001007196 根因：前公司流程繁重，被迫养成这种习惯。 分享的内容：可分享的干货不多，我觉得，在写文档的过程中，大部分人想的很详细，只是没有编写到文档中，毕竟每个人都有自己的编写风格。所以，本文的重点，是介绍前公司流程与要求，并以我做过的需求为例，为大家提供一点参考。 分享人经历：交过10+个不算小的需求，完整写过10+次需求与设计文档，格式与海量的接近。 分享的局限：交付的需求，主要是安全方向，也涉及SQL、存储等多个模块，所以，本文主要以安全需求的角度写，其他模块的需求不一定适用。 1.3 前公司的流程 与海量相比，前公司的交付流程，几乎一样： 客户：提出需求 产品、项目、测试、架构等：审核需求 开发：撰写需求/设计文档 各角色：评审需求/设计文档 开发：编写代码 … 其中，在4.评审需求/设计文档环节，前公司区别较大： 一、评审人员多 编号 角色 评审人 目的 1 开发 安全组、SQL组、存储组、运维组、.. 避免影响其他模块，协助发现风险 2 测试 测试人、测试组长 学习新需求，识别测试重点 3 架构 架构设计 避免影响其他模块，确保后向兼容 4 资料 资料优化、资料审核 学习新需求 5 用例 用例审核 确保各种check可看护功能 6 其他 流程提升 - 二、评审通过难 组内评审 线上评审：上述所有角色会上评审，不过，一般很多人会议冲突，关键靠线下评审 线下评审（关键流程）：各类角色共10+必选评审人，通过在线需求文档、设计文档了解需求，提出疑问，提出意见。开发分析解决后，找提出人确认意见，才算闭环。最后，所有必选评审人评审通过，才算完成流程。 在这种流程中，需求与设计文档，要满足很多要求： 普适：考虑到其他组开发、测试、资料等角色，不熟悉本领域的基础知识，所以，需要详细介绍相关原理，很多原理需要从头介绍 完整：要充分例举所有可能涉及风险，否则，评审人会认为未考虑到 举例：做了1个需求，可以为表设置加密属性，需要考虑：系统表、用户表（atore表、ustore表、分区表、临时表、toast表、unlogged表、segment表、hashbuckent表、物化视图…） 2 需求文档写作思路 2.1 分析过程 首先，客户提出需求，很多需求不够清晰。 示例： profile原始需求： 目前对于数据库用户的管理方式不够便捷，无法像Oracle为用户赋予一组安全策略。一些属性如密码有效期、密码过期天数、密码尝试次数等也只能全局设定，无法指定用户配置。 然后，以我的个人习惯，分析需求的流程如下： ...

1 TLS协议支持第三方流量审计 1.1 功能简述 【需求背景】 TLS协议，是保障通信安全的加密协议，可分为4个子功能： 密钥生成：通过密钥交换或密钥协商等协议，让双方生成相同的密钥 身份认证：在开始阶段，双方均向对方发送自己的证书。双方接收证书后，基于PKI体系，校验证书是否合法。 数据加密：发送方发生数据前，使用密钥加密数据，发送数据密文。接受方接受密文后，使用密钥解密，获取数据。 数据校验：在加密数据的同时，生成数据完整性校验码，与数据密文拼接在一起。（简单理解：生成数据的哈希值，并使用密钥加密哈希值）接收方解密数据后，同样生成数据完整性校验码，与接收的相比，判断是否一致。 开源软件libssl.so提供TLS功能，应用只需调用接口，即可实现TLS协议。同时，libssl.so提供100+算法套件，可让应用选择不同的参数组合，1个算法套件，包含4个关键参数： 密钥生成：密钥生成协议 身份认证：证书算法类型 数据加密：加密算法类型 数据校验：哈希算法类型 例如，libssl.so中，常用的算法套件为：ECDHE-RSA-AES128-SHA256，该套件中，参数的含义如下： 密钥生成协议：ECDHE协议。（常见协议类型:DHE、ECDHE、RSA等） 证书算法类型：RSA 加密算法类型：AES-128 哈希算法类型：SHA-256 【需求分析】 vastbase支持TLS协议，当vsql与vastbase通信时，双方可使用TLS模块，生成密钥，并使用密钥加密、解密通信数据，包括：SQL语句、SQL执行结果等。 客户可能采用第三方工具，截取网络流量，获取传输中的SQL等数据，进行流量审计。但是，在使用TLS协议的情况下，网络中的数据是密文形式，无法进行流量审计。 vastbase提供1个GUC参数ssl_ciphers，用于配置TLS协议采用的算法套件，旧版本，该参数的取值范围如下： ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-GCM-SHA384 DHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES128-GCM-SHA256 DHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-ECDSA-SM4-CBC-SM3 4个仅tassl支持的国密算法套件 上述7个套件中，密钥生成协议为：ECDHE、DHE，此类DH协议，无法让第三方工具获取密钥。 本版本，新增4个算法套件： AES128-SHA256 AES256-SHA256 AES128-GCM-SHA256 AES256-GCM-SHA384 上述4个套件，密钥生成协议为：RSA，该协议可让第三方工具获取密钥，使其可解密网络流量，获取SQL语句、SQL执行结果等。 【需求实现】 之前，vastbase限制ssl_ciphers的取值范围，仅放开7个算法套件，本版本，将新增放开4个算法套件。 实现时，仅修改ssl_ciphers的取值范围，新增支持4个算法套件[AES128-SHA256、AES256-SHA256、AES128-GCM-SHA256、AES256-GCM-SHA384]，4个算法套件将直接传递给libssl.so，内核不做任何处理。 因此，本需求无复杂设计。本文主要介绍完整的TLS协议工作原理。 1.2 实现方案 一、ECDHE与RSA的区别 此处简化ECDHE与RSA的步骤与算法，提取最核心的原理，方便快速理解。 一、ECDHE密钥协商协议 第三方工具、攻击者完全无法获取密钥。 client server +-------------------------------------------+----------------------------------- | <---- 0. 双方随机约定一些公开参数 ------> | | 1. 生成随机私钥 client_priv | 2. 基于client_priv，计算公钥 client_pub | 3. 发送公钥 client_pub ------------> | 4. 接收公钥 client_pub | 5. 生成随机私钥 server_priv | 6. 基于server_priv，计算公钥 server_pub <------------ | 7. 发送公钥 server_pub | 8. 接收公钥 server_pub | 9. 基于client_priv，server_pub，计算密钥 | 10. 基于server_priv，client_pub，计算密钥 （第9步和第10步，可以计算出相同的密钥） 简单举个例子 client server +-------------------------------------------+----------------------------------- | <----- 0. generate and send (2,11) ----> | | 1. generate 8 | 2. caculate (8 * 2) % 11 = 5 | 3. send 5 ----------> | 4. receive 5 | 5. generate 10 | 6. caculate (10 * 2) % 11 = 9 <------------ | 7. send 9 | 8. receive 9 | 9. key = (8 * 9) % 11 = 6 | 10. key = (10 * 5) % 11 = 6 攻击者：截获网络流量，获取2,11,5,9，无法计算出密钥为6 二、RSA密钥交换协议 ...