超文本传输协议HTTP协议被用于在Web浏览器和网站服务器之间传递信息,HTTP协议以明文方式发送内容,不提供任何方式的数据加密,若是攻击者截取了Web浏览器和网站服务器之间的传输报文,就能够直接读懂其中的信息,所以,HTTP协议不适合传输一些敏感信息,好比:信用卡号、密码等支付信息。css
为了解决HTTP协议的这一缺陷,须要使用另外一种协议:安全套接字层超文本传输协议HTTPS,为了数据传输的安全,HTTPS在HTTP的基础上加入了SSL协议,SSL依靠证书来验证服务器的身份,并为浏览器和服务器之间的通讯加密。html
HTTP:是互联网上应用最为普遍的一种网络协议,是一个客户端和服务器端请求和应答的标准(TCP),用于从WWW服务器传输超文本到本地浏览器的传输协议,它可使浏览器更加高效,使网络传输减小。算法
HTTPS:是以安全为目标的HTTP通道,简单讲是HTTP的安全版,即HTTP下加入SSL层,HTTPS的安全基础是SSL,所以加密的详细内容就须要SSL。浏览器
HTTPS协议的主要做用能够分为两种:一种是创建一个信息安全通道,来保证数据传输的安全;另外一种就是确认网站的真实性。缓存
HTTP协议传输的数据都是未加密的,也就是明文的,所以使用HTTP协议传输隐私信息很是不安全,为了保证这些隐私数据能加密传输,因而网景公司设计了SSL(Secure Sockets Layer)协议用于对HTTP协议传输的数据进行加密,从而就诞生了HTTPS。简单来讲,HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议,要比http协议安全。安全
HTTPS和HTTP的区别主要以下:性能优化
一、https协议须要到ca申请证书,通常免费证书较少,于是须要必定费用。服务器
二、http是超文本传输协议,信息是明文传输,https则是具备安全性的ssl加密传输协议。网络
三、http和https使用的是彻底不一样的链接方式,用的端口也不同,前者是80,后者是443。架构
四、http的链接很简单,是无状态的;HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议,比http协议安全。
咱们都知道HTTPS可以加密信息,以避免敏感信息被第三方获取,因此不少银行网站或电子邮箱等等安全级别较高的服务都会采用HTTPS协议。
客户端在使用HTTPS方式与Web服务器通讯时有如下几个步骤,如图所示。
(1)客户使用https的URL访问Web服务器,要求与Web服务器创建SSL链接。
(2)Web服务器收到客户端请求后,会将网站的证书信息(证书中包含公钥)传送一份给客户端。
(3)客户端的浏览器与Web服务器开始协商SSL链接的安全等级,也就是信息加密的等级。
(4)客户端的浏览器根据双方赞成的安全等级,创建会话密钥,而后利用网站的公钥将会话密钥加密,并传送给网站。
(5)Web服务器利用本身的私钥解密出会话密钥。
(6)Web服务器利用会话密钥加密与客户端之间的通讯。
咱们先不了聊HTTP,HTTPS,咱们先从一个聊天软件提及,咱们要实现A能发一个hello消息给B:
若是咱们要实现这个聊天软件,本文只考虑安全性问题,要实现
A发给B的hello消息包,即便被中间人拦截到了,也没法得知消息的内容
这个问题,不少人立刻就想到了各类加密算法,什么对称加密、非对称加密、DES、RSA、XX、噼里啪啦~
而我想说,加密算法只是解决方案,咱们首先要作的是理解咱们的问题域——什么是安全?
我我的的理解是:
A与B通讯的内容,有且只有A和B有能力看到通讯的真正内容
好,问题域已经定义好了(现实中固然不止这一种定义)。对于解决方案,很容易就想到了对消息进行加密。
题外话,可是只有这一种方法吗?我看未必,说不定在未来会出现一种物质打破当前世界的通讯假设,实现真正意义上的保密。
对于A与B这样的简单通讯模型,咱们很容易作出选择:
这就是对称加密算法,其中图中的密钥S同时扮演加密和解密的角色。具体细节不是本文范畴。
只要这个密钥S不公开给第三者,同时密钥S足够安全,咱们就解决了咱们一开始所定问题域了。由于世界上有且只有A与B知道如何加密和解密他们之间的消息。
可是,在WWW环境下,咱们的Web服务器的通讯模型没有这么简单:
若是服务器端对全部的客户端通讯都使用一样的对称加密算法,无异于没有加密。那怎么办呢?即能使用对称加密算法,又不公开密钥?请读者思考21秒钟。😜
答案是:Web服务器与每一个客户端使用不一样的对称加密算法:
慢着,另外一个问题来了,咱们的服务器端怎么告诉客户端该使用哪一种对称加密算法?
固然是经过协商。
可是,你协商的过程是没有加密的,仍是会被中间人拦截。那咱们再对这个协商过程进行对称加密就行了,那你对协商过程加密的加密仍是没有加密,怎么办?再加密不就行了……好吧,进行鸡生蛋蛋生鸡的问题了。
新问题来了,如何对协商过程进行加密?密码学领域中,有一种称为“非对称加密”的加密算法,特色是私钥加密后的密文,只要是公钥,均可以解密,可是公钥加密后的密文,只有私钥能够解密。私钥只有一我的有,而公钥能够发给全部的人。
虽然服务器端向A、B……的方向仍是不安全的,可是至少A、B向服务器端方向是安全的。
好了,如何协商加密算法的问题,咱们解决了:使用非对称加密算法进行对称加密算法协商过程。
这下,你明白为何HTTPS同时须要对称加密算法和非对称加密算法了吧?
要达到Web服务器针对每一个客户端使用不一样的对称加密算法,同时,咱们也不能让第三者知道这个对称加密算法是什么,怎么办?
使用随机数,就是使用随机数来生成对称加密算法。这样就能够作到服务器和客户端每次交互都是新的加密算法、只有在交互的那一该才肯定加密算法。
这下,你明白为何HTTPS协议握手阶段会有这么多的随机数了吧。
细心的人可能已经注意到了若是使用非对称加密算法,咱们的客户端A,B须要一开始就持有公钥,要不无法开展加密行为啊。
这下,咱们又遇到新问题了,如何让A、B客户端安全地获得公钥?
我能想到的方案只有这些:
方案1. 服务器端将公钥发送给每个客户端
方案2. 服务器端将公钥放到一个远程服务器,客户端能够请求获得
咱们选择方案1,由于方案2又多了一次请求,还要另外处理公钥的放置问题。
可是方案1有个问题:若是服务器端发送公钥给客户端时,被中间人调包了,怎么办?
我画了张图方便理解:
显然,让每一个客户端的每一个浏览器默认保存全部网站的公钥是不现实的。
公钥被调包的问题出现,是由于咱们的客户端没法分辨返回公钥的人究竟是中间人,仍是真的服务器。这其实就是密码学中提的身份验证问题。
若是让你来解决,你怎么解决?若是你了解过HTTPS,会知道使用数字证书来解决。可是你想过证书的本质是什么么?请放下你对HTTPS已有的知识,本身尝试找到解决方案。
我是这样解决的。既然服务器须要将公钥传给客户端,这个过程自己是不安全,那么咱们为何不对这个过程自己再加密一次?但是,你是使用对称加密,仍是非对称加密?这下好了,我感受又进了鸡生蛋蛋生鸡问题了。
问题的难点是若是咱们选择直接将公钥传递给客户端的方案,咱们始终没法解决公钥传递被中间人调包的问题。
因此,咱们不能直接将服务器的公钥传递给客户端,而是第三方机构使用它的私钥对咱们的公钥进行加密后,再传给客户端。客户端再使用第三方机构的公钥进行解密。
下图就是咱们设计的初版“数字证书”,证书中只有服务器交给第三方机构的公钥,并且这个公钥被第三方机构的私钥加密了:
若是能解密,就说明这个公钥没有被中间人调包。由于若是中间人使用本身的私钥加密后的东西传给客户端,客户端是没法使用第三方的公钥进行解密的。
话到此,我觉得解决问题了。可是现实中HTTPS,还有一个数字签名的概念,我无法理解它的设计理由。
原来,我漏掉了一个场景:第三方机构不可能只给你一家公司制做证书,它也可能会给中间人这样有坏心思的公司发放证书。这样的,中间人就有机会对你的证书进行调包,客户端在这种状况下是没法分辨出是接收的是你的证书,仍是中间人的。由于不论中间人,仍是你的证书,都能使用第三方机构的公钥进行解密。像下面这样:
第三方机构向多家公司颁发证书的状况:
客户端能解密同一家第三机构颁发的全部证书:
最终致使其它持有同一家第三方机构证书的中间人能够进行调包:
要解决这个问题,咱们首先要想清楚一个问题,辨别同一机构下不一样证书的这个职责,咱们应该放在哪?
只能放到客户端了。意思是,客户端在拿到证书后,本身就有能力分辨证书是否被篡改了。如何才能有这个能力呢?
咱们从现实中找灵感。好比你是HR,你手上拿到候选人的学历证书,证书上写了持证人,颁发机构,颁发时间等等,同时证书上,还写有一个最重要的:证书编号!咱们怎么鉴别这张证书是的真伪呢?只要拿着这个证书编号上相关机构去查,若是证书上的持证人与现实的这个候选人一致,同时证书编号也能对应上,那么就说明这个证书是真实的。
咱们的客户端能不能采用这个机制呢?像这样:
但是,这个“第三方机构”究竟是在哪呢?是一个远端服务?不可能吧?若是是个远端服务,整个交互都会慢了。因此,这个第三方机构的验证功能只能放在客户端的本地了。
客户端本地怎么验证证书呢?答案是证书自己就已经告诉客户端怎么验证证书的真伪。
也就是证书上写着如何根据证书的内容生成证书编号。客户端拿到证书后根据证书上的方法本身生成一个证书编号,若是生成的证书编号与证书上的证书编号相同,那么说明这个证书是真实的。
同时,为避免证书编号自己又被调包,因此使用第三方的私钥进行加密。
这地方有些抽象,咱们来个图帮助理解:
证书的制做如图所示。证书中的“编号生成方法MD5”就是告诉客户端:你使用MD5对证书的内容求值就能够获得一个证书编号。
当客户端拿到证书后,开始对证书中的内容进行验证,若是客户端计算出来的证书编号与证书中的证书编号相同,则验证经过:
可是第三方机构的公钥怎么跑到了客户端的机器中呢?世界上这么多机器。
其实呢,现实中,浏览器和操做系统都会维护一个权威的第三方机构列表(包括它们的公钥)。由于客户端接收到的证书中会写有颁发机构,客户端就根据这个颁发机构的值在本地找相应的公钥。
题外话:若是浏览器和操做系统这道防线被破了,就没办法。想一想当年本身装过的很是规XP系统,都惧怕。
说到这里,想必你们已经知道上文所说的,证书就是HTTPS中数字证书,证书编号就是数字签名,而第三方机构就是指数字证书签发机构(CA)。
当我听到这个问题时,我误觉得,咱们的SERVER须要发网络请求到CA部门的服务器来拿这个证书。😭 究竟是我理解能力问题,仍是。。
其实,问题应该是CA如何颁发给咱们的网站管理员,而咱们的管理员又如何将这个数字证书放到咱们的服务器上。
咱们如何向CA申请呢?每一个CA机构都大同小异,我在网上找了一个:
拿到证书后,咱们就能够将证书配置到本身的服务器上了。那么如何配置?这是具体细节了,留给你们google了。
咱们经过推算的方式尝试还原HTTPS的设计过程。这样,咱们也就明白了为何HTTPS比HTTP多那么屡次的交互,为何HTTPS的性能会差,以及找到HTTPS的性能优化点。
而上面一大堆工做都是为了让客户端与服务器端安全地协商出一个对称加密算法。这就是HTTPS中的SSL/TLS协议主要干的活。剩下的就是通讯时双方使用这个对称加密算法进行加密解密。
如下是一张HTTPS协议的真实交互图(从网上copy的,忘了从哪了,若是侵权麻烦告知):
答案是不能,由于HTTPS自己实在太复杂。可是我仍是尝试使用一段话来总结HTTPS:
HTTPS要使客户端与服务器端的通讯过程获得安全保证,必须使用的对称加密算法,可是协商对称加密算法的过程,须要使用非对称加密算法来保证安全,然而直接使用非对称加密的过程自己也不安全,会有中间人篡改公钥的可能性,因此客户端与服务器不直接使用公钥,而是使用数字证书签发机构颁发的证书来保证非对称加密过程自己的安全。这样经过这些机制协商出一个对称加密算法,就此双方使用该算法进行加密解密。从而解决了客户端与服务器端之间的通讯安全问题。
尽管HTTPS并不是绝对安全,掌握根证书的机构、掌握加密算法的组织一样能够进行中间人形式的攻击,但HTTPS还是现行架构下最安全的解决方案,主要有如下几个好处:
(1)使用HTTPS协议可认证用户和服务器,确保数据发送到正确的客户机和服务器;
(2)HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议,要比http协议安全,可防止数据在传输过程当中不被窃取、改变,确保数据的完整性。
(3)HTTPS是现行架构下最安全的解决方案,虽然不是绝对安全,但它大幅增长了中间人攻击的成本。
(4)谷歌曾在2014年8月份调整搜索引擎算法,并称“比起同等HTTP网站,采用HTTPS加密的网站在搜索结果中的排名将会更高”。
虽说HTTPS有很大的优点,但其相对来讲,仍是存在不足之处的:
(1)HTTPS协议握手阶段比较费时,会使页面的加载时间延长近50%,增长10%到20%的耗电;
(2)HTTPS链接缓存不如HTTP高效,会增长数据开销和功耗,甚至已有的安全措施也会所以而受到影响;
(3)SSL证书须要钱,功能越强大的证书费用越高,我的网站、小网站没有必要通常不会用。
(4)SSL证书一般须要绑定IP,不能在同一IP上绑定多个域名,IPv4资源不可能支撑这个消耗。
(5)HTTPS协议的加密范围也比较有限,在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么做用。最关键的,SSL证书的信用链体系并不安全,特别是在某些国家能够控制CA根证书的状况下,中间人攻击同样可行。
若是须要将网站从http切换到https到底该如何实现呢?
这里须要将页面中全部的连接,例如js,css,图片等等连接都由http改成https。例如:http://www.baidu.com改成https://www.baidu.com
BTW,这里虽然将http切换为了https,仍是建议保留http。因此咱们在切换的时候能够作http和https的兼容,具体实现方式是,去掉页面连接中的http头部,这样能够自动匹配http头和https头。例如:将http://www.baidu.com改成//www.baidu.com。而后当用户从http的入口进入访问页面时,页面就是http,若是用户是从https的入口进入访问页面,页面即便https的。
参考:https://www.cnblogs.com/wqhwe/p/5407468.html
https://www.cnblogs.com/zhangshitong/p/6478721.html