restkhz

我不得不说...

我自己就是 Manjaro+KDE 。用了好多年了。一个有 1050N 卡的笔记本。
第一天的时候刚装 Manjaro 直接不能开机. 最后要改内核引导参数。和 ACPI ，N 卡什么毛病有关。
而后想双显卡，经常出问题。卡顿，画面撕裂。后来直接全部 GPU 渲染，
不记得后面又有什么问题了，反正一番折腾再接下来就累了，直接 mhwd 默认 video-hybrid-intel-nvidia-prime 了。
但是默认配置也一直有问题。什么问题呢？

1. KDEconnect 或者什么东西弹出提示后有概率 KDE 卡死。弹窗不消失，工具栏，菜单无响应。
2. Alt+Tab 后界面直接卡死，卡到崩溃，等待几秒中然后 plasma 自己会重启。
3. 任何 CPU 渲染的界面都低帧率。弹个开始菜单卡成 PPT 。

这些问题困扰了我两年，甚至有时候弹窗卡住我就按 Alt+Tab 同时触发 Bug1 和 2 直接卡死让 plasma 快捷重启。试着解决无数遍，一直没啥效果...

直到今天，
楼主你发了这个帖子，我为了看看你说的 kvantum 全面升级了一下系统。
然后上面这个困扰我两年的问题莫名其妙的好了，但是 Chrome 莫名其妙卡得很，打开硬件加速就好了，跑起来一点问题没有。之前不开硬件加速是因为开硬件加速 Chrome 会崩溃....

额，谢谢楼主！...

顺便一说，我觉得 Manjaro KDE 默认的配置稍稍调调也很不错啊。

不好意思，没仔细审题，一次一密码，给上上下下都道个歉，想删除的时候不小心发出来了。尤其是给 @Citrus 道个歉，我没仔细审题。
你提醒我了，你说的对。送一个感谢表示诚意。

感觉怪怪的，想了一会，没想出有啥问题。

不安全，某些情况请千万不要这么做。你的理解大致是正确的，但是尽可能不要固定 IV 。

赞同 @liuidetmks

AES 归 AES ，但是你的加密模式是什么？楼主没有说。
比如，在上面说的 OFB 和 CTR 模式等等情况下，IV 重用并且密码重用的情况下基本就完蛋了。
比如 CTR ，你只需要知道你的明文去和密文 XOR 一下你就知道密码流了。未来的加密形同虚设。
在 CBC 模式虽然不会被直接破解，但是密文相同，破坏了语义安全。有些场景可以接受。

我简单介绍一下一些概念吧，完美安全和语义安全。
完美安全性就是密文本身不会透露任何明文信息。这个太难了。根据信息论，你需要随机密钥+密钥长度至少有明文那么长才能做到。这个时候你的熵就高的足以用来混淆任何一个明文 bit 。
所以楼上 @Citrus 其实说的不完全正确。因为你密码长度只要小了就是不行。不是说会暴力破解，单纯就是熵不够。
你说的严格一次一密，你是指每个 block 都一密码还是完全参照已有的 AES 模式呢？如果你能做到前者，恭喜你，但是直接换成 XOR 玩 OTP 可能更好。做到后者，比如 CBC 模式中，密码随机 IV 固定依旧做不到语义安全。
做到这个太难了。密钥生成，传输，都是问题。

于是人们退而求其次，密文可能会暴露明文信息，但无法被有效利用。这个就是语义安全了。
保存和更新密码的成本太高了。默认密码就会重用。设计的时候也是这么设计的。

这个时候引入 IV 你的确可以理解为增加信息熵，增加密文随机性。某种意义上来说 IV 解决了密码重用的问题(密码学角度的问题)

@raw0xff 你没搞明白的是谁在防谁。
这个机制不是让你服务器防着恶意客户，而是让正常客户防第三方网站的攻击。防止第三方攻击者在正常客户的浏览器中模拟正常请求访问你的接口。这个是在保护浏览器安全，不是保护服务器安全。

你的客户可能在第三方网站被钓鱼，假设没有同源策略，假设你是银行，此时恶意的第三方网站里有个脚本会在用户浏览器里运行：自动模拟你网站的转账操作，发给你的接口。由于没有同源策略，这个请求因为带着你客户的 cookie 等信息。你的客户就这样莫名其妙被偷了钱。

