这是一个创建于 2178 天前的主题，其中的信息可能已经有所发展或是发生改变。
SSL tunnel 是不是最安全的代理方式？
双向 SSL 加密，只能跟踪 ip 层的信息，应用流量只能阻隔，无法窃取。
希望能跟大佬们讨论一下。
第 1 条附言 · 2018-11-23 19:07:15 +08:00
目前来看，SSL tunnel 应该是一种比较安全的方式。
 |
1
jadec0der 2018-11-23 18:18:30 +08:00
以前用过两年，需要先建立连接，频繁掉线重连挺不爽的
|
 |
3
liuminghao233 2018-11-23 18:42:09 +08:00 via iPhone
不是
没有必要上 ssl |
 |
4
Greenm 2018-11-23 18:48:11 +08:00  1
如何定义最安全？
安全的定义一般有三要素，机密性( Confidentiality )、完整性( Integrity )、可用性( Availability)。 SSL 在这三要素上经过了长时间的考验，是值得信赖的。我个人觉得比 shadowsocks 在安全性的角度来讲更好。 但是由于某个不能说的存在，有时候可用性会受到影响。 |
 |
5
autoxbc 2018-11-23 18:52:49 +08:00
OpenVPN 需要客户端和服务器双向密钥鉴权，SSL 应该是双向加密单向鉴权
|
 |
6
getecho OP @Greenm 我也觉得 SSL 更经得起考验。但是 SSL handshake 的性能损害跟 ssr 的加密解密不知道哪个的影响更大。
|
 |
8
wevsty 2018-11-23 19:50:39 +08:00
各有各的优点和适用环境。
在能预先安全交换密钥的情况下，SS 对于点对点指定通信的性能显然比 SSL 要好，安全性上反正没有密钥就无法知道通讯内容，所以我会认为安全性没有任何问题。唯一的问题在于固定密钥无法做到向前保密，一旦密钥泄露就可以做到解密以前的所有通讯。 SSL/TLS 能在一定条件下进行安全的通讯（注意：必须具备先决条件），安全性上 SSL/TLS 连接可以做到向前保密的特性，但是显然 SSL/TLS 建立连接时仍然需要先握手交换通讯密钥，这使得使用起来付出更高的代价。 |
 |
10
sinv 2018-11-23 21:35:05 +08:00 2
纠正一下，SSL 支持服务器端和客户端双向认证，只不过客户的认证是可选的，详见：
* 维基 [“过程”小节第 4 条]( https://zh.wikipedia.org/wiki/傳輸層安全性協定#过程) >服务器请求客户端公钥。客户端有证书即双向身份认证，没证书时随机生成公钥。 * RFC [第 12 页第 1 行]( https://tools.ietf.org/html/rfc8446#page-12) >Authentication: Authenticate the server (and, optionally, the client) and provide key confirmation and handshake integrity. * Nginx 配置文件中打开客户端身份验证 >ssl_verify_client on; |
 |
11
archean 2018-11-23 21:55:17 +08:00 2
Stunnel + Squid 稳定用了 8 年了
|
 |
13
flynaj 2018-11-23 22:36:58 +08:00 via Android 1
HTTP2 代理了解一下，quic 代理，gost 全功能
|
 |
14
XinLake 2018-11-23 22:50:14 +08:00 via Android
传输层的数据也能拿到啊
|
 |
15
Mohanson 2018-11-23 23:22:33 +08:00
> 安全的定义一般有三要素，机密性( Confidentiality )、完整性( Integrity )、可用性( Availability)。
我们的根本目的不是 "加密数据保护你流量的安全", 而是 "不让别有用心之人知道你在爬墙". > 那我们需要的是什么? 匿名, 伪装, 混淆. 你往加密算法上考虑, 大方向已经错了. SSH Tunnel 握手特征过于明显. 我不需要知道你到底访问了什么网站, 我只要通过分析握手特征知道你在使用 SSH Tunnel 这个技术, 就直接 block. 这就是为什么很多人使用 SSH Tunnel 每 20 分钟必断一次的根本原因. @Greenm |
 |
17
datocp 2018-11-24 00:18:20 +08:00 via Android
55 说它伪装成 http 变成普通流量淹没在网络里，softether stunnel 何尝不是看起来很普通的 tls 流量。
Stunnel 本身一层加密 服务器端验证客户端身份 客户端验证服务器端身份 可以每 30 分钟变换证书 进行 rr 负载 它能真正的做到抗中间人，将流量打散到不同端口不同服务器上。 常用的也就剩下 softether+stunnel，备用 ocsrv |
|
18
Greenm 2018-11-24 01:30:02 +08:00 via iPhone
@Mohanson
首先帖子探讨的是安全性，并没有特指突破某种屏障的能力，而安全性就必须考虑这三要素。 另外，回到你提出这个更窄的方向来，如果想要更好的匿名性，不被发现阻断，最好的方法就是少，闷声发大财，自己造一个协议最好，不考虑安全只考虑匿名。 至于 SS 的表现如何，我可以明确的说，不怎么样。在安全三要素中，都远远比不上堪称工业级别的 ssl，唯一略胜一筹的可能就是不用交换密钥，所以没那么明显吧。但其实很有可能不少 SS 早就被识别，并且爆破了。Big brother is watching you. 参考: https://raw.githubusercontent.com/x41sec/slides/master/2018-passthesalt/shadowsocks_slides_pass_the_salt_2018.pdf |
 |
19
t6attack 2018-11-24 04:19:08 +08:00
正因为特征明显，所以是可用的。ssh 管理服务器、文件传输、隧道通信，位于一个端口。
你连接了 海外主机 的 非常用端口。这本身就是个最明显特征。如果这个端口是 ssh，那么还可以认为是 远程管理服务器 所必须而放一马。 |
|
20
liuminghao233 2018-11-24 08:16:14 +08:00 via iPhone
@Greenm
在识别这个问题上 在 proxy 这种应用环境下 ssl 只会死得更快 另外那个 sssniff 只是一个玩具而已 55aes 加密后的数据 没有被爆破的可能 那种超烂的 255 次改包检测法 上 aead 之后也不存在了 不过最安全还是隐藏协议实现 nonce 和 tag 放哪你都不知道 还有那个啥用 ml 来检测的我认为也是不存在的 |
Select Language