聊聊HTTP、HTTPS那些事儿
在HTTP协议中有可能存在信息窃听或身份伪装等安全问题，而使用HTTPS通信机制则可以有效的防止这些问题。这一篇文章我打算从安全的角度来聊一聊HTTP和HTTPS。
HTTP具有相当优秀和方便的一面，然而它也并非只有好的一面，事物皆具有两面性，它也有自己的不足之处。这些不足之处尤其体现在安全方面。下面我们就先来看看HTTP在安全方面的缺陷。
众所周知，HTTP报文使用明文(未经加密的报文)的方式来发送。而按照TCP/IP协议簇的工作方式，通信内容在所有的通信线路上都有可能遭到窥视。互联网是由能够连通到全世界的网络组成的。无论世界上哪个角落的服务器在和客户端通信时，再此通信线路上的某些网络设备、光缆、计算机等都不可能是个人的私有物，所以不排除某个环节中会遭到恶意窥视的行为的发生。
即使经过加密处理的通信，其通信内容仍然会被窥视到，这点和未加密的通信是一样的。只是说如果通信经过加密，就有可能让人无法破解报文信息的含义，但加密处理后的报文信息还是会被看到。
窃听相同段上的通信并非难事，只需要收集在互联网上流动的数据包(帧)就行了。对于收集来的数据包的解析工作，可以交给那些抓包或者嗅探器工具。所以说，互联网上任何角落都存在通信内容被窃听的风险。
在目前大家正在研究的如何防止窃听的保护措施中，最为普及的就是加密技术。加密的对象可以是对整个通信线路进行加密，也就是服务器和客户端之间在建立起安全的通信线路之后才开始真正的通信。还有一种是将参与通信的内容本身加密。为了做到有效的内容加密，前提是要求客户端和服务器同时具备加密和解密机制。
HTTP协议中的请求和响应不会对通信方进行确认，也就是说存在’服务器是否就是发送请求中URI真正指定的主机，返回的响应是否真的返回到实际请求的客户端’等类似问题。理论上来讲，任何人都可以发起请求，服务器只要接收到请求，不管对方是谁都会返回一个响应，这会存在以下的各种忧患：
无法确认请求发送至目标的Web服务器是，否是按照真实意图返回响应的那台服务器，有可能是已经伪装的Web服务器。
无法确认响应返回到的客户端是否是按真实意图接收响应的那个客户端，有可能是已伪装的客户端。
无意义的请求也会照单全收。无法阻止海量请求下的DoS攻击(Denial of Service,拒绝服务攻击)。
虽然HTTP协议无法确认通信方，但如果使用SSL则可以，SSL不仅提供加密处理，而且还使用了一种被称为证书的手段，可用于确认通信方。证书由值得信任的第三方机构颁发，用以证明服务器和客户端是实际存在的。另外，伪造证书从技术角度来说是异常困难的一件事。所以只要能够确认同通信方(服务器或客户端)持有的证书，即可判断通信方的真实意图。
由于HTTP协议无法证明通信的报文的完整性，因此在请求或响应送出之后直到对方接收之前的这段时间内，即使请求或响应的内容遭到篡改，也没有办法获悉。换句话说，没有任何办法确认，发出的请求/响应和接收到的请求/响应是前后相同的。因为在数据传输的途中，内容可能会被篡改。像这样，请求或响应在传输途中，遭攻击者拦截并篡改内容的攻击称为中间人攻击(Man-in-the-Middle attack,MITM).
虽然有使用HTTP协议确定报文完整性的方法，但事实上并不便捷、可靠。其中常用的是MD5,SHA-1等散列值校验的方法。但是这种方法都需要操作客户端的用户本人亲自检查验证下载的文件是否就是原来服务器上的文件，浏览器无法自动帮用户检查。另外，这种方法也依然无法百分之百的保证确认结果正确，应为MD5值本身被改写的话，用户是没有办法意识到的。
通过上面的分析，我们知道HTTP在安全方面确实存在着很大的缺陷，为了有效的防止这些弊端，有必要使用HTTPS。
HTTP加上加密处理和认证以及完整性保护后就是HTTPS。HTTPS并非是应用层的一种新协议，只是HTTP通信接口部分用SSL和TLS协议替代而已。通常，HTTP直接和TCP通信。当使用SSL时，则演变成先和SSL通信，再由SSL和TCP通信了。简言之，所谓HTTPS,其实就是身披SSL协议这层外壳的HTTP。在采用SSL之后，HTTP就拥有了安全传输的能力。
要了解https我们先来了解一下两种加密算法:对称加密和非对称加密。
对称加密特点是：加密和解密使用相同密钥的算法。它要求发送方和接收方在安全通信之前，商定一个对称密钥。对称算法的安全性完全依赖于密钥，密钥泄漏就意味着任何人都可以对他们发送或接收的消息解密，所以密钥的保密性对通信至关重要。
非对称加密特点是：有公钥和私钥之分，公钥可以给任何人，而私钥则只部署在服务器端。并且公钥加密的数据，有且只有与该公钥对应的私钥才可以解密。非对称加密的缺点是加密和解密的计算量比较大，非常消耗CPU资源。
如果需要Python方面的入门知识可以点击这个链接获取入门资料