或者你是一个 webmail 但是人家也可以通过类似手段，在三方钓鱼网站里插脚本控制用户浏览器，进而偷到你客户的邮件。

你说请求在接口处理与否取决于你的代码，但是这个伪造的请求千真万确是客户端浏览器发的。看似完全正常的请求，正常的 Cookie ，同样的 IP 。Referer 头不靠谱而且可能被绕过，你说用 Token 但是 Token 也可能被偷(如果没有同源策略)。你服务器要怎么检查？？

因为这种攻击发生在客户端，所以客户的浏览器实现防御才比较容易。
于是有了同源策略 SOP ，注意，SOP 不阻止请求发出，但是可以阻止带着 Cookie 。还有非同源页面能否读网站响应。

你会发现请求不带 Cookie, 同时脚本不能跨源读数据，
上面说的两种攻击基本上就被阻断了。（当然实际情况更复杂些）
但是前后端分离也同样被阻断了。


你说的：
> "浏览器访问 a 网站时 a 网站的脚本访问 b 网站，无论是 post get 还是 options ，是否响应是 b 网站自身逻辑说的算的，即便 Access-Control-Allow-Origin:* 也只是告诉浏览器 b 允许所有来源访问，至于如何响应是看代码。"


带上 SOP 以后，由 a 发起的访问 b 网站的请求不会带有 b 的 cookie ，响应也未必能被 a 的页面读取。敏感操作和敏感信息都 a 都搞不了。

而 Access-Control-Allow-Origin 是 CORS 的一部分，作为同源策略 SOP 的扩展，允许你提供接口的服务器指定哪个网站可信(可以发 cookie 和可以读响应)，就是告诉浏览器第三方网站的白名单，白名单里的网站应该不会让浏览器发恶意请求，可以让 SOP 信任。CORS 给开发部署提供一些灵活性。这样你又可以前后端分离了。

顺便，你设置成 Access-Control-Allow-Origin:*的时候，浏览器的 Cookie 是不会发出去的。这整套机制都是怕浏览器被第三方恶意网站利用。
至于调试工具，，你不用调试工具当日常浏览器，不用担心被钓鱼，而且 CORS 也要被调试。所以当然不遵守这些。

楼上有人说的 CSS 应该是 XSS. 那个是 CSP 机制的事情。因为恶意脚本插入正常网站后是同源的。

楼主感到疑惑：貌似只是告诉客户端一个白名单让客户端自觉连接，服务端是不是还要判断 @$%^&%
楼主可能知道这是什么，但是不知道这个目的是什么...我们从头来说吧

5 楼说了安全问题。是的。如果 A 网站能读取浏览器保存的 B 网站的 Cookie ，或者 A 网站的脚本能随意让浏览器对 B 网站发起请求(比如转账操作)，是不是不安全？

于是搞了一个同源策略。如果非同源，即便要求发 Ajax 也会拒绝。非同源就 0 信任。
但是这样的同源策略是否有些过于严格？

如果我前后端分离，我域名或者端口就是不一样怎么办？我前端就是需要加载别的域名的 API 怎么办？反正我就是要加载非同源的东西，你一个同源策略因为安全问题就把它堵死了？搞得 AJAX 用不了。

楼主说的 Access-Control-Allow-Origin 这就来了。
后端需要告诉浏览器，哪个前端网站你可以信任，在他的页面可以给我发请求，我们是一家的。

这是设置一种因为信任而可以设置安全例外的做法。

客户端不自觉？那是客户端有安全缺陷。你做网站的恐怕做不了太多。

@cmdOptionKana 我赞同你的说法。
我也认为，如果特别“厌蠢”，可能缺乏耐心和换位思考能力，对结果焦虑或者有别的心理/情绪障碍。
但是也正常，谈不上心理障碍。

