https简介以及仿https的加密tcp安全通道的简要设计思路
来源:互联网 发布:安徽管家婆软件 编辑:程序博客网 时间:2024/05/16 12:30
今天, 我们来说说https, 也就是安全的http.
怎么个安全法? 那肯定是要对传输的数据进行加密, 为了效率, 我么可以考虑用对称加密算法, 如典型的AES. 那么问题来了, 客户端和服务端怎样才能拥有相同的对称秘钥key呢? 显然, 可以考虑从客户端端随机生成一个秘钥, 然后传递了服务端, 这不就行了吗? 是的。
但是, 传递这个秘钥的过程, 是一个不靠谱的过程, 如果秘钥被坏人中途截获怎么办? 显然, 坏人也是可以用秘钥key来解密传输内容的, 安全性无从说起。
那怎么办呢? 可以考虑这样一种情况, 如果客户端有RSA公钥, 那么就可以对对称秘钥key进行加密保护, 传递给服务端, 即使中途被截获, 也不怕, 因为必须要有RSA私钥才能解开内容, 所以, 这样就保护了对称秘钥key不被中途截获, 问题貌似就解决了。 恩。
但是, 这又引入了一个新的问题, 客户端的RSA公钥和服务端的RSA私钥是怎么分配的? 必然要从一段传递到另外一端啊。 我们考虑, 在服务端生成RSA公钥和RSA私钥, 然后服务端传递给客户端, 这不就OK了吗? 公钥是公开的, 坏人知道了公钥又能如何? 恩。
可是, 坏人可以在中间过程生成一对假的RSA秘钥对, 然后把坏人把假的RSA公钥发给客户端, 坏人自己持有假的RSA私钥, 于是, 客户端实际上在跟中间的坏人进行通信, 客户端浑然不知。这就引入了一个新的问题: 客户端怎么知道自己手上的RSA公钥是服务端派发的还是中间坏人的呢? 这里就引入了数字证书的概念。
第三方机构对服务端的RSA公钥进行认证(确保真实无误,且没有篡改), 那么问题就完全解决了。 怎么实现的呢? 第三方认证中心用自己的RSA私钥对服务端(目的是发给客户端)的RSA公钥进行保护, 客户端拿个第三方机构的RSA公钥来解出服务端的RSA公钥, blablablalbla, 于是认为服务端的RSA公钥可信。 那么问题来了, 客户端怎么获取到第三方机构的RSA公钥呢? 这就是涉及到认证的流程了,扯多了, 会涉及到根证书的概念。 会有一点点复杂。 有兴趣的朋友, 可以看看认证流程和原理。
有很多数字认证公司, 就是专门干这些事的, 专门派发数字证书, 完成数字认证。
说了这么多, 而且都是用文字说明的, 比较绕了。 最好是画图来理解。 如上就是https的大致原理, 其实也比较简单。
接下来, 我们来看tcp安全通道的设计, 我为什么想说这个呢? 因为我之前碰到过。 仿https的简单方案可以如下:
1. 服务端生成RSA密钥对, 然后在合作中, 服务端的同事直接把RSA公钥发给客户端同事。(可以通过QQ发, 通过微信发, 或者写在文档文档中)
2. 客户端随机随机生成对称秘钥key, 然后用RSA公钥加密, 发送到服务端。
3. 服务端用RSA私钥来解密, 得到对称秘钥key。
4. 客户端和服务端用用对称秘钥key对通信内容进行AES加密。
安全, 搞定。 不多说。
我都是用文字来说明的, 喷的时候, 请轻点, 谢谢。
- https简介以及仿https的加密tcp安全通道的简要设计思路
- Tomcat8+Spring-Security 启用安全通道(https)的一步步实现
- TCP/IP、Http、Https、Socket的简介
- https加密的实现
- Https加密的实现
- 更安全的HTTPS
- web安全的HTTPS
- https的安全密钥
- HTTPS的安全保护
- https安全传输和内容加密的短信接口代码
- 一般的加密技,数字证书,https以及其他
- 未能创建SSL/TLS安全通道,导致的通过HTTPS协议访问WCF服务
- HTTPS 是怎么加密的
- https的加密解密过程
- HTTPS加密套件的笔记
- 改用更安全的HTTPS
- HTTPS为什么是安全的
- Https为什么是安全的
- 最全Pycharm教程(41)——Pycharm扩展功能之便签注释
- Spring AOP简单的配置(注解和xml配置)
- 阿柟的NOIP冲刺计划
- CSS中英文换行问题
- 27. netstat
- https简介以及仿https的加密tcp安全通道的简要设计思路
- Gym 101490K
- redis字符串命令
- preparedStatement介绍
- 实现一键群发126邮件(基础版Webpower)
- Java中return用法.
- 最全Pycharm教程(42)——Pycharm扩展功能之Emacs外部编辑器
- nginx中的nginx.conf.default配置
- 并发技术_1_Semaphore