https经验介绍

https经验介绍

特此声明：这篇文章是本人查看多篇博客，自己整理出来的。对引用的其他作者的文章表示感谢！

一．https的概念

要说https，首先要说下http，http就是超文本传输协议，它主要用于web浏览器与网站服务器之间传递信息，http是以明文方式发送信息，不提供任何方式的数据加密，如果攻击者截取了web浏览器与网站服务器之间的传输报文，那么攻击者就可以直接读懂其中的内容。因此，http不适合传递一些敏感的信息，比如银行卡号，密码等等。

为了解决这一缺陷，所以网景公司就设计了SSL（Secure Sockets Layer）协议用于对http协议传输数据的加密。从而就诞生了https。

简单的说https=http+ssl，也就是安全的http。

目前SSL的版本是3.0，被IETF(Internet Engineering Task Force)定义在RFC 6101中，后来IETF升级了SSL3.0变为TLS1.0（Transport Layer Security）,定义在RFC 2246中。实际上我们现在的https使用的就是TLS协议。但是因为SSL出现的比较早，而且依旧被现在的浏览器所支持，所以SSL依然是https的代名词。

二．Https的原理

在这里先理解两个概念：

1.对称加密

    也就是通讯甲乙两方共用一个密钥，甲方用密钥加密，乙方用密钥解密，反之亦然。

特点：速度高，可加密内容较大，用来加密回话过程中的信息。

 

2.非对称加密（公钥加密）

    甲乙两方分别生成公钥和私钥，然后将自己的公钥传递给对方，自己留下私钥。这样，甲方传递信息时，就可以用乙方的公钥加密，乙方收到信息后，用私钥解密，就可以读取信息。反之亦然。

特点：加密速度较慢，但是能更好的提供身份认证技术，用来加   密对称加密的密钥。

 

https分为单向认证和双向认证

https在建立Socket连接之前需要进行握手。具体过程如下：

单向认证

 

 

具体过程：

1.浏览器访问一个https地址，同时向服务端发送它所支持的SSL协议版本、支持的加密算法等。

2.服务端给客户端返回它所要使用的SSL协议版本、加密算法等。同时还要返回服务端的证书，即公钥证书。

3.客户端收到服务端的会用之后，会首先验证服务端证书是否合法，如果证书不是自己所信任的机构颁发的，或者证书中的域名与实际的域名不一致，或者证书已经过期，或者返回的公钥不能正确打开返回证书中的数字签名，就会向访问者发出一个警告，警告这个证书是不安全的，由访问者选择是否继续访问，如果证书没有问题，则客户端就会从证书中取出服务端的公钥继续。

4.客户端向服务端发送自己所支持的对称加密方案，供服务端选择

5.服务端从客户端发送过来的加密方式中选择加密程度最高的加密方案。

6.服务端将选择好的加密方案以明文方式发送给客户端。

7.客户端收到服务端发送过来的加密方式后，使用该加密方式，生成一个随机数，然后将这个随机数用服务端证书中的公钥加密，发送给服务端。

8.服务端收到客户端发送过来的加密信息后，用自己的私钥解密，获得最终的对称加密密钥。至此，客户端和服务端都得到这个加密密钥，而这个加密密钥是别人不知道的。

9.在接下来的会话中，客户端和服务端的通讯就会用这个加密密钥进行加密解密，保证通讯安全。

 

 

双向认证

 

 

双向认证和单向认证差不多，只不过双向认证不仅客户端验证服务端的身份，而且服务端还要求客户端发送证书认证身份。具体过程如下：

1. 浏览器访问一个https地址，同时发送自己所支持的SSL版本号、加密算法等给服务端。

2. 服务端给客户端返回它所要使用的SSL版本号、加密算法等。同时还返回服务端的证书，即公钥证书

3. 客户端收到服务端证书后，验证证书是否合法，如果证书不是自己所信任的机构颁发的，或者证书里面的域名与实际域名不一致，或者证书已经过期，或者服务端返回的公钥不能正确解开返回证书的数字签名，就会向访问者发出一个警告，警告证书不安全，又访问者决定是否继续。如果证书没有问题，则客户端就会从服务端证书中取出服务端公钥继续。

4. 客户端验证通过后，会将自己的证书发送给服务端验证。

5. 服务端验证客户端证书，验证通过，则获得客户端的公钥。

6. 客户端发送自己所支持的对称加密方案给服务端，供其选择。

