Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
Greenplum
Gpdb
提交
bb8c822d
G
Gpdb
项目概览
Greenplum
/
Gpdb
通知
7
Star
1
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
DevOps
流水线
流水线任务
计划
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
G
Gpdb
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
DevOps
DevOps
流水线
流水线任务
计划
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
流水线任务
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
bb8c822d
编写于
10月 24, 2008
作者:
M
Magnus Hagander
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Remove notes from the frontend SSL source that are incorrect or
end-user documentation that lives in the actual documentation.
上级
81f3e109
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
1 addition
and
56 deletion
+1
-56
src/interfaces/libpq/fe-secure.c
src/interfaces/libpq/fe-secure.c
+1
-56
未找到文件。
src/interfaces/libpq/fe-secure.c
浏览文件 @
bb8c822d
...
...
@@ -11,64 +11,9 @@
*
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/interfaces/libpq/fe-secure.c,v 1.10
5 2008/05/16 18:30:53
mha Exp $
* $PostgreSQL: pgsql/src/interfaces/libpq/fe-secure.c,v 1.10
6 2008/10/24 12:29:11
mha Exp $
*
* NOTES
* [ Most of these notes are wrong/obsolete, but perhaps not all ]
*
* The client *requires* a valid server certificate. Since
* SSH tunnels provide anonymous confidentiality, the presumption
* is that sites that want endpoint authentication will use the
* direct SSL support, while sites that are comfortable with
* anonymous connections will use SSH tunnels.
*
* This code verifies the server certificate, to detect simple
* "man-in-the-middle" and "impersonation" attacks. The
* server certificate, or better yet the CA certificate used
* to sign the server certificate, should be present in the
* "~/.postgresql/root.crt" file. If this file isn't
* readable, or the server certificate can't be validated,
* pqsecure_open_client() will return an error code.
*
* Additionally, the server certificate's "common name" must
* resolve to the other end of the socket. This makes it
* substantially harder to pull off a "man-in-the-middle" or
* "impersonation" attack even if the server's private key
* has been stolen. This check limits acceptable network
* layers to Unix sockets (weird, but legal), TCPv4 and TCPv6.
*
* Unfortunately neither the current front- or back-end handle
* failure gracefully, resulting in the backend hiccupping.
* This points out problems in each (the frontend shouldn't even
* try to do SSL if pqsecure_initialize() fails, and the backend
* shouldn't crash/recover if an SSH negotiation fails. The
* backend definitely needs to be fixed, to prevent a "denial
* of service" attack, but I don't know enough about how the
* backend works (especially that pre-SSL negotiation) to identify
* a fix.
*
* ...
*
* Unlike the server's static private key, the client's
* static private key (~/.postgresql/postgresql.key)
* should normally be stored encrypted. However we still
* support EPH since it's useful for other reasons.
*
* ...
*
* Client certificates are supported, if the server requests
* or requires them. Client certificates can be used for
* authentication, to prevent sessions from being hijacked,
* or to allow "road warriors" to access the database while
* keeping it closed to everyone else.
*
* The user's certificate and private key are located in
* ~/.postgresql/postgresql.crt
* and
* ~/.postgresql/postgresql.key
* respectively.
*
* ...
*
* We don't provide informational callbacks here (like
* info_cb() in be-secure.c), since there's mechanism to
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录