|
| 1 | +Http与Https的区别 |
| 2 | +=== |
| 3 | + |
| 4 | +`http`(超文本传输协议) |
| 5 | +--- |
| 6 | + |
| 7 | +缺点: |
| 8 | + |
| 9 | +- 通信使用明文(不加密),内容可能会被窃听 |
| 10 | +- 不验证通信方的身份,因此有可能遭遇伪装 |
| 11 | +- 无法证明报文的完整性,所以有可能已遭篡改 |
| 12 | + |
| 13 | +优点: |
| 14 | + |
| 15 | +- 传输速度快 |
| 16 | + |
| 17 | + |
| 18 | +`https` |
| 19 | +--- |
| 20 | + |
| 21 | +`Https`并非是应用层的一种新协议。只是`http`通信接口部分用`SSL`(安全套接字层)和`TLS`(安全传输层协议)代替而已。即添加了加密及认证机制的`HTTP`称为`HTTPS(HTTP Secure)`. |
| 22 | + |
| 23 | +``` |
| 24 | +HTTP + 加密 + 认证 + 完整性保护 = HTTPS |
| 25 | +``` |
| 26 | + |
| 27 | + |
| 28 | +如何保证安全 |
| 29 | +--- |
| 30 | + |
| 31 | +一般来说网络安全关心三个问题:`CIA(confidentiality, integrity, availability)`. |
| 32 | +那`https`在这三方面做的怎么样呢? |
| 33 | +- `https`保证了`confidentiality`(你浏览的页面的内容如果被人中途看见,将会是一团乱码。不会发生比如和你用同一个无线网的人收到一个你发的数据包,打开来一看,就是你的密码啊银行卡信息啊) |
| 34 | +- `intergrity`(你浏览的页面就是你想浏览的,不会被黑客在中途修改,网站收到的数据包也是你最初发的那个,不会把你的数据给换掉,搞一个大新闻) |
| 35 | +- 最后一个`availability`几乎没有提供(虽然我个人认为会增加基础`DOS`等的难度,但是这个不值一提),不过`https`还提供了另一个`A`,`authentication`(你连接的是你连接的网站,而不是什么人在中途伪造了一个网站给你,专业上叫`Man In The Middle Attack`)。 |
| 36 | +那`https`具体保护了啥?简单来说,保护了你从连接到这个网站开始,到你关闭这个页面为止,你和这个网站之间收发的所有信息,就连`url`的一部分都被保护了。同时`DNS querying`这一步也被保护了, |
| 37 | +不会发生你输入`www.google.com`实际上跑到了另一个网站去了。 |
| 38 | + |
| 39 | + |
| 40 | + |
| 41 | +#### 使用两把密钥的公开密钥加密 |
| 42 | + |
| 43 | +公开密钥加密使用一对非对称的密钥。一把叫做私钥,另一把叫做公钥。私钥不能让其他任何人知道,而公钥则可以随意发布,任何人都可以获得。使用公钥加密方式,发送密文的一方使用对方的公钥进行加密处理,对方收到被加密的信息后,再使用自己的私钥进行解密。利用这种方式,不需要发送用来解密的私钥,也不必担心密钥被攻击者窃听而盗走。 |
| 44 | + |
| 45 | + |
| 46 | +过程 |
| 47 | +--- |
| 48 | + |
| 49 | +- 服务器把自己的公钥登录至数字证书认证机构。 |
| 50 | +- 数字证书机构把自己的私有密钥向服务器的公开密码部署数字签名并颁发公钥证书。 |
| 51 | +- 客户端拿到服务器的公钥证书后,使用数字证书认证机构的公开密钥,向数字证书认证机构验证公钥证书上的数字签名。以确认服务器公钥的真实性。 |
| 52 | +- 使用服务器的公开密钥对报文加密后发送。 |
| 53 | +- 服务器用私有密钥对报文解密。 |
| 54 | + |
| 55 | + |
| 56 | +`HTTPS`通信的步骤 |
| 57 | +--- |
| 58 | + |
| 59 | +- 客户端发送报文进行`SSL`通信。报文中包含客户端支持的`SSL`的指定版本、加密组件列表(加密算法及密钥长度等)。 |
| 60 | +- 服务器应答,并在应答报文中包含`SSL`版本以及加密组件。服务器的加密组件内容是从接受到的客户端加密组件内筛选出来的。 |
| 61 | +- 服务器发送报文,报文中包含公开密钥证书。 |
| 62 | +- 服务器发送报文通知客户端,最初阶段`SSL`握手协商部分结束。 |
| 63 | +- `SSL`第一次握手结束之后,客户端发送一个报文作为回应。报文中包含通信加密中使用的一种被称`Pre-master secret`的随机密码串。该密码串已经使用服务器的公钥加密。 |
| 64 | +- 客户端发送报文,并提示服务器,此后的报文通信会采用`Pre-master secret`密钥加密。 |
| 65 | +- 客户端发送`Finished`报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够完成成功,要以服务器是否能够正确解密该报文作为判定标准。 |
| 66 | +- 服务器同样发送`Change Cipher Spec`报文。 |
| 67 | +- 服务器同样发送`Finished`报文。 |
| 68 | +- 服务器和客户端的`Finished`报文交换完毕之后,`SSL`连接就算建立完成。 |
| 69 | +- 应用层协议通信,即发送`HTTP`响应。 |
| 70 | +- 最后由客户端断开链接。断开链接时,发送`close_nofify`报文。 |
| 71 | + |
| 72 | + |
| 73 | +`HTTPS`的工作原理 |
| 74 | +--- |
| 75 | + |
| 76 | +`HTTPS`在传输数据之前需要客户端(浏览器)与服务端(网站)之间进行一次握手,在握手过程中将确立双方加密传输数据的密码信息。`TLS/SSL`协议不仅仅是一套加密传输的协议,更是一件经过艺术家精心设计的艺术品,`TLS/SSL`中使用了非对称加密,对称加密以及`HASH`算法。握手过程的简单描述如下: |
| 77 | +- 浏览器将自己支持的一套加密规则发送给网站。 |
| 78 | +- 网站从中选出一组加密算法与`HASH`算法,并将自己的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址,加密公钥,以及证书的颁发机构等信息。 |
| 79 | +- 获得网站证书之后浏览器要做以下工作: |
| 80 | + |
| 81 | + - 验证证书的合法性(颁发证书的机构是否合法,证书中包含的网站地址是否与正在访问的地址一致等),如果证书受信任,则浏览器栏里面会显示一个小锁头,否则会给出证书不受信的提示。 |
| 82 | + - 如果证书受信任,或者是用户接受了不受信的证书,浏览器会生成一串随机数的密码,并用证书中提供的公钥加密。 |
| 83 | + - 使用约定好的HASH计算握手消息,并使用生成的随机数对消息进行加密,最后将之前生成的所有信息发送给网站。 |
| 84 | + |
| 85 | +- 网站接收浏览器发来的数据之后要做以下的操作: |
| 86 | + |
| 87 | + - 使用自己的私钥将信息解密取出密码,使用密码解密浏览器发来的握手消息,并验证HASH是否与浏览器发来的一致。 |
| 88 | + - 使用密码加密一段握手消息,发送给浏览器。 |
| 89 | + |
| 90 | +- 浏览器解密并计算握手消息的`HASH`,如果与服务端发来的`HASH`一致,此时握手过程结束,之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。 |
| 91 | + |
| 92 | +这里浏览器与网站互相发送加密的握手消息并验证,目的是为了保证双方都获得了一致的密码,并且可以正常的加密解密数据,为后续真正数据的传输做一次测试。另外,`HTTPS`一般使用的加密与`HASH`算法如下: |
| 93 | + |
| 94 | +- 非对称加密算法:`RSA`,`DSA/DSS` |
| 95 | +- 对称加密算法:`AES`,`RC4`,`3DES` |
| 96 | +- `HASH`算法:`MD5`,`SHA1`,`SHA256` |
| 97 | + |
| 98 | + |
| 99 | +其中非对称加密算法用于在握手过程中加密生成的密码,对称加密算法用于对真正传输的数据进行加密,而`HASH`算法用于验证数据的完整性。由于浏览器生成的密码是整个数据加密的关键,因此在传输的时候使用了非对称加密算法对其加密。非对称加密算法会生成公钥和私钥,公钥只能用于加密数据,因此可以随意传输,而网站的私钥用于对数据进行解密,所以网站都会非常小心的保管自己的私钥,防止泄漏。 |
| 100 | + |
| 101 | +`TLS`握手过程中如果有任何错误,都会使加密连接断开,从而阻止了隐私信息的传输。正是由于`HTTPS`非常的安全,攻击者无法从中找到下手的地方,于是更多的是采用了假证书的手法来欺骗客户端,从而获取明文的信息,但是这些手段都可以被识别出来, |
| 102 | + |
| 103 | + |
| 104 | +优点 |
| 105 | +--- |
| 106 | + |
| 107 | +尽管`HTTPS`并非绝对安全,掌握根证书的机构、掌握加密算法的组织同样可以进行中间人形式的攻击,但`HTTPS`仍是现行架构下最安全的解决方案,主要有以下几个好处: |
| 108 | + |
| 109 | +- 使用`HTTPS`协议可认证用户和服务器,确保数据发送到正确的客户机和服务器 |
| 110 | +- `HTTPS`协议是由`SSL+HTTP`协议构建的可进行加密传输、身份认证的网络协议,要比`http`协议安全,可防止数据在传输过程中不被窃取、改变,确保数据的完整性。 |
| 111 | +- `HTTPS`是现行架构下最安全的解决方案,虽然不是绝对安全,但它大幅增加了中间人攻击的成本。 |
| 112 | +- 谷歌曾在2014年8月份调整搜索引擎算法,并称比起同等`HTTP`网站,采用`HTTPS`加密的网站在搜索结果中的排名将会更高。 |
| 113 | + |
| 114 | +缺点 |
| 115 | +--- |
| 116 | + |
| 117 | +虽然说HTTPS有很大的优势,但其相对来说,还是存在不足之处的: |
| 118 | + |
| 119 | +- `HTTPS`协议握手阶段比较费时,会使页面的加载时间延长近`50%`,增加`10%`到`20%`的耗电; |
| 120 | +- `HTTPS`连接缓存不如`HTTP`高效,会增加数据开销和功耗,甚至已有的安全措施也会因此而受到影响; |
| 121 | +- `SSL`证书需要钱,功能越强大的证书费用越高,个人网站、小网站没有必要一般不会用。 |
| 122 | +- `SSL`证书通常需要绑定`IP`,不能在同一`IP`上绑定多个域名,`IPv4`资源不可能支撑这个消耗。 |
| 123 | +- `HTTPS`协议的加密范围也比较有限,在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的,`SSL`证书的信用链体系并不安全,特别是在某些国家可以控制`CA`根证书的情况下,中间人攻击一样可行。 |
| 124 | + |
| 125 | + |
| 126 | + |
| 127 | + |
| 128 | + |
| 129 | + |
| 130 | + |
| 131 | + |
| 132 | + |
| 133 | + |
| 134 | + |
| 135 | + |
| 136 | + |
| 137 | + |
| 138 | + |
| 139 | + |
| 140 | +---- |
| 141 | +- 邮箱 :charon.chui@gmail.com |
| 142 | +- Good Luck! |
| 143 | + |
| 144 | + |
0 commit comments