7. 服务端从客户端发送过来的对称加密方案中，选择加密程度最高的加密方案。

8. 将选择好的加密方案，有客户端公钥加密放松给客户端。

9. 客户端收到加密方式后，用自己的私钥解密，产生随机码，作为对称加密密钥，使用服务端公钥加密后，发送给服务端。

10.服务端用私钥解密，获得对称加密密钥。

11.在接下来的会话中，客户端和服务端的通讯就会用这个加密密钥进行加密解密，保证通讯安全。

 

三．故事讲解https

在开始之前，我们来虚构两个人物， 一个是位于中国的张大胖， 还有一个是位于米国的Bill 。

这俩哥们隔着千山万水，通过网络联系上了， 两个人臭味相投，聊得火热。

此时正值米国大选， 张大胖亲切地“致电”Bill, 对米国总统大选的情况表示强烈地关注。 Bill则回电说谢谢关心米国人的事情我们米国人自己做主，不用你们歪果仁瞎操心......

张大胖继续“致电”说其实我们支持特朗普， 因为希拉里太情绪化，太难打交道了， 我们挺希望看到特朗普上台这样米国就会变成 The Divided State of America ......

Bill 回电： 拉倒你吧你， 我们米国的政体有着强大的纠错性， 虽然有时候发展得慢， 有时候会走上岔路， 但很快就会回到正途，几百年来稳定得很，不像你们像坐了过山车一样.....

两个人越聊越投机，天南地北，海阔天空，还夹杂着不少隐私的话题。

 

2 总是有一种被偷看的感觉

 

有一天， Bill 突然意识到： 坏了， 我们的通信是明文的， 这简直就是网络上裸奔啊， 任何一个不怀好意的家伙都可以监听我们通信，打开我们发送的数据包，窥探我们的隐私啊。

张大胖说： “你不早点说，我刚才是不是把我的微信号给你发过去了？ 我是不是告诉你我上周去哪儿旅游了?   估计已经被人截取了吧！”

Bill  提议： “要不我们做个数据的加密？ 每次传输之前， 你把消息用一个加密算法加密， 然后发到我这里以后我再解密， 这样别人就无法偷窥了，像这样： ”

 

 

张大胖冰雪聪明，一看就明白了， 这加密和解密算法是公开的，那个密钥是保密的， 只有两人才知道， 这样生成的加密消息（密文） 别人就无法得知了。 他说： “Bill 老兄，你生成一个密钥， 然后把密钥发给我， 咱们这就开启加密消息， 让那些偷窥狂人们哭去吧！”

 

（这叫对称加密算法， 因为加密和解密用的是同一个密钥）

一炷香功夫过去了， Bill 还是没有回音， 张大胖忍不住地催促： “快发啊？！！！”

Bill 终于回复了： “ 我感觉有一双眼睛正在虎视眈眈地盯着我们的通话， 如果我把密钥发给你， 也被他截取了， 那加密岂不白费工夫？”

张大胖沉默了， 是啊， 网络是不安全的， 这密钥怎么安全地发过来啊 ？　

“奥，对了，我下周要去米国旅游，到时候我们见一面，把密码确定下来，写到纸上，谁也偷不走， 这不就结了？”　

“哈哈， 这倒是终极解决之道 ”  Bill 笑了， “不过，我不仅仅和你聊天， 我还要和易卜拉欣，阿卜杜拉， 弗拉基米尔，克里斯托夫，玛格丽特， 桥本龙太郎， 李贤俊， 许木木，郭芙蓉，吕秀才等人通信， 我总不能打着飞的，满世界的和人交换密码吧？ ”

张大胖心里暗自佩服Bill同学的好友竟然遍布全球，看来他对加密通信的要求更加强烈啊！

可是这个加密解密算法需要的密钥双方必须得知道啊， 但是密钥又无法通过网络发送， 这该死的偷窥者！

 

3  RSA : 非对称加密

 

Bill 和 张大胖的通信无法加密，说话谨慎了不少， 直到有一天， 他们听说了一个叫做RSA的非对称加密算法，一下子来了灵感。

这个RSA算法非常有意思，它不是像之前的算法， 双方必须协商一个保密的密钥， 而是有一对儿钥匙， 一个是保密的，称为私钥，另外一个是公开的，称为公钥。

更有意思的是，用私钥加密的数据，只有对应的公钥才能解密，用公钥加密的数据， 只有对应的私钥才能解密。

 

