1、http安全问题：
泄密，个人隐私、账户密码等信息可能会被盗取。
篡改，收到的数据可能被第三方修改过，或被植入广告等。
假冒，访问的站点非目标服务器站点。如域名欺骗、域名劫持、钓鱼网站等。
为了保护数据隐私，让数据不再“裸奔”。对需要传输的数据进行加密处理就很有必要了。目前而言，加密算法可以分两大类，一类是对称加密算法，还有一类是非对称加密算法。
对称加密
对称加密算法的加密和解密都是用同一个密钥。客户端需要将秘钥和数据传输给服务端，所以存在密钥泄露的问题！如银行采用的是离线加密狗，保证密钥安全。
非对称加密
非对称加密算法需要一组密钥对，分别是公钥和私钥，这两个密钥是成对出现的。公钥加密的内容需要用私钥解密，私钥加密的内容需要用公钥解密！私钥由服务器自己保存，公钥发送给客户端。
客户端拿到公钥后就可以对请求进行加密后发送给服务端了，这时候就算被截获，如果没有私钥也无法解密发送的内容，这样确保了客户端发送到服务端数据的“安全”！
问题：由于公钥也需要通过网络发送给客户端，同样能被截获并替换；并且非对称加密的效率很低。
客户端怎么防止公钥被假冒，怎么能确定对方是真正的目标服务器？怎么证明服务器的身份？于是有了数字证书！
数字证书
当服务器需要告诉浏览器公钥时，并不是简单地返回公钥，而是响应包含公钥信息在内的数字证书。
数字证书包含内容：服务器的公钥、颁发机构信息、签名中的hash摘要算法。
以上等内容通过【颁发机构的私钥】摘要签名生成证书。
浏览器通过【颁发机构的公钥】对数字证书解密验签，验签通过即说明证书的真实性，可以放心取证书拥有者的公钥了。（常用CA机构的公钥都已经植入到浏览器里面）
客户端拿到数字证书后，先通过操作系统或者浏览器内置信任的CA机构找到对应CA机构的公钥对数字证书进行解密，然后采用同样的摘要算法计算数字证书的摘要，如果自己计算的摘要与服务器发来的摘要一致，则证书是没有被篡改过的！这样就防止了篡改！第三方拿不到CA机构的私钥，也就无法证书进行加密，如果是第三方伪造的证书自然也在客户端无法解密，这就防止了伪造！所以数字签名就是通过这种机制来保证数字证书不被篡改和伪造。
以上保证了 [浏览器?服务器] 是加密的，然而 [服务器?浏览器] 却没有；另外一个是性能问题，如果所有数据都使用非对称加密的话，会消耗较多的服务器资源，通信速度也会受到较大影响。
HTTPS巧妙地结合了非对称加密和对称加密，在保证双方通信安全的前提下，尽量提升性能。
HTTPS建立安全连接的基本流程
HTTPS=HTTP+SSL，在HTTP层和TCP之间加了一个SSL/TLS层，HTTPS（SSL/TLS）期望建立安全连接后，通信均使用【对称加密】。
建立安全连接的任务就是让浏览器-服务器协商出本次连接使用的【对称加密的算法和密钥】；协商过程中会使用到【非对称加密】和数字证书。
客户端通过与服务端四次握手，确定对称加密算法和拿到服务端的公钥，客户端随机生成对称加密的秘钥。客户端通过公钥对对称加密的秘钥进行加密，然后将公钥加密的秘钥传输给服务端，服务端通过私钥解密拿到对称加密的秘钥。
然后通过对称秘钥在两边传输数据。
为什么有HTTPS了，往往还要在应用层进行一次加密/签名？
确认发送端的身份。值得注意的是，HTTPS只是保证了传输过程中防止被窥视和被假冒篡改信息，任何人都可以请求建立安全连接（SSL/TCL握手），发送内容。如果想要限制只接受处理某些请求的话，除开IP白名单外，在应用层再加一个签名验证就是个不错的选择。
安全性。从客户端到真正处理的应用服务器，途中可能会经过很多中转（代理）服务器，对于极其敏感的数据，应用方并不希望中转服务器有看到明文的机会。另外中转协议并不一定全部都是HTTPS，像内网中转往往就是使用HTTP的（SSL卸载）。