非常多啊，比如 TCP/IP，HTTP 等，都好多年前的了

@no1xsyzy 所以说，在没有浏览器的支持下，想再模仿一遍 HTTPS 都是不可能做到的。除非自己做一个客户端。

@no1xsyzy 是的，只要中间人往返回内容插 JS，记录用户操作，用户的账号密码就泄露了。
除非全站加密，问题是基于 HTTP 全站加密，浏览器端也解不了密，那用户看到的全是乱码

@type 写了一堆，才发现第一步的公钥返回给客户端时，就存在被中间人替换的可能，后面的步骤就没用了。https 是浏览器内置了 CA 根证书

@NoKey 使用 HTTPS 就是保护链路安全，如果只能使用 HTTP 还要保护链路数据，那最终还是要实现一个类似 HTTPS 的应用层，比如：

1. 使用 [非对称加密算法] ，生成公私钥，服务端持用私钥，公钥返回给客户端；

2. 客户端生成一个 32 位随机字符串，将账号、密码、随机字符串使用公钥加密，通过 POST 请求传给服务端；

3. 服务端将收到的数据使用私钥解密，并验证账号密码是否正确，如果正确，生成 Session，将随机字符串保存在 Session 中，并使用上述的随机字符串为密钥，使用 [对称加密算法] 加密返回信息，并返回给客户端，同时返回 JSESSIONID 到客户端的 COOKIE

4. 客户端使用之前生成的随机字符串为密钥，将服务端返回的数据使用 [对称加密算法] 解密，得到登录成功的信息

5. 后续客户端向服务端请求，都使用： [对称加密算法] 加密请求内容 再请求；

6. 服务端根据请求的 COOKIE，取出 Session 中的随机字符串，将请求解密；返回信息时也全部加密返回内容 再返回客户端；（使用 [对称加密算法] ）

描述有点混乱，大概就这么个思路，主要是按楼主的想法：保护客户端和服务端的交互信息；
随机字符串长度跟使用的 [对称加密算法] 有关，这里是以 AES256 来设定的;
第 2 3 段的公钥加密、私钥解密 都是使用 [非对称加密算法] ；
可能会有些其他缺陷...

关于上限这一块，其实是看天赋的

关注这个公众号很久了，推荐看看，多了解这些套路，提高防范意识

打开非常慢，在线下单付款后，竟然找不到刚下的订单，问客服，让到邮箱去找订单邮件；非常难用

之前很多办事网站的域名看起来挺山寨的，规范一下挺好的

生搬硬套

刚年会出来，两个节目都有女装

别问编辑器，问就是 Vim、Emacs ；
别问键盘，问就是 HHKB ；
别问电脑，问就是 MBP ；
别问，问就是天分。
---------------
+1

有人愿意做这件事，也有人愿意用，那就行了；
工具而已，各人喜好哪种就用那种，不喜欢不用就行了，难道还要作为异端用火烧死？

有人愿意做这件事，也有人愿意用，那就行了；
工具而已，各人喜好哪种就用那种，何必在这争论。

MIT 的 scratch，在中文系统环境下，关键字就是中文的。对学习者还是很友好的。