Forwarded from 科技圈🎗在花频道📮 (Pineapple🍍)
泄密文件显示西班牙想要禁止端对端加密
《连线》报道，一份泄密文件显示西班牙想要禁止端对端加密。欧盟委员会向其成员国询问了对加密进行监管的意见。西班牙对端对端加密的立场最为坚决，该国认为应该立法阻止欧盟的服务商实现端对端加密。
西班牙称，访问所有数据是至关重要的，加密通信应该能解密。而端对端的加密和解密是在通讯端的双方进行的，因此服务商也无法知道会话内容，这能有效防止第三方监听。欧盟其它国家也有多个国家主张弱加密：波兰建议允许法院命令解密，认为父母有权解密儿童的通信。
https://www.wired.com/story/europe-break-encryption-leaked-document-csa-law/
《连线》报道，一份泄密文件显示西班牙想要禁止端对端加密。欧盟委员会向其成员国询问了对加密进行监管的意见。西班牙对端对端加密的立场最为坚决，该国认为应该立法阻止欧盟的服务商实现端对端加密。
西班牙称，访问所有数据是至关重要的，加密通信应该能解密。而端对端的加密和解密是在通讯端的双方进行的，因此服务商也无法知道会话内容，这能有效防止第三方监听。欧盟其它国家也有多个国家主张弱加密：波兰建议允许法院命令解密，认为父母有权解密儿童的通信。
https://www.wired.com/story/europe-break-encryption-leaked-document-csa-law/
Forwarded from 平壤卫视
This media is not supported in your browser
VIEW IN TELEGRAM
Forwarded from MET WARN 天氣預警
This media is not supported in your browser
VIEW IN TELEGRAM
美國關島今日受超強颱風瑪娃吹襲期間，當地有民眾拍攝到有汽車在猛烈風力吹襲下被吹至多次翻滾。
（Credit: Gingercruz's Twitter）
（Credit: Gingercruz's Twitter）
Forwarded from 愛玉大麻 🍼 ฅ(✖ᴥ🔺️)ノ 阿巴阿巴的貓尾海獺q= •̀∞•́ =p
Forwarded from 叮当喵喵-今天你也很可爱
This media is not supported in your browser
VIEW IN TELEGRAM
#在线旅游
千里共婵娟哈
千里共婵娟哈
Forwarded from Project X Channel
警惕 SNI 白名单地区隐蔽的大规模“降级攻击”
根据长期的观察，以及多位身处 SNI 白名单地区的群友的反馈，这些地区的 IPv4 TCP 并不封锁 SS、VMess 这类全随机数裸协议，与其它地区的封锁策略形成了鲜明的反差，是一种非常反常的现象。
我们已知对于封锁翻墙流量，SNI 白名单是一种附带伤害极高的方式，我们也知道，其它地区的 GFW 正在轻易识别并封锁全随机数裸协议。那么请大家思考：为什么某些地区并不在乎附带伤害，对 TLS 采用 SNI 白名单这样的强过滤策略，却“完全不管”全随机数裸协议？
只有一种可能：故意留的口子，除此之外没有任何其它合理解释。我们已知相较于 TLS，全随机数裸协议相当于是把翻墙写在了脸上，更便于识别、掌握情况。且它们普遍缺乏 TLS 的“前向安全”等高级安全特性，非常原始，通过某种方式拿到密码就可以解密以前、以后的所有流量，非常利于监控。所以我认为，这种 SNI 白名单+不封锁全随机数裸协议的组合策略，实质上是在迫使人们从较为安全的 TLS 协议迁移到不够安全的全随机数裸协议，是一场隐蔽的大规模“降级攻击”。
SNI 白名单地区存在的这种非常反常的现象也从侧面证实了，我在多个场合曾提醒过的关于全随机数裸协议的种种风险切实存在，就连 GFW 也明确希望你们使用全随机数裸协议而不是 TLS。目前，这些地区仍可直接使用 REALITY，且它解决了 TLS 令人诟病的 CA 风险。或者，配置 REALITY over SS：https://github.com/XTLS/Xray-core/discussions/1811#discussioncomment-5355075
根据长期的观察，以及多位身处 SNI 白名单地区的群友的反馈，这些地区的 IPv4 TCP 并不封锁 SS、VMess 这类全随机数裸协议，与其它地区的封锁策略形成了鲜明的反差，是一种非常反常的现象。
我们已知对于封锁翻墙流量，SNI 白名单是一种附带伤害极高的方式，我们也知道，其它地区的 GFW 正在轻易识别并封锁全随机数裸协议。那么请大家思考：为什么某些地区并不在乎附带伤害，对 TLS 采用 SNI 白名单这样的强过滤策略，却“完全不管”全随机数裸协议？
只有一种可能：故意留的口子，除此之外没有任何其它合理解释。我们已知相较于 TLS，全随机数裸协议相当于是把翻墙写在了脸上，更便于识别、掌握情况。且它们普遍缺乏 TLS 的“前向安全”等高级安全特性，非常原始，通过某种方式拿到密码就可以解密以前、以后的所有流量，非常利于监控。所以我认为，这种 SNI 白名单+不封锁全随机数裸协议的组合策略，实质上是在迫使人们从较为安全的 TLS 协议迁移到不够安全的全随机数裸协议，是一场隐蔽的大规模“降级攻击”。
SNI 白名单地区存在的这种非常反常的现象也从侧面证实了，我在多个场合曾提醒过的关于全随机数裸协议的种种风险切实存在，就连 GFW 也明确希望你们使用全随机数裸协议而不是 TLS。目前，这些地区仍可直接使用 REALITY，且它解决了 TLS 令人诟病的 CA 风险。或者，配置 REALITY over SS：https://github.com/XTLS/Xray-core/discussions/1811#discussioncomment-5355075
GitHub
REALITY + socks5 = ? · XTLS Xray-core · Discussion #1811
由于 socks 和 http 代理都被无脑阻断，所以这个方法没用，是我云了 最近想到一个“偷证书”类型的代理的加强使用方式(补充：REALITY 不是偷证书)：偷白名单的证书 + socks5 代理 Xray 服务端使用以下配置： { "inbounds": [ { "listen": "127.0.0.1", "por...