SSL 支持
SSL 支持¶
SeaboxSQL本地支持使用SSL连接加密客户端/服务通信以提高安全性。关于服务端的SSL功能详见用 SSL 进行安全的 TCP/IP 连接
。
libpq读取系统范围的OpenSSL配置文件。默认情况下,这个文件被命名为openssl.cnf
并且位于openssl version -d
所报告的目录中。可以通过设置环境变量OPENSSL_CONF
把这个默认值覆盖为想要的配置文件的名称。
服务证书的客户端验证¶
默认情况下,SeaboxSQL将不会执行服务证书的任何验证。这意味着可以在不被客户端知晓的情况下伪造服务身份(例如通过修改一个DNS 记录或者接管服务的 IP地址)。为了阻止哄骗,客户端必须能够通过一条信任链验证服务的身份。信任链可以这样建立:在一台计算机上放置一个根(自签名的)证书机构(CA)的证书并且在另一台计算机上放置一个由根证书签发的叶子证书。还可以使用一种“中间”证书,它由根证书签发并且可以签发叶子证书。
为了允许客户端验证服务的身份,在客户端上放置一份根证书并且在服务上放置由根证书签发的叶子证书。为了允许服务验证客户端的身份,在服务上放置一份根证书并且在客户端上放置由根证书签发的叶子证书。也可以使用一个或者更多个中间证书(通常与叶子证书存在一起)来将叶子证书链接到根证书。
一旦信任链被建立起来,客户端有两种方法验证服务发过来的叶子证书。如果参数sslmode
被设置为verify-ca
,libpq将通过检查该证书是否链接到存储在客户端上的根证书来验证服务。如果sslmode
被设置为verify-full
,libpq还将验证服务的主机名匹配存储在服务证书中的名称。如果服务证书无法被验证,则SSL连接将失败。在大部分对安全性很敏感的环境中,推荐使用verify-full
。
在verify-full
模式中,主机名被拿来与证书的主体别名属性 匹配,或者在不存在类型dNSName
的主体别名时与通用名称属性匹配。如果证书的名称属性以一个星号(*
)开始,这个星号将被视作一个通配符,它将匹配所有除了句点(.
)之外的字符。这意味着该证书将不会匹配子域。如果连接是使用一个 IP 地址而不是一个主机名创建的,该 IP 地址将被匹配(不做任何 DNS查找)。
要允许服务证书验证,必须将一个或者更多个根证书放置在用户主目录下的~/.seaboxsql/root.crt
文件中(在MicrosoftWindows上该文件名为%APPDATA%\seaboxsql\root.crt
)。如果需要把服务发来的证书链链接到存储在客户端的根证书,还应该将中间证书加到该文件中。
如果文件~/.seaboxsql/root.crl
存在(微软 Windows上的%APPDATA%\seaboxsql\root.crl
),证书撤销列表(CRL)项也会被检查。
根证书文件和 CRL的位置可以通过设置连接参数sslrootcert
和sslcrl
或环境变量SDSSLROOTCERT
和SDSSLCRL
改变。
注意
为了与 SeaboxSQL 的早期版本达到向后兼容,如果存在一个根 CA文件,sslmode
=require
的行为将与verify-ca
相同,即服务证书根据 CA验证。我们鼓励依赖这种行为,并且需要证书验证的应用应该总是使用verify-ca
或者verify-full
。
客户端证书¶
如果服务尝试通过请求客户端的叶子证书来验证客户端的身份,libpq将发送用户主目录下文件~/.seaboxsql/seaboxsql.crt
中存储的证书。该证书必须链接到该服务信任的根证书。也必须存在一个匹配的私钥文件~/.seaboxsql/seaboxsql.key
。该私钥文件不能允许全部用户或者组用户的任何访问,可以通过命令chmod 0600 ~/.seaboxsql/seaboxsql.key
实现。在微软 Windows上这些文件被命名为%APPDATA%\seaboxsql\seaboxsql.crt
和%APPDATA%\seaboxsql\seaboxsql.key
,不会有特别的权限检查,因为该目录已经被假定为安全。证书和密钥文件的位置可以使用连接参数sslcert
和sslkey
或者环境变量SDSSLCERT
和SDSSLKEY
覆盖。
seaboxsql.crt
中的第一个证书必须是客户端的证书,因为它必须匹配客户端的私钥。可以选择将“中间”证书追加到该文件 — 这样做避免了在服务上存放中间证书的要求(ssl_ca_file)。
创建证书的指令请参考创建证书
)。
不同模式中提供的保护¶
sslmode
参数的不同值提供了不同级别的保护。SSL 能够针对三类攻击提供保护:
-
窃听
如果一个第三方能够检查客户端和服务之间的网络流量,它能读取连接信息(包括用户名和口令)以及被传递的数据。SSL使用加密来阻止这种攻击。
-
中间人(MITM)
如果一个第三方能对客户端和服务之间传送的数据进行修改,它就能假装是服务并且因此能看见并且修改数据,即使这些数据已被加密。然后第三方可以将连接信息和数据转送给原来的服务,使得它不可能检测到攻击。这样做的通常途径包括DNS污染和地址劫持,借此客户端被重定向到一个不同的服务。还有几种其他的攻击方式能够完成这种攻击。SSL使用证书验证让客户端认证服务,就可以阻止这种攻击。
-
模仿
如果一个第三方能假装是一个授权的客户端,它能够简单地访问它本不能访问的数据。通常这可以由不安全的口令管理所致。SSL使用客户端证书来确保只有持有合法证书的客户端才能访问服务,这样就能阻止这种攻击。
对于一个已知安全的连接,在连接被建立之前,SSL使用必须被配置在客户端和服务之上。如果只在服务上配置,客户端在知道服务要求高安全性之前可能会结束发送敏感信息(例如口令)。在libpq中,要确保连接安全,可以设置sslmode
参数为verify-full
或verify-ca
并且为系统提供一个根证书用来验证。这类似于使用一个https
URL进行加密网页浏览。
一旦服务已经被认证,客户端可以传递敏感数据。这意味着直到这一点,客户端都不需要知道是否证书将被用于认证,这样只需要在服务配置中指定就比较安全。
所有SSL选项都带来了加密和密钥交换的负荷,因此必须在性能和安全性之间做出平衡。SSL 模式描述不同sslmode
值所保护的风险,以及它们是怎样看待安全性和负荷的。
表 SSL 模式描述
sslmode |
窃听保护 | MITM保护 | 声明 |
---|---|---|---|
disable |
No | No | 我不关心安全性,并且我不想为加密增加负荷。 |
allow |
可能 | No | 我不关心安全性,但如果服务坚持,我将承担加密带来的负荷。 |
prefer |
可能 | No | 我不关心安全性,但如果服务支持,我希望承担加密带来的负荷。 |
require |
Yes | No | 我想要对数据加密,并且我接受因此带来的负荷。我信任该网络会保证我总是连接到想要连接的服务。 |
verify-ca |
Yes | 取决于 CA -策略 |
我想要对数据加密,并且我接受因此带来的负荷。我想要确保我连接到的是我信任的服务。 |
verify-full |
Yes | Yes | 我想要对数据加密,并且我接受因此带来的负荷。我想要确保我连接到的是我信任的服务,并且就是我指定的那一个。 |
verify-ca
和verify-full
之间的区别取决于根CA
的策略。如果使用了一个公共CA
,verify-ca
允许连接到那些可能已经被其他人注册到该CA
的服务。在这种情况下,总是应该使用verify-full
。如果使用了一个本地CA
或者甚至是一个自签名的证书,使用verify-ca
常常就可以提供足够的保护。
sslmode
的默认值是prefer
。如表中所示,这在安全性的角度来说没有意义,并且它只承诺可能的性能负荷。提供它作为默认值只是为了向后兼容,并且我们不推荐在安全部署中使用它。
SSL 客户端文件使用¶
Libpq/客户端 SSL 文件用法总结了与客户端SSL 设置相关的文件。
表 Libpq/客户端 SSL 文件用法
文件 | 内容 | 效果 |
---|---|---|
~/.seaboxsql/seaboxsql.crt |
客户端证书 | 由服务要求 |
~/.seaboxsql/seaboxsql.key |
客户端私钥 | 证明客户端证书是由拥有者发送;不代表证书拥有者可信 |
~/.seaboxsql/root.crt |
可信的证书机构 | 检查服务证书是由一个可信的证书机构签发 |
~/.seaboxsql/root.crl |
被证书机构撤销的证书 | 服务证书不能在这个列表上 |
. SSL 库初始化¶
如果你的应用初始化libssl
或libcrypto
库以及带有SSL支持的libpq,你应该调用PQinitOpenSSL
来告诉libpq:libssl
或libcrypto
库已经被你的应用初始化,这样libpq将不会也去初始化那些库。
关于 SSL API详见http://h71000.www7.hp.com/doc/83final/ba554_90007/ch04.html。
PQinitOpenSSL
-
允许应用选择要初始化哪个安全性库。
void PQinitOpenSSL(int do_ssl, int do_crypto);
当
do_ssl
是非零时,libpq将在第一次打开数据库连接前初始化OpenSSL库。当do_crypto
是非零时,libcrypto
库将被初始化。默认情况下(如果没有调用PQinitOpenSSL
),两个库都会被初始化。当SSL 支持没有被编译时,这个函数也存在但是什么也不做。如果你的应用使用并且初始化OpenSSL或者它的底层
libcrypto
库,你必须在第一次打开数据库连接前以合适的非零参数调用这个函数。同时要确保在打开一个数据库连接前已经完成了初始化。 PQinitSSL
-
允许应用选择要初始化哪个安全性库。
void PQinitSSL(int do_ssl);
这个函数等效于
PQinitOpenSSL(do_ssl,do_ssl)
。这对于要么初始化OpenSSL以及libcrypto
要么都不初始化的应用足够用了。