HTTP和HTTPS的区别 | 刘口子的博客

status

HTTP的缺点

通信使用明文可能会被窃听

HTTP本身不具备加密的功能，即HTTP报文使用明文（即未加密的报文）方式发送。而按照TCP/IP协议族的工作机制，通信内容在所有通信线路上都是可能被窃听的。

无论哪个客户端和服务器在通信时，线路上必定有某些网络设备（例如光缆、计算机等）不是个人私有物，所以不排除在公共环境下遭到窥视的可能。

即使已经加密过的通信，也会被窥视到通信内容，这是通信加密中两个不同的概念。通信过程加密，指的是内容不可被窃听；通信内容加密，指的是内容可能被窃听，但是窃听者无法破解报文信息的含义，但信息本身还是会被看到的。

窃听相同段上的通信并非难事，只需要收集流动的数据包（帧）就行了，收集和解析的过程称之为抓包。使用例如Wireshark这样的抓包工具，像使用GET方法发送请求、响应返回200 OK、HTTP响应报文的全部内容等等，一系列信息都可以看到。

不验证身份可能遭遇伪装

HTTP协议中，请求和响应都不会对通信方的身份进行验证。也就是说一次请求，不能保证它来自真正的客户端，也不能保证它被发送至真正的服务器，响应同理。

任何人都可以发送请求，服务器只要收到请求，不管对方是谁都会返回一个响应。（此处不考虑发送端的IP和端口号被服务器限制访问的情况）

HTTP这种任意发送和响应的机制，存在很多隐患：

无法确定收到请求的服务器，是否是按真实意图返回响应的服务器，有可能是被伪装的服务器。

无法确定收到响应的客户端，是否是按真实意图接受响应的客户端，有可能是被伪装的客户端。

无法确定通信对方是否具备访问条件。

无法确定请求和响应来自何处。

无意义的请求也会被接受，所以无法阻止海量请求下的DoS攻击。

无法验证报文完整性

在请求和响应发送出去，到对方接受这段时间内，无法知道通信内容是否遭到篡改。例如客户端下载的文件，可能和存放在服务器上的文件不一致了，但客户端也察觉不到。

像这样，请求或相应在传输途中，遭到攻击者拦截并篡改内容的攻击，称为中间人攻击（Man-in-the-Middle attack）。中间人可以在途中篡改传输内容，虽然归属于“无法验证报文完整性”，但一定程度上还是因为没有验证通信对方身份。

HTTPS简介

为了解决上述这些问题，需要在HTTP上加入加密和认证等机制，有这些机制的HTTP称为HTTPS(HTTP Secure)。也就是说，HTTPS = HTTP + 加密 + 认证 + 完整性保护。

HTTPS并非是一种新协议，而是HTTP通信接口部分使用SSL（Secure Socket Layer）和TLS（Transport Layer Security）协议代替而已。一般，HTTP直接和TCP通信，当使用SSL时，则先和SSL通信，再由SSL和TCP通信。

采用SSL之后，HTTPS就拥有了加密、证书、完整性保护等功能。SSL是独立于HTTP的协议，所以其他应用层的协议也可以配合SSL使用。

使用HTTPS进行通信时，不再用http://，而是改用https://，大部分浏览器地址栏内会出现一个带锁的标记。

HTTPS的解决方案

针对HTTP的缺点，HTTPS都提供了相应的解决方案。

通信加密、防止篡改

HTTP用于确定报文完整性的方法，事实上并不便捷、可靠，其中最常用的是MD5、SHA-1等散列值校验，以及PGP（Pretty Good Privacy，优良保密协议）创建的数字签名，但PGP或MD5本身被改写的话，用户也是无法知道的。而SSL提供了认证、加密及摘要功能。HTTPS使用SSL建立安全的通信线路之后，就可以在这条线路上进行HTTP通信了。

当然，还可以采取内容加密的方式，前提是客户端和服务器同时具备加密和解密的密钥。但这种单纯内容加密的方式不同于SSL和TLS将整个通信线路加密，所以内容有可能被篡改。

这里的“通信加密”其实并不准确，并不是使用 SSL 之后数据传输就不可窃听、不可篡改了，而是要验证对方身份之后才建立连接进行通信。也就是说，通过 SSL 验证身份之后，就确定了没有中间人，以确保内容不会被篡改；与此同时，将内容进行加密，窃听者即使获取了内容也无法解密。

所以，在 SSL 这种解决方案下，最重要的就是如何验证对方的身份，以及加密内容时采取的加密方法。

加密方法

首先我们来看看有哪些加密的方法，以及SSL采取了什么方式。近代的加密方法中，加密算法是公开的，而密钥是保密的。任何人只要持有密钥，就可以对内容解密。

对称加密（共享密钥）

加密和解密同用一个密钥的方式，称为共享密钥加密，即对称加密。对称的意思是，只要拥有密钥，既可以将内容加密，也可以把加密过的内容解密。

