SSL tunnel 是不是最安全的代理方式？

[getecho]

SSL tunnel 是不是最安全的代理方式？
双向 SSL 加密，只能跟踪 ip 层的信息，应用流量只能阻隔，无法窃取。
希望能跟大佬们讨论一下。

目前来看，SSL tunnel 应该是一种比较安全的方式。

[jadec0der]

以前用过两年，需要先建立连接，频繁掉线重连挺不爽的

[getecho]

@jadec0der 这种情况的话。http 这种无状态的协议还是合适的。

[liuminghao233]

不是
没有必要上 ssl

[Greenm]

如何定义最安全？

安全的定义一般有三要素，机密性( Confidentiality )、完整性( Integrity )、可用性( Availability)。

SSL 在这三要素上经过了长时间的考验，是值得信赖的。我个人觉得比 shadowsocks 在安全性的角度来讲更好。

但是由于某个不能说的存在，有时候可用性会受到影响。

[autoxbc]

OpenVPN 需要客户端和服务器双向密钥鉴权，SSL 应该是双向加密单向鉴权

[getecho]

@Greenm 我也觉得 SSL 更经得起考验。但是 SSL handshake 的性能损害跟 ssr 的加密解密不知道哪个的影响更大。

[getecho]

@autoxbc 好吧。看样子永远没有“最”，只有“更”。

[wevsty]

各有各的优点和适用环境。

在能预先安全交换密钥的情况下，SS 对于点对点指定通信的性能显然比 SSL 要好，安全性上反正没有密钥就无法知道通讯内容，所以我会认为安全性没有任何问题。唯一的问题在于固定密钥无法做到向前保密，一旦密钥泄露就可以做到解密以前的所有通讯。
SSL/TLS 能在一定条件下进行安全的通讯（注意：必须具备先决条件），安全性上 SSL/TLS 连接可以做到向前保密的特性，但是显然 SSL/TLS 建立连接时仍然需要先握手交换通讯密钥，这使得使用起来付出更高的代价。

[getecho]

@wevsty 了解了，谢谢

[sinv]

纠正一下，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;

[archean]

Stunnel + Squid 稳定用了 8 年了

[getecho]

@sinv 多谢指正

[flynaj]

HTTP2 代理了解一下，quic 代理，gost 全功能

[XinLake]

传输层的数据也能拿到啊

[Mohanson]

> 安全的定义一般有三要素，机密性( Confidentiality )、完整性( Integrity )、可用性( Availability)。

我们的根本目的不是 "加密数据保护你流量的安全", 而是 "不让别有用心之人知道你在爬墙".

> 那我们需要的是什么? 匿名, 伪装, 混淆.

你往加密算法上考虑, 大方向已经错了. SSH Tunnel 握手特征过于明显. 我不需要知道你到底访问了什么网站, 我只要通过分析握手特征知道你在使用 SSH Tunnel 这个技术, 就直接 block. 这就是为什么很多人使用 SSH Tunnel 每 20 分钟必断一次的根本原因.

@Greenm

[pythonee]

@archean 能稍微细说吗，如何搭建

[datocp]

55 说它伪装成 http 变成普通流量淹没在网络里，softether stunnel 何尝不是看起来很普通的 tls 流量。
Stunnel 本身一层加密
服务器端验证客户端身份
客户端验证服务器端身份
可以每 30 分钟变换证书
进行 rr 负载
它能真正的做到抗中间人，将流量打散到不同端口不同服务器上。
常用的也就剩下 softether+stunnel，备用 ocsrv

[Greenm]

@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

[t6attack]

正因为特征明显，所以是可用的。ssh 管理服务器、文件传输、隧道通信，位于一个端口。
你连接了 海外主机 的 非常用端口。这本身就是个最明显特征。如果这个端口是 ssh，那么还可以认为是 远程管理服务器 所必须而放一马。

[liuminghao233]

@Greenm
在识别这个问题上
在 proxy 这种应用环境下 ssl 只会死得更快
另外那个 sssniff 只是一个玩具而已
55aes 加密后的数据
没有被爆破的可能
那种超烂的 255 次改包检测法
上 aead 之后也不存在了
不过最安全还是隐藏协议实现
nonce 和 tag 放哪你都不知道
还有那个啥用 ml 来检测的我认为也是不存在的

[Mohanson]

@t6attack ssh 端口通常只会有小流量且低频的交互，你访问个网站突然几秒内出现几 M 流量， 太明显了。