但是我个人认为不是逆反心理。可能你在当时感到焦虑在大脑里留下负面印象后，你父亲问你的时候你会开始 panic
尤其是渴望得到父母肯定的阶段，小孩会因为自己的行为而感到懊恼，或者因为父母的批评/压迫感而焦虑。
这种焦虑多次出现以后就会建立一个非常负面的正反馈。
以后会在每次遇到同样的事情时，焦虑发作，开始占用很多意识资源，思考不了。
在家长看来，一提这个问题怎么这倒霉孩子就和我急？这是和我“对着干”？逆反？


另外，说说 教人教不会
就像很多老年人不会用电子产品，因为他们对这东西没兴趣。很多年轻人觉得理所当然的 UI 设计他们也看不懂。
我举个例子

比如德语，krankenversicherung ，法语，intergouvernementalisations
对于母语者记忆这些词是比较轻松的。但是如果你不是，而且你没有基础，无论教还是学，都很痛苦。

换个更容易理解的角度说，
比如“沐浴”的“沐”，
我相信在这里的中文母语者应该都在学了“什么是三点水”，“木”这两个东西以后再接触这个字的。你很容易学会这个字的读写含义。
但是，你找个分不清中文日文的外国人，你让他学，他会很痛苦。
在他眼里只是觉得这是一堆点和线堆砌的复杂恶心的结构(还有笔划顺序)，还要记怎么读，什么读音，什么意思.....


同样我也想这里吐槽我的某些老师，他们支持“你学习时间越长越好”“你背下来就行”
这些老师很努力，很痛苦，很愤怒，很困惑。“这孩子是不是蠢...？”
其实你也很努力，很痛苦，很愤怒，很困惑。“我是不是真蠢......”

不是所有人都有一样的“基础知识”

回到这个主题，我不认为这是心理障碍。每个人都在用自己的视角看问题，很正常。
但是你也的确应该用别人的视角看一下，看一下别人知道什么，这坑多深得填。
如果你觉得教的成本过高且没收益，就算了。不生气。

简而言之：
Charles 篡改了通信内容，普通代理没有。
Charles 为了能抓包看明文，要破坏了加密，伪造证书搞中间人攻击。但是普通代理没在乎，看啥转啥。


不简而言之，说个场景：


A 和 B 要写信，这信都在盒子里送走，这盒子最好要上个锁，防着邮差。

于是 A 和 B 决定：

1. 正常通讯都用密码锁，安全还方便。
2. 所以，通讯之前，A 要把 密码锁的密码 发给 B 。然后他们就可以用密码锁和这个密码通信了。

问题是，这个送 密码锁的密码 的盒子，本身又该怎么确保安全？
3.于是，B 只能先把自己的，经过 ”权威机构认证的 B 专用锁” (B 的证书) 发过去，这锁的钥匙只有 B 他自己有。
4. 然后 A 收到后，就用 B 的锁，锁住里面是密码的盒子，发给 B 。
4. B 就可以用自己私人钥匙打开盒子，看到密码，接下来就可以也用 密码锁 锁住盒子来进行接下来的安全通信了。

Charles 和普通代理都是送盒子的邮差，但是有区别：
Charles 为了破坏加密，会在中途，把最开始 B 的锁换成自己配的锁，而自己则收下 B 的锁。这样，A 会用 Charles 的锁来锁盒子。A 想出的密码这下邮差 Charles 就能知道了。Charles 也可以假装 A 给 B 发一个自己编的密码。

Charles 可以对通信为所欲为，这样加密就完全被破坏了！

然而 A 发现 Charles 调包过的锁觉得不对劲，这锁也没经过权威机构认证啊，看起来绝对不是 B 的，我不接受！于是他停止了发信 (报个错)，B 也迟迟没收到来信所以这事情就没了下文。

(以上是过度简化且不准确的 TLS-RSA ，就不提 dhe 系列了。反正证书被换了就不该有下文。)


而普通代理该送啥就送啥。根本懒得看里面是啥，也压根没碰过。
管你是 https 还是 DNS ，还是什么锁，反正有东西我都送走就是了。

这里最大的区别就是：Charles 篡改了通信内容破坏加密，但是普通代理没有。


最后，你可以 root 后导入你 Charles 的证书到系统证书里。运气不好的话你可能遇到了 SSL Pin. 我之前用 Xposed 模块解决的这个问题。