如果采用对称加密，就必须把密钥发给对方。就像考试时候对答案一样，对答案的人在进考场之前就要约定好各个选项对应的动作。可在互联网上转发密钥是非常危险的，如果密钥被监听，加密就失去了意义。这是目前对称加密面临的最大问题。

非对称加密（公开密钥加密）

非对称加密使用一对密钥，一把叫做公开密钥，任何人都可以获得，一把叫做私有密钥，只有自己保存。

采用非对称加密时，发送方使用接收方提供的公开密钥进行加密处理，接收方收到被加密的消息之后，再用自己的私钥进行解密。这种方式不需要传输用来解密的私钥，所以更加安全。

另外，根据密文和公钥想要恢复到信息原文是非常困难的，因为解密过程就是在对离散对数求值，或者说是在对大数进行因式分解，以目前的技术来看这是不现实的。

HTTPS采用混合加密

对称加密的瓶颈在于，无法安全地传输密钥。非对称加密虽然安全，但是速度和效率比较低下。考虑到各自的优势，HTTPS在交换密钥的时候使用非对称加密，建立通信之后交换报文则使用对称加密。

遗憾的是，非对称加密还是存在一些问题的，那就是无法证明公钥本身的正确性和真实性，即公钥在传输途中有可能被替换。饶了一大圈，问题的根本又回到了加密传输，即验证公钥的真实性。

现在来捋一捋HTTPS解决问题的思路：

如果内容加密，就不会被窃听，所以采用非对称加密，但存在无法验证公钥的问题。

如果验证了对方的身份，就不会遇到伪装的通信方，也不会遭到中间人攻击。

为了同时验证公钥的真实性、对方的身份，以及公钥和对方身份的关联性，SSL引入了证书。

查明证书

SSL使用了一种被称为公开密钥证书（数字证书）的手段。证书由可信任的第三方机构颁发，用于证明服务器和客户端的真实性。

首先，服务器的运营人员向数字证书认证机构提出公钥密钥的申请。数字证书认证机构在判明申请者的身份之后，对公开密钥进行数字签名，然后将这个已签名的公开密钥分配给申请者，并将公开密钥放入公钥证书并绑定在一起。

服务器会将这份公钥证书发送给客户端，客户端可以使用数字证书认证机构的公钥，对证书上的数字签名进行验证，如果验证通过，则证明了两件事：

服务器的公开密钥，确实是经过可信赖的第三方数字证书认证机构认证过的。

服务器的公开密钥是真实可靠的，没有经过篡改。

那么问题来了，客户端又怎么确定接受到的证书是安全可靠的、没有被篡改过的？很简单，多数浏览器开发商发布版本时，会事先在内部植入常用认证机构的公开密钥。

当然并不是只有服务器才能拥有证书，在一些需要验证客户端身份的场景，客户端也需要证书。例如在浏览器进行网银操作时，客户端会被要求安装证书。

HTTPS的通信过程

客户端通过发送 Client Hello 报文开始SSL通信。报文中包含客户端支持的SSL版本、加密组件列表（使用的加密算法和密钥长度等等）。

服务器可以进行SSL通信时，会以 Server Hello 报文作为应答。报文内容同样包含SSL版本和加密组件列表，服务器的加密组件内容是从客户端的加密组件列表中筛选出来的。

服务器发送 Certificate 报文。其中包含公开密钥证书。

服务器发送 Server Hello Done 报文，通知客户端最初阶段的SSL握手协商部分结束。

SSL第一次握手结束之后，客户端以 Client Key Exchange 报文回应。报文包含了一种被称为Pre-master secret的随机密码串，并且该报文已经被步骤3中的公开密钥加密过。

客户端继续发送 Change Cipher Spec 报文。该报文会提示服务器：在此报文之后的通信都采用Pre-master secret进行加密。

客户端发送 Finished 报文。该报文包含连接至今全部报文的整体校验值，这次握手能否成功，要以服务器是否能够解密此报文作为判断标准。

服务器同样发送 Change Cipher Spec 报文。

服务器同样发送 Finished 报文。

客户端和服务器的 Finished 报文交换完毕之后，SSL连接就建立完成了。从此之后的通信都会受到SSL保护，也就是可以开始应用层协议的通信，即发送HTTP请求。

应用层协议通信，此处以服务器发送HTTP响应为例。

最后客户端断开连接，发送 close_notify 报文。上图做了一些省略，这步之后会再发送TCP FIN报文来关闭TCP通信。

下图对该过程进行了总结：

总结

区别	HTTP	HTTPS
URL开头	http://	https://
安全性	不安全、无加密、无证书	安全、加密、有证书
标准端口	80	443
OSI模型层次	应用层	传输层
速度	快	慢（网络负载、加密解密消耗CPU和内存）

参考：《图解HTTP》