有了这两个漂亮的特性， 当张大胖给Bill发消息的时候， 就可以先用Bill的公钥去加密（反正Bill的公钥是公开的，地球人都知道）， 等到消息被Bill 收到后， 他就可以用自己的私钥去解密（只有Bill才能解开，私钥是保密的 ）

 

 

反过来也是如此， 当Bill 想给张大胖发消息的时候，就用张大胖的公钥加密， 张大胖收到后，就用自己的私钥解密。

这样以来，通信安全固若金汤， 没有任何人能窥探他们的小秘密了。

4 非对称加密+对称加密

两人实验了几次，  张大胖说： “Bill  , 你有没有感觉这个RSA的加密和解密有点慢啊？”

Bill叹了口气 ：“是啊， 我也注意到了， 刚才搜了一下，这个RSA算法比之前的对称密钥算法要慢上百倍。我们就是加个密而已，现在搞得都没法用了”

“回到咱们最初的问题，我们想用一个密钥来加密通信，那个对称加密算法是非常快的，但是苦于密钥无法安全传输， 现在有了RSA ,我想可以结合一下， 分两步走　(1) 我生成一个对称加密算法的密钥， 用RSA的方式安全发给你，  (2) 我们随后就不用RSA了， 只用这个密钥，利用对称加密算法来通信,  如何？   ”

Bill 说： “你小子可以啊， 这样以来既解决了密钥的传递问题， 又解决了RSA速度慢的问题，不错。”　

于是两人就安全地传递了对称加密的密钥， 用它来加密解密，果然快多了！

 

5 中间人攻击

 

张大胖把和Bill 聊天的情况给老婆汇报了一次。

老婆告诫他说： “你要小心啊， 你确定网络那边坐着的确实是Bill ?”

张大胖着急地辩解说：“肯定是他啊，我都有他的公钥，我们俩的通信都是加密的。”

老婆提醒道：＂假如啊，Bill给你发公钥的时候， 有个中间人，截取了Bill的公钥， 然后把自己的公钥发给了你，冒充Bill ，你发的消息就用中间人的公钥加了密，　那中间人不就可以解密看到消息了？＂

张大胖背后出汗了，是啊，这个中间人解密以后，还可以用Bill的公钥加密，发给Bill ,  Bill和我根本都意识不到， 还以为我们在安全传输呢！

 

 

看来问题出现在公钥的分发上！  虽然这个东西是公开的， 但是在别有用心的人看来，截取以后还可以干坏事 ！

6 你到底是谁？

 

但是怎么安全地分发公钥呢？ 似乎又回到了最初的问题： 怎么安全的保护密钥？

可是似乎和最初的问题还不一样，这一次的公钥不用保密，但是一定得有个办法声明这个公钥确实是Bill的， 而不是别人的。

怎么声明呢？

张大胖突然想到： 现实中有公证处，它提供的公证材料大家都信任，那在网络世界也可以建立一个这样的具备公信力的认证中心， 这个中心给大家颁发一个证书， 用于证明一个人的身份。

这个证书里除了包含一个人的基本信息之外，还有包括最关键的一环：这个人的公钥！

这样以来我拿到证书就可以安全地取到公钥了 ！ 完美！

可是Bill 马上泼了一盆冷水：证书怎么安全传输？ 要是证书传递的过程中被篡改了怎么办？

张大胖心里不由地咒骂起来： 我去， 这简直就是鸡生蛋，蛋生鸡的问题啊。

天无绝人之路， 张大胖很快就找到了突破口： 数字签名。

简单来讲是这样的， Bill可以把他的公钥和个人信息用一个Hash算法生成一个消息摘要， 这个Hash算法有个极好的特性，只要输入数据有一点点变化，那生成的消息摘要就会有巨变，这样就可以防止别人修改原始内容。

 

 

可是作为攻击者的中间人笑了： “虽然我没办法改公钥，但是我可以把整个原始信息都替换了， 生成一个新的消息摘要， 你不还是辨别不出来？”

张大胖说你别得意的太早 ， 我们会让有公信力的认证中心（简称CA）用它的私钥对消息摘要加密，形成签名：

这还不算， 还把原始信息和数据签名合并， 形成一个全新的东西，叫做“数字证书”

张大胖接着说：当Bill把他的证书发给我的时候， 我就用同样的Hash 算法， 再次生成消息摘要，然后用CA的公钥对数字签名解密， 得到CA创建的消息摘要， 两者一比，就知道有没有人篡改了！

