V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Distributions
Ubuntu
Fedora
CentOS
中文资源站
网易开源镜像站
getecho
V2EX  ›  Linux

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

  •  
  •   getecho · 2018-11-23 17:29:42 +08:00 · 7445 次点击
    这是一个创建于 2176 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

    第 1 条附言  ·  2018-11-23 19:07:15 +08:00
    目前来看,SSL tunnel 应该是一种比较安全的方式。
    21 条回复    2018-11-24 12:02:18 +08:00
    jadec0der
        1
    jadec0der  
       2018-11-23 18:18:30 +08:00
    以前用过两年,需要先建立连接,频繁掉线重连挺不爽的
    getecho
        2
    getecho  
    OP
       2018-11-23 18:29:00 +08:00
    @jadec0der 这种情况的话。http 这种无状态的协议还是合适的。
    liuminghao233
        3
    liuminghao233  
       2018-11-23 18:42:09 +08:00 via iPhone
    不是
    没有必要上 ssl
    Greenm
        4
    Greenm  
       2018-11-23 18:48:11 +08:00   ❤️ 1
    如何定义最安全?

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

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

    但是由于某个不能说的存在,有时候可用性会受到影响。
    autoxbc
        5
    autoxbc  
       2018-11-23 18:52:49 +08:00
    OpenVPN 需要客户端和服务器双向密钥鉴权,SSL 应该是双向加密单向鉴权
    getecho
        6
    getecho  
    OP
       2018-11-23 18:57:34 +08:00
    @Greenm 我也觉得 SSL 更经得起考验。但是 SSL handshake 的性能损害跟 ssr 的加密解密不知道哪个的影响更大。
    getecho
        7
    getecho  
    OP
       2018-11-23 19:04:18 +08:00
    @autoxbc 好吧。看样子永远没有“最”,只有“更”。
    wevsty
        8
    wevsty  
       2018-11-23 19:50:39 +08:00
    各有各的优点和适用环境。

    在能预先安全交换密钥的情况下,SS 对于点对点指定通信的性能显然比 SSL 要好,安全性上反正没有密钥就无法知道通讯内容,所以我会认为安全性没有任何问题。唯一的问题在于固定密钥无法做到向前保密,一旦密钥泄露就可以做到解密以前的所有通讯。
    SSL/TLS 能在一定条件下进行安全的通讯(注意:必须具备先决条件),安全性上 SSL/TLS 连接可以做到向前保密的特性,但是显然 SSL/TLS 建立连接时仍然需要先握手交换通讯密钥,这使得使用起来付出更高的代价。
    getecho
        9
    getecho  
    OP
       2018-11-23 20:00:36 +08:00
    @wevsty 了解了,谢谢
    sinv
        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;
    archean
        11
    archean  
       2018-11-23 21:55:17 +08:00   ❤️ 2
    Stunnel + Squid 稳定用了 8 年了
    getecho
        12
    getecho  
    OP
       2018-11-23 22:10:55 +08:00
    @sinv 多谢指正
    flynaj
        13
    flynaj  
       2018-11-23 22:36:58 +08:00 via Android   ❤️ 1
    HTTP2 代理了解一下,quic 代理,gost 全功能
    XinLake
        14
    XinLake  
       2018-11-23 22:50:14 +08:00 via Android
    传输层的数据也能拿到啊
    Mohanson
        15
    Mohanson  
       2018-11-23 23:22:33 +08:00
    > 安全的定义一般有三要素,机密性( Confidentiality )、完整性( Integrity )、可用性( Availability)。

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

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

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

    @Greenm
    pythonee
        16
    pythonee  
       2018-11-23 23:37:29 +08:00
    @archean 能稍微细说吗,如何搭建
    datocp
        17
    datocp  
       2018-11-24 00:18:20 +08:00 via Android
    55 说它伪装成 http 变成普通流量淹没在网络里,softether stunnel 何尝不是看起来很普通的 tls 流量。
    Stunnel 本身一层加密
    服务器端验证客户端身份
    客户端验证服务器端身份
    可以每 30 分钟变换证书
    进行 rr 负载
    它能真正的做到抗中间人,将流量打散到不同端口不同服务器上。
    常用的也就剩下 softether+stunnel,备用 ocsrv
    Greenm
        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
    t6attack
        19
    t6attack  
       2018-11-24 04:19:08 +08:00
    正因为特征明显,所以是可用的。ssh 管理服务器、文件传输、隧道通信,位于一个端口。
    你连接了 海外主机 的 非常用端口。这本身就是个最明显特征。如果这个端口是 ssh,那么还可以认为是 远程管理服务器 所必须而放一马。
    liuminghao233
        20
    liuminghao233  
       2018-11-24 08:16:14 +08:00 via iPhone
    @Greenm
    在识别这个问题上
    在 proxy 这种应用环境下 ssl 只会死得更快
    另外那个 sssniff 只是一个玩具而已
    55aes 加密后的数据
    没有被爆破的可能
    那种超烂的 255 次改包检测法
    上 aead 之后也不存在了
    不过最安全还是隐藏协议实现
    nonce 和 tag 放哪你都不知道
    还有那个啥用 ml 来检测的我认为也是不存在的
    Mohanson
        21
    Mohanson  
       2018-11-24 12:02:18 +08:00 via Android
    @t6attack ssh 端口通常只会有小流量且低频的交互,你访问个网站突然几秒内出现几 M 流量, 太明显了。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5415 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 130ms · UTC 06:00 · PVG 14:00 · LAX 22:00 · JFK 01:00
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.