HTTPS

Posted 2020-08-11 foodoir

HTTPS

细心的朋友们可能注意到，越来越多的绿色https链接出现在各种网站上，博客园https、开源中国https、百度https、淘宝https等。越来越多的浏览器地址栏里多了个带绿色小锁的图标，域名的前缀也由原来的http自动跳转为https 开头，那么这些网站为什么要从http变成https呢?

HTTP是干什么的，它还有哪些不足？
　　HTTP 是一个网络传输协议，是专门用来帮你传输 Web 内容 的。大部分网站都是通过 HTTP协议来传输 Web 页面、以及 Web 页面上包含的各种东西（图片、CSS 样式、JS 脚本）。
　　下面说下HTTP的不足：
    　　1、通信使用明文（不加密），导致内容可能被窃听（原因：TCP/IP是可能被窃听的网络）
    　　2、部炎症通信方的身份，因此有可能遭遇伪装
    　　3、无法证明报文的完整性，所以有可能报文已遭到修改
     更多关于HTTP的知识请戳：http://www.cnblogs.com/foodoir/p/5905946.html
　　因为HTTP中没有加密机制，后面出现了SSL和TLS的组合使用来加密HTTP这种组合方式，使用的HTTP被成为HTTPS。

那么什么是SSL和TLS组合呢？

　　SSL/TLS全称“Secure Sockets Layer”的缩写，中文叫做“安全套接层”。由网景公司在上世纪90年代中期设计的。
　　发明这个的原因是：因为原先互联网上使用的 HTTP 协议是明文的，存在很多缺点——比如传输内容会被偷窥（嗅探）和篡改。发明 SSL 协议，就是为了解决这些问题。到了1999年，SSL 因为应用广泛，已经成为互联网上的事实标准。IETF 就在那年把 SSL 标准化。标准化之后的名称改为 TLS（是“Transport Layer Security”的缩写），中文叫做“传输层安全协议”。可以把这两者并列称呼（SSL/TLS），因为这两者其实是同一个东西的不同阶段（简单一句话：就是对信息加密传输防止被窃取或篡改  。以前叫SSL  后来被标准化后改名为TLS）。

Http加密方式

1、通信加密
　　HTTP协议中没有加密机制，但是可以通过和SSL（Secure Socket Layer，安全套阶层）或 TLS（Transport Layer Security，安全传输层协议）的组合使用，加密HTTP的通信内容，与SSL组合使用的HTTP被称为HTTPS，也就是 HTTP Security 或 HTTP over SSL.这个加密只是加密通信的通道。（注意，这里说道SSL，那么要和SSH区分开来，SSH只是加密的shell，最初是用来替代telnet的。通过Telnet 这又联系到 FTP ， SFTP ，FTP 就是文件传输协议，但是为了文件的安全和高效所以使用SSH，那就使用 SFTP；他们的端口分别是：Telnet 23 ， FTP 21 ， SFTP 22）
HTTPS并非应用层的一种新协议。只是HTTP通信接口部分用SSL和TLS协议替代。通常，HTTP直接和TCP通信，当使用SSL时，则演变成先和SSL通信，再由SSL和TCP通信，简言之，HTTPS其实就是身披SSL协议这层外壳的HTTP。
　　HTTPS采用对称和非对称混合加密机制，首先使用采用非对称加密，等到验证通过之后就采用对称加密，原因就是对称加密的效率要高。一开始使用非对称加密是因为服务器无法保证密钥安全送达客户端，所以采用加密密钥公开的方式，但是解密密钥私有。等到这种通信建立好之后，服务端就可以安全的把对称加密的密钥发送给客户端了，这样就可以采用对称加密了。但是这里又有个问题，那就是服务端又如何保证他发送的加密密钥安全抵达客户端呢？所以就有了数字证书（CA，Certificate Authority），权威可信机构颁发，一般浏览器内嵌这些机构的常用公开密钥，服务端会把证书发送给浏览器，然后浏览器对证书的数字签名解密，一旦解密成功，就说明网站是可信的，这样就可以保证二者都是连接可信的。

　　补充：
　　　　对称加密 和 非对称加密是干什么的？
　　　　　　加密：就是把“明文”变成“密文”
　　　　　　解密：就是把“密文”变为“明文”
　　　　在这两个过程中，都需要一个关键的东西——叫做“密钥”
　　　　对称加密：“加密”和“解密”使用【相同的】密钥。
　　　　非对称加密技术：“加密”和“解密”使用【不同的】密钥。

