目录
HTTPS 也是一个应用层协议,HTTPS是基于HTTP协议+安全层(SSL/TLS用来加密的协议)实现的
HTTP 协议内容都是按照文本的方式明文传输的,导致在传输过程中出现一些被篡改的情况,由于我们通过网络传输的任何的数据包都会经过运营商的网络设备(路由器, 交换机等), 那么运营商的网络 设备就可以解析出你传输的数据内容, 并进行篡改
前文也说过运营商劫持的问题,为什么要进行这样的篡改呢?说白了还是被金钱蒙蔽了双眼.假如当我们点击 "下载按钮", 其实就是在给服务器发送了一个 HTTP 请求, 获取到的 HTTP 响应其实就包含了该 APP 的下载链接. 运营商劫持之后, 就发现这个请求是要下载这个APP, 那么就自动的把交给用户的响应给篡改成另外的的下载地址(另一个APP)了,一下载就变成别的了,这样做的原因肯定是这个APP给钱了!!
所以下载要使用的软件一定要去官网上下载!要下载有份概念的软件,可以在虚拟机上下载,因为虚拟机可以随时回退,删除,比较安全
HTTP是明文传输的,比较危险.为了解决运营商劫持的问题,要进行对数据的加密
加密就是把明文(要传输的信息)进行一系列变换生成密文
解密的过程就是将密文再进行一系列变换还原成明文
在这个加密和解密的过程中,还需要一个或多个中间数据,辅助这个过程,这样的数据称为密钥
所以我们大概可以知道加密解密的过程如图
加密解密也已经发展为独立的学科:密码学
这里还要提到一位大佬,就是密码学的奠基人, 也正是计算机科学的祖师爷之一, 艾伦·麦席森·图灵
为了保证数据的安全就需要对数据进行加密,网络传输中不再直接明文传输,而是加密之后的密文
加密方式可分为两大类:对称加密和非对称加密
先了解一下对称加密
明文a+key=>密文b
密文b+key=>明文a
很明显,对称加密其实就是通过同一个 "密钥" , 把明文加密成密文, 并且也能把密文解密成明文
看一个简单的对称加密, 按位异或
假设
明文:123456
key:123123
加密:
解密:
对称密钥的安全性前提是,密钥不能泄露
由于没有密钥,及时截取了密文,没有密钥解密,也不知道数据是什么意思
那么密钥是谁生成的呢.由于一个服务器对应很多个客户端,因此每个客户端都要有不同的密钥,如果密钥相同,那么和没有一样了..因此服务器还需要维护每个客户端和每个密钥之间的关联关系,也比较麻烦,需要记录每个客户端的密钥..所以为了节省服务器资源,更理想的做法是不进行记录
当客户端和服务器建立连接的时候,双方协定这次使用什么密钥传输数据,过程如图所示
由于第一次服务器也不知道客户端的密钥是什么,需要客户端明文传送密钥给服务器.那么此时如果被截取,密钥就泄露了.因此密钥的传输也必须加密传输!很显然,对密钥加密不能再使用对称加密了
引入了非对称加密
非对称加密要用到两个密钥, 一个叫做 "公钥", 一个叫做 "私钥"
公钥是公开的,私钥是隐私的.服务器生成一对密钥,客户端持有公钥,服务器私藏私钥
公钥和私钥是配对的. 最大的缺点就是运算速度非常慢，比对称加密要慢很多
非对称加密过程
公钥+明文=>密文
私钥+密文=>明文
或者反过来也可以
非对称加密过程:
客户端先在本地生产对称密钥,然后通过公钥加密,发送给服务器
由于中间网络设备没有私钥,即使截获了数据,也不能还原出明文,获取对称密钥
服务器通过私钥解密,获取对称密钥,并使用对称密钥加密返回给客户端的响应数据
第一次使用非对称加密,确保了对称加密密钥没有泄露.因此后续的客户端服务器通信都使用对称加密即可
注意:由于对称加密的效率比非对称加密高很多, 因此只是在开始阶段协商密钥的时候使用非对称加密, 后续的传输仍然使用对称加密
问题又来了.客户端如何才能获取到公钥呢?我们看下面的场景
这个场景大概就是客户端不知道p2这个公钥是假的,然后还通过p2传输了对称密钥给黑客
黑客拿着对称密钥使用p1公钥进行加密后传给服务器
服务器就使用pri1解密收到的数据,获取到对称密钥,后续通信都以这个密钥进行加密
这也就是中间人攻击问题
解决中间人攻击问题的关键:客户端要能正确的识别公钥是否来自真正的服务器
为了解决这个问题引入了"证书"
证书 可以理解成是一个结构化的字符串, 里面包含了以下信息: 证书发布机构 证书有效期 公钥 证书所有者 签名 ......
客户端拿到一个证书会判定:
证书的有效期是否过期
证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构)
证书是否被篡改
在客户端和服务器刚一建立连接的时候, 服务器给客户端返回一个 证书. 这个证书包含了刚才的公钥, 也包含了网站的身份信息,证书本质是一个第三方认证机构提供的,服务器具有合格的条件就能申请证书,服务器生成的密钥也包含在证书中.
此时客户端请求公钥时,是将整个证书都请求过来.客户端拿到证书后就对证书进行校验(验证证书是不是假的或被篡改的.如果证书无效,浏览会弹窗警告)证书上面会有特定的字段,叫做证书的签名.
客户端使用第三方认证机构提供的公钥进行解密,解密后得到的结果相当于一个哈希值,类似于校验和,客户端可以使用同样的哈希算法针对其他字段再算一次哈希值买得到的哈希值如果相同,就说明证书是有效的,没有被篡改
那么黑客能篡改证书么?比如说替换掉公钥?
答案是不行的,一旦替换了公钥,意味着从客户端计算的哈希值和从签名中解密的哈希值不同,客户端就发现证书无效
引入证书后,通信过程:
HTTPS 工作过程中涉及到的密钥有三组
第一组(非对称加密): 用于校验证书是否被篡改. 服务器持有私钥(私钥在注册证书时获得), 客户端持有公钥(操作系统包含了可信任的 CA 认证机构有哪些, 同时持有对应的公钥). 服务器使用这个私钥对证书的签名进行加密. 客户端通过这个公钥解密获取到证书的签名, 从而校验证书内容是否是篡改过
第二组(非对称加密): 用于协商生成对称加密的密钥. 服务器生成这对私钥-公钥, 然后通过证书把公钥传递给客户端. 客户端用这个公钥给生成的对称加密的密钥加密, 传输给服务器, 服务器通过私钥解密,获取到对称加密密钥
第三组(对称加密): 客户端和服务器后续传输的数据都通过这个对称密钥加密解密
1.错误信息：Errorresponsefromdaemon:Gethttps://registry-1.docker.io/v2/:net/http:requestcanceledwhilewaitingforconnection(Client.Timeoutexceededwhileawaitingheaders)或者：Errorresponsefromdaemon:Gethttps://registry-1.docker.io/v2/:net/http:TLShandshaketimeout2.报错原因：docker使用的镜像网址默认为国外，下载容易超时，需要修改成国内镜像地址（首先阿里
最近在学习CAN，记录一下，也供大家参考交流。推荐几个我觉得很好的CAN学习，本文也是在看了他们的好文之后做的笔记首先是瑞萨的CAN入门，真的通透；秀！靠这篇我竟然2天理解了CAN协议！实战STM32F4CAN！原文链接：https://blog.csdn.net/XiaoXiaoPengBo/article/details/116206252CAN详解（小白教程）原文链接：https://blog.csdn.net/xwwwj/article/details/105372234一篇易懂的CAN通讯协议指南1一篇易懂的CAN通讯协议指南1-知乎(zhihu.com)视频推荐CAN总线个人知识总
尝试通过SSL连接到ImgurAPI时出现错误。这是代码和错误:API_URI=URI.parse('https://api.imgur.com')API_PUBLIC_KEY='Client-ID--'ENDPOINTS={:image=>'/3/image',:gallery=>'/3/gallery'}#Public:Uploadanimage##args-Theimagepathfortheimagetoupload#defupload(image_path)http=Net::HTTP.new(API_URI.host)http.use_ssl=truehttp.verify
一、什么是MQTT协议MessageQueuingTelemetryTransport：消息队列遥测传输协议。是一种基于客户端-服务端的发布/订阅模式。与HTTP一样，基于TCP/IP协议之上的通讯协议，提供有序、无损、双向连接，由IBM（蓝色巨人）发布。原理：（1）MQTT协议身份和消息格式有三种身份：发布者（Publish）、代理（Broker）（服务器）、订阅者（Subscribe）。其中，消息的发布者和订阅者都是客户端，消息代理是服务器，消息发布者可以同时是订阅者。MQTT传输的消息分为：主题（Topic）和负载（payload）两部分Topic，可以理解为消息的类型，订阅者订阅（Su
TCL脚本语言简介•TCL（ToolCommandLanguage）是一种解释执行的脚本语言（ScriptingLanguage）,它提供了通用的编程能力：支持变量、过程和控制结构；同时TCL还拥有一个功能强大的固有的核心命令集。TCL经常被用于快速原型开发，脚本编程，GUI和测试等方面。•实际上包含了两个部分：一个语言和一个库。首先，Tcl是一种简单的脚本语言，主要使用于发布命令给一些互交程序如文本编辑器、调试器和shell。由于TCL的解释器是用C\C++语言的过程库实现的，因此在某种意义上我们又可以把TCL看作C库，这个库中有丰富的用于扩展TCL命令的C\C++过程和函数，所以，Tcl是
我每次打开终端时都会收到这个错误:警告:PATH设置为RVMruby但未设置GEM_HOME和/或GEM_PATH，请参阅:https://github.com/wayneeseguin/rvm/issues/3212这是在我最近安装zsh(oh-my-zsh)后开始发生的我不知道如何设置GEM_HOME和/或GEM_PATH的路径。 最佳答案 我也面临同样的问题，更改.zshrc中的以下行，exportPATH="/usr/local/heroku/bin:.........."到exportPATH="$PATH:/usr/
我正在尝试使用RubyEventMachine访问使用SSL证书身份验证的HTTPSWeb服务，但我没有让它工作。我编写了以下简单代码块来对其进行端到端测试:require'rubygems'require'em-http'EventMachine.rundourl='https://foobar.com/'ssl_opts={:private_key_file=>'/tmp/private.key',:cert_chain_file=>'/tmp/ca.pem',:verify_peer=>false}http=EventMachine::HttpRequest.new(url).g
出于某种原因，在我的开发机器上，我对通过Net::HTTP执行的HTTPS请求的响应非常非常慢。我试过RestClient和HTTParty，它们都有同样的问题。它似乎是凭空冒出来的。我已毫无问题地提出这些请求数百次，但今天它们的速度慢得令人难以忍受。pry(main)>putsTime.now;HTTParty.get('https://api.easypost.com/v2/addresses');putsTime.now;2015-04-2908:07:08-05002015-04-2908:09:39-0500如您所见，响应耗时2.5分钟。不仅仅是这个EasyPostAPIUR
我看过几个用Ruby编写HTTP代理的例子，例如thisgistbyTorstenBecker，但我如何扩展它来处理HTTPS，又名“中间人”SSL代理？我正在寻找一个简单的源代码框架，我可以扩展它以满足我自己的日志记录和测试需求。更新我已经在使用Charles,aniftyHTTPSproxyapp类似于Fiddler，它本质上是我想要的，只是它被打包在一个应用程序中。我想自己写一个，因为我对过滤和展示有特定的需求。更新二四处浏览后，我对术语的理解有所好转。我不是在寻找完整的“中间人”SSL代理。相反，它将在我的机器上本地运行，因此我可以接受它提供的任何SSL证书。但是，我需要查看我
一、RIPV2协议简介 RIP(RoutingInformationProtocol)路由协议是一种相对古老，在小型以及同介质网络中得到了广泛应用的一种路由协议。RIP采用距离向量算法，是一种距离向量协议。RIP-1是有类别路由协议（ClassfulRoutingProtocol），它只支持以广播方式发布协议报文。RIP-1的协议报文无法携带掩码信息，它只能识别A、B、C类这样的自然网段的路由，因此RIP-1不支持非连续子网（DiscontiguousSubnet）。RIP-2是一种无类别路由协议（ClasslessRoutingProtocol），支持路由标记，在路由策略中可根据路由标记对
