Home Sign Up Sign In
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
busier
V2EX  ›  程序员

实现一个纯 Web 界面的端到端加密临时聊天对话思路是否可行？

  •   
  •   busier · Jun 5, 2024 · 5227 views
    This topic created in 893 days ago, the information mentioned may be changed or developed.
    假如想实现一个纯 Web 界面的端到端加密临时聊天对话

    通过 openpgpjs 项目，在客户端浏览器纯前端实现 PGP 加解密

    服务器端只负责交换公钥和转发客户端传过来的加密消息，保证服务器管理员无法解密阅读消息内容

    免用户注册机制，服务器通过 PGP 公钥来标识用户，列出在线用户及 PGP 公钥

    用户"密钥对"在用户浏览器加载页面时随机生成，不上传不保存私钥，关闭浏览器私钥丢失，所有消息将被废弃不可解密。

    这样的设计思路有无技术可行性，或者有什么重大缺陷？

    已知问题：无法确认对方身份，需要通过其它渠道交换公钥来确认身份。

    其它问答题希望听听大家意见
  • Web
  • 加密
  • 临时
    46 replies  •  2024-06-06 13:04:07 +08:00
    fruitmonster
    fruitmonster
    Jun 5, 2024
    1
    第一个问题：给谁用，使用场景是啥
    busier
    busier
    OP
    Jun 5, 2024 via iPhone
    2
    @fruitmonster 场景就是加密传输临时消息啊，又不想被别人获取。比方说打个加密压缩包传给同事，但是密码又不想明文发过去。

    只讨论技术实现及缺陷，这类其它问题不再讨论范畴。
    makaflow
    makaflow
    Jun 5, 2024
    3
    国内是不行，无法监管就会被叫停
    7lQM1uTy635LOmbu
    7lQM1uTy635LOmbu
    Jun 5, 2024
    4
    @busier 服务器不要留存信息，转发的消息确认送达后直接删除，并且应该设置 ttl ，最大存活时间，可以由发送方自定义，并且由发送方决定超时是否由服务器代替发送超时通知，但最大不能超过 x ，超时直接删除。

    即便是同一对通信用户，请定期 rotate 密钥对，确保历史消息不可被物理解除后恢复。

    至于安全交换公钥，印象中有看到过相关方案，反正是个已经解决的问题。

    如何防止中间人攻击？（比如劫持，代理）
    cassidy0134
    cassidy0134
    Jun 5, 2024
    5
    @busier 本人 ops 一枚，有多台海外服务器（ sg ，us ），我不想暴露自己但想帮 op 测试这个页面和 app ，ops 相关的工作可以全部我来，你只要写代码即可，如果愿意，请给我一个临时联系方式。
    cassidy0134
    cassidy0134
    Jun 5, 2024
    6
    其实我也早就想做这件事，奈何不会写代码~
    shinsekai
    shinsekai
    Jun 5, 2024
    7
    telegram web 算 OP 所说的吗？
    ltkun
    ltkun
    Jun 5, 2024
    8
    如果不是 web 可以选择 k9mail 这种 使用普通 email 就能端到端的 app
    dj721xHiAvbL11n0
    dj721xHiAvbL11n0
    Jun 5, 2024❤️2
    9
    都通过其它渠道交换公钥了，我干嘛不直接通过那个渠道顺便把加密消息一起发了得了？
    dislazy2023
    dislazy2023
    Jun 5, 2024
    10
    感觉可行，这个用来做临时聊天还是很有用处，我也一直在找这样的开源 web ，不太好找
    jeesk
    jeesk
    Jun 5, 2024
    11
    肯定可行, 不过没什么鸟用呀
    jeesk
    jeesk
    Jun 5, 2024
    12
    使用场景? 如果仅仅是分享问价? 那么直接临时启动一个 http-server 即可
    ooolooo
    ooolooo
    Jun 5, 2024
    13
    @shinsekai 不算, tg 有账号系统
    tg 也没有默认端到端加密, web 更不是
    wushenlun
    wushenlun
    Jun 5, 2024 via Android
    14
    email pgp 加密不就好了 或者 whatsapp
    ArthurSS
    ArthurSS
    Jun 5, 2024
    15
    webrtc 不是可以直接支持？
    ArthurSS
    ArthurSS
    Jun 5, 2024
    16
    很早以前写了一个小 demo ，用的免费信令服务器，国内不一定能连接上： https://arthursuz.github.io/peer-link/
    输入另外一边的 id ，既可建立连接，完全 p2p
    Nazz
    Nazz
    Jun 5, 2024
    17
    可行, 逻辑全部走 WASM
    Nazz
    Nazz
    Jun 5, 2024
    18
    内置证书
    superkkk
    superkkk
    Jun 5, 2024 via iPhone
    19
    https://www.v2ex.com/t/1043160
    Conda
    Conda
    Jun 5, 2024
    20
    我歪个楼，我们业务里的埋点和日志这类通用的服务就是基于 protobuf 传输的，发送前加密通过正常的 http 发送加密后的字符串，服务端拿到之后再解密，这个思路和你的聊天工具也是类似的吧，只要按我的格式传过来就行。
    shadowyue
    shadowyue
    Jun 5, 2024
    21
    可行，但是功能单一估计用户太少怕维持运营成本都难。看你怎么在其他方面上发挥，比如约炮啥的🤣
    lingo
    lingo
    Jun 5, 2024❤️1
    22
    http://element.io

    自己 docker 开个服务器就好
    ZhiyuanLin
    ZhiyuanLin
    Jun 5, 2024
    23
    传输可以走 WebRTC ，双客户端之间通过 WebSocket signalling 建立 WebRTC 直连，大文件传输不用经过服务器。
    之前搞得科研项目用用到这俩技术。
    ZhiyuanLin
    ZhiyuanLin
    Jun 5, 2024
    24
    缺点是双方都是 symmetric NAT 的话是没法建立连接的，除非你提供 TURN server
    ZhiyuanLin
    ZhiyuanLin
    Jun 5, 2024❤️1
    25
    WebRTC 在 Signalling 期间本身就确立了端对端加密，所以你其实不用搞 openpgpjs 之类麻烦东西。
    ZhiyuanLin
    ZhiyuanLin
    Jun 5, 2024
    27
    关于公钥的交换，可以直接提取 WebRTC 的公钥在其他渠道交换。
    kkocdko
    kkocdko
    Jun 5, 2024
    28
    可行而且早就有人实现过了，善用 google
    luxor
    luxor
    Jun 5, 2024
    29
    element.io
    meeop
    meeop
    Jun 5, 2024
    30
    可行,但没用,以及已经有很多人实现过了,以及 99%场景用电报之类就行,再不行分享网盘邮箱之类
    busier
    busier
    OP
    Jun 5, 2024
    31
    @nevadax "如何防止中间人攻击？（比如劫持，代理）"
    我说过了：“无法确认对方身份，需要通过其它渠道交换公钥来确认身份。”
    公钥一旦确认，中间人问题就解决了！

    @x2420390517 “都通过其它渠道交换公钥了，我干嘛不直接通过那个渠道顺便把加密消息一起发了得了？”
    已有渠道并不提供方便的端 PGP 加解密操作。你要来回复制粘贴密文来操作么！！！

    @jeesk “使用场景? 如果仅仅是分享问价? 那么直接临时启动一个 http-server 即可”
    与 http-server 单分享是不同的。端到端的加密，要求服务器端也获取不到明文内容。
    keithwhisper
    keithwhisper
    Jun 5, 2024
    32
    可以看下 ECash Chat
    0o0O0o0O0o
    0o0O0o0O0o
    Jun 5, 2024
    33
    推荐这篇讨论 https://news.ycombinator.com/item?id=39436238 浏览器有往这方面发展的趋势，但并不够

    E2EE 可以让用户只信任客户端，我个人对 E2EE 应用的要求是：开源的客户端、客户端会执行的代码在编译后就是确定的、客户端经过审计。而对于你的 "纯 Web 界面的端到端加密"，用户还必须信任浏览器每次加载的页面，你作为网站管理员被胁迫了或者你服务器被黑了怎么办？你用的 CDN 被黑了怎么办？还是说你打算单独分发前端源码文件？
    raw0xff
    raw0xff
    Jun 5, 2024
    34
    @Nazz 全走 wasm 的目的是？

    客户端浏览器临时生成密钥对除了 webcrypto api 和在 wasm 中生成，还有哪些方式？（不算浏览器扩展的话）
    window.crypto.subtle.generateKey 时 extractable:ture 的话可以导出私钥，我觉得还是有一定风险的。
    所以你说的全走 wasm 意思是在 wasm 沙盒中生成公私钥对吗？ wasm 存私钥的变量是否会被 js 读出来？

    楼主可以看看去年的 nostr 项目，应该也属于 e2ee.
    raw0xff
    raw0xff
    Jun 5, 2024
    35
    @0o0O0o0O0o 哈哈总会碰到 oo 大佬，你这个链接也给过我。
    chinni
    chinni
    Jun 5, 2024
    36
    邮件 gpg 呗
    Nazz
    Nazz
    Jun 5, 2024 via Android
    37
    @raw0xff 保护密钥和源代码
    busier
    busier
    OP
    Jun 5, 2024
    38
    @0o0O0o0O0o 在终端加密的目的就是解决服务器不可靠时，管理员也获取不到明文信息，包括 CDN 也是。
    你所提到的页面被黑被撰改问题，这在所有 Web 网站都存在此风险。并不是我这个设计特有的，算不得此设计缺陷。
    话所说回来，加解密部分的代码是静态不改变且开源的，用户只要校对这部分代码(或设计个校对功能)便不是问题。
    raw0xff
    raw0xff
    Jun 5, 2024
    39
    @busier 你可能没有意识到在不能保证用户访问的第一个页面的完整性的前提下 e2ee 并不安全。
    0o0O0o0O0o
    0o0O0o0O0o
    Jun 5, 2024
    40
    @busier #38

    我在 #33 并没有将你的应用跟“所有 Web 网站”对比，我是将你的应用与常见的 E2EE 应用做对比。它们解决了，而你的方案或者说浏览器没解决，在这个重要问题没有解决的时候说 "解决服务器不可靠"、"管理员也获取不到明文信息，包括 CDN 也是" 就是不对的。

    > 加解密部分的代码是静态不改变且开源的
    > 用户只要校对这部分代码(或设计个校对功能)便不是问题

    首先，我认为不可能只审计一部分代码，而是你的网站前端的所有代码都要审计，而目前 Web 的运作方式让这个事情失去它应有的意义，因为作为用户根本没办法保证下一次请求的代码不会变。除非你自己分发前端 HTML 文件，或者用个外部软件来提供保障，那这也就和你原文中 "客户端浏览器纯前端"、 "浏览器加载页面时" 矛盾了。
    busier
    busier
    OP
    Jun 5, 2024
    41
    确实存在 raw0xff “ 你可能没有意识到在不能保证用户访问的第一个页面的完整性的前提下 e2ee 并不安全。”说的问题

    此设计中，前端本就是纯静态，分发前端 HTML 方案可行。
    raw0xff
    raw0xff
    Jun 6, 2024
    42
    大概分三个问题：用户身份验证、私钥安全存储、页面完整性校验

    目前被困在页面完整性实时校验问题上。
    raw0xff
    raw0xff
    Jun 6, 2024
    43
    @Nazz 我对逆向工程不懂，wasm 嵌入证书的话是否会被逆向出来？ wasm 中的变量是否会被恶意 js 脚本读出来？
    busier
    busier
    OP
    Jun 6, 2024 via iPhone
    44
    @raw0xff
    考虑运行时选择通信服务器。至于页面分发部分就独立出来，让用户通过自己的受信渠道分发。
    Nazz
    Nazz
    Jun 6, 2024
    45
    @raw0xff 逆向没那么容易
    qfdk
    qfdk
    PRO
    Jun 6, 2024 via Android
    46
    双认证 吧 试试？
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Privacy   ·   Solana   ·   866 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 71ms · UTC 21:33 · PVG 05:33 · LAX 13:33 · JFK 16:33
    ♥ Do have faith in what you're doing.