如果没人篡改， 我就可以安全的拿到Bill的公钥喽，有了公钥， 后序的加密工作就可以开始了。

虽然很费劲， 但是为了防范你们这些偷窥者，实在是没办法啊。

 

中间人恶狠狠地说： “算你小子狠！ 等着吧，我还有别的招。 对了，我且问你， 你这个CA的公钥怎么拿到？　难道不怕我在你传输ＣＡ公钥的时候发起中间人攻击吗？　如果我成功的伪装成了ＣＡ，你这一套体系彻底玩完。”

张大胖语塞了，折腾了半天，又回到了公钥安全传输的问题！

不过转念一想，想解决鸡生蛋，蛋生鸡的问题必须得打破这个怪圈才行，我必须得信任ＣＡ，并且通过安全的的方式获取他们的公钥，这样才能把游戏玩下去。

（注：这些ＣＡ本身也有证书来证明自己的身份，并且ＣＡ的信用是像树一样分级的，高层的ＣＡ给底层的ＣＡ做信用背书，而操作系统／浏览器中会内置一些顶层的ＣＡ的证书，相当于你自动信任了他们。　这些顶层的ＣＡ证书一定得安全地放入操作系统／浏览器当中，否则世界大乱。）

7  https 

 

终于可以介绍https了，前面已经介绍了https的原理， 你把张大胖替换成浏览器， 把Bill 替换成某个网站就行了。

一个简化的（例如下图没有包含Pre-Master Secret）https流程图是这样的， 如果你理解了前面的原理，这张图就变得非常简单：

 

（完）

 

四．https的优缺点

HTTPS的优点：

安全性方面

在目前的技术背景下，HTTPS是现行架构下最安全的解决方案，主要有以下几个好处：

1、使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器;

2、HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。

3、HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。

HTTPS的缺点：

技术方面

1、相同网络环境下，HTTPS协议会使页面的加载时间延长近50%，增加10%到20%的耗电。此外，HTTPS协议还会影响缓存，增加数据开销和功耗。

2、HTTPS协议的安全是有范围的，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。

3、最关键的，SSL 证书的信用链体系并不安全。特别是在某些国家可以控制 CA 根证书的情况下，中间人攻击一样可行。

成本方面

1、SSL的专业证书需要购买，功能越强大的证书费用越高。个人网站、小网站可以选择入门级免费证书。

2、SSL 证书通常需要绑定 固定IP，为服务器增加固定IP会增加一定费用;

3、HTTPS 连接服务器端资源占用高较高多，相同负载下会增加带宽和服务器投入成本;

 

五．小注

RSA非对称加密的两个用途：

 

1.加密（防窃听）

RSA非对称加密会用到一堆密钥，分别称为公钥和私钥。公钥加密后可以通过私钥来解密；私钥加密后可以通过公钥来解密。在web数据传输过程中，由于客户端与服务器端是多对一的关系，因此可以让所有的客户端持有相同的公钥，而服务器端持有私钥。这样一来就能方便的实现数据的传输了。

 

2.签名（防篡改）

由于私钥只在某一个体当中，因此可以利用这点来进行身份识别。比如有用户A和B，A向B发送消息“ABC”，可进行如下操作：

A用私钥对“ABC”进行加密，得到“##@”，并附上原文得到“@#￥”，将这个密文发送给B，B得到之后，就用公钥解密，将解密后的文本与A发送过来的原文“ABC”进行比对，如果一切正常，那么B解密后的文本就是A加密后发送过来的文本。因为只有A才有对文本加密的私钥。当然，能得到这个结论的前提是，B所用的公钥和A所用的私钥确实是一对的。

加入在数据传送过程中C截取并篡改了密文，将“ABC”改为“AAA”，但是由于C没有A所持有的的私钥，所以它不能正确的数字签名，或者C用其他的私钥进行签名，但是B所持有的的公钥不能进行解密，这样一来，B就知道了A发过来的密文已经被别人篡改了。因为B持有的公钥所对应的私钥只在A手里。

 

3.非对称加密算法：RSA，DSA/DSS  

      在客户端与服务端相互验证的过程中用的是非对称加密 
  对称加密算法：AES，RC4，3DES    

      客户端与服务端相互验证通过后，以随机数作为密钥时，就是 

      对称加密
  HASH算法：MD5，SHA1，SHA256  

      在确认握手消息没有被篡改时