2、内容加密
　　将内容进行加密传输，一般只是加密报文主体，报文手部是不加密，这样依然会带来被窃取、篡改的问题。当然，这个也是我们程序中经常需要使用的。

下面请看如下所示的图：

如图，我们来分析HTTPS加密的过程：
1. 客户端发起HTTPS请求
　　用户在浏览器里输入一个https网址，然后连接到server的443端口。

2. 服务端的配置
　　采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择，有1年的免费服务)。这套证书其实就是一对公钥和私钥。如果对公钥和私钥不太理解，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。

3. 传送证书
　　这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。

4. 客户端解析证书
　　这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随即值。然后用证书对该随机值进行加密。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。

5. 传送加密信息
　　这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。

6. 服务段解密信息
　　服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密。所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。

7. 传输加密后的信息
　　这部分信息是服务段用私钥加密后的信息，可以在客户端被还原

8. 客户端解密信息
　　客户端用之前生成的私钥解密服务段传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。

使用HTTPS的优势
【兼容性：】
　　1. HTTPS 还是要基于 TCP 来传输（如果改为 UDP 作传输层，无论是 Web 服务端还是浏览器客户端，都要大改，动静太大了）

　　2. 单独使用一个新的协议，把 HTTP 协议包裹起来（所谓的“HTTP over SSL”，实际上是在原有的 HTTP 数据外面加了一层 SSL 的封装。HTTP 协议原有的 GET、POST 之类的机制，基本上原封不动）打个比方：如果原来的 HTTP 是塑料水管，容易被戳破；那么如今新设计的 HTTPS 就像是在原有的塑料水管之外，再包一层金属水管。一来，原有的塑料水管照样运行；二来，用金属加固了之后，不容易被戳破。

【可扩展性：】
　　HTTPS 相当于是“HTTP over SSL”。SSL/TLS除了能跟 HTTP 搭配，还能够跟其它的应用层协议搭配。  可以跟很多常用的应用层协议（比如：FTP、SMTP、POP、Telnet）搭配，来强化这些应用层协议的安全性。接着刚才打的比方：如果把 SSL/TLS 视作一根用来加固的金属管，它不仅可以用来加固输水的管道，还可以用来加固输煤气的管道。

【保密性：】
　　HTTPS 需要做到足够好的保密性。能够对抗嗅探（行话叫 Sniffer）。所谓的“嗅探”，通俗而言就是监视你的网络传输流量。如果你使用明文的 HTTP 上网，就知道你在访问哪些网站的哪些页面。
　　HTTPS 还要能对抗其它一些稍微高级的攻击手法——比如“重放攻击”

【完整性(防篡改)：】
　　在发明 HTTPS 之前，由于 HTTP 是明文的，不但容易被嗅探，还容易被篡改。

【真实性(防假冒)：】
　　举个例子：
　　你因为使用网银，需要访问该网银的 Web 站点。那么，你如何确保你访问的网站确实是你想访问的网站？（这话有点绕口令）
　　有些天真的同学会说：通过看网址里面的域名，来确保。为啥说这样的同学是“天真的”？因为 DNS 系统本身是不可靠的（尤其是在设计 SSL 的那个年代，连 DNSSEC 都还没发明）。由于 DNS 的不可靠（存在“域名欺骗”和“域名劫持”），你看到的网址里面的域名【未必】是真实的！所以，HTTPS 协议必须有某种机制来确保“真实性”的需求。

比较HTTP和HTTPS的区别：

1、HTTPS比HTTP要慢到2到100倍，原因就是 加密解密耗时，另外SSL通信部分也会消耗时间。

2、HTTP网络传输不安全。

3、HTTPS本身并非协议，而是标准的HTTP协议架在SSL/TLS协议之上的一种结构。（所谓的HTTPS其实就是身披SSL协议这层外壳的HTTP）。

相关博文：
　　HTTP协议：http://www.cnblogs.com/foodoir/p/5905946.html

　　javascript中的Cookie：http://www.cnblogs.com/foodoir/p/5914631.html

　　HTTP首部：http://www.cnblogs.com/foodoir/p/5922480.html