现在网络上使用http的网站越来越少了，这很大部分原因要归功于浏览器的强制要求，浏览器强制用户使用https而非http，人们的安全意识也逐渐增强了。
那么为什么使用https协议是足够安全的呢？
首先协议的本质，至少站在程序员角度去看，就是一段按照协议要求编写的程序，而且必然是供两端或者多端使用的，要不然不可能会被定义为协议，比如TCP协议，IP协议，ICMP协议，ARP协议等网络相关协议，协议所要解决的本质诉求必然是通信。哪怕是电子电路中的协议也一样，CAN,SPI,I2C,UART,USB等都是解决电路之间通信问题， 蓝牙、wifi、星闪、nfc协议都是解决无线通信问题，http(https)、ftp、smb、ssh等是为了更方便的解决网络通信问题而生。它们的诞生本质就是为了方便，如果把IP,ARP等协议比作钻木取火，那么http(https)就是打火机。
越原始的协议构造越简单，无论怎么变化，怎么定义，它们都是为了传输数据，既然是传输，就势必会有安全问题，网际传输会经过无数路由和交换机，它们一个个都是快递转运站，谁能保证快递员不拆开包裹来瞧一瞧？http对快递员来说就是一个使用了透明盒子的协议，你里边的数据完全公开，但是用http传输也可以是安全的，那就需要程序员把数据加密后再丢给http协议，对端收到后再解密。那么问题来了，谁能保证密钥安全，加密算法安全，这两个东西泄漏了就和透明没啥两样，特别是CS架构下，客户端若去解密，相当于明文了，代码一览无余。
https就是为了解决上面的问题而生，其本质就是在数据按照http协议加工之后，在http数据传输之前将数据加密，然后发送，对端在接收之后解密，然后按照http协议解包还原。
那么加密后一定安全吗？密钥和算法被攻破怎么办？网景公司软件工程师设计https之初肯定也想到了，它们想着只要密钥不被攻破，那么传输就是安全的，还好数学上有一个叫做非对称加密的东西，即使我算法摆给你看，只要你拿不到我的私钥，我们之间的通信就是安全的。
https最核心的安全实现就是利用了非对称加密，非对称加密的本质是大质数极难分解。由两个因子产生一个公钥和一个私钥，而且他们其中一个加密，另一个可以解密，它们的诞生全都源于这两个因子，你无法从公钥私钥反推两个因子，因为分解难度极高。之所以一个加密，另一个能解密是由于它们具备某些数学特性，可以看做一个黑盒，就是这么神奇地被发现了，没有什么理由，这背后说不定和造物主有关。
我们把公钥加密，私钥解密称之为对数据进行了非对称加密，而用私钥加密，公钥解密称之为签名验证，这是非对称加密的两种应用。
https 有了非对称加密后，数据安全是有保证了，但是还要解决一个传输效率问题，因为非对称加密时间复杂度很高，如果传输数据都要使用非对称加密，那https的延迟高的没法用了，所以https采用的办法是引入对称加密，非对称加密RSA只对 对称加密的密钥进行加密，没人能解出对称加密的密钥，那不就是最安全的吗？
https解决了效率问题，又有一个问题产生了，我作为服务器，我假冒一个银行系统，你登录我的网站，你全程都是用我的公钥和我来通信，你输入的密码在最终会被我的私钥进行解密，虽然互联网上别人没法获取，但是我获取到了，我再利用这个密码去真的银行把钱转走，这就是信任危机。客户端怎么来信任你，这就是签名技术，客户端需要信任这个公钥就是来自官方，怎么做呢？找第三方权威机构呗，权威机构使用它们的私钥对官方的公钥进行加密，也就是签名，我们拿权威机构的公钥来验证官方的公钥，也就是解密。解密失败就是该公钥非法，权威机构的公钥怎么信任呢？那只能信任，权威机构的公钥以证书的形式内置在操作系统中，不信任都没办法。实际的公钥是以证书的形式发送的，证书包含了公钥以及官方的域名、主机、签发时间、有效期等信息，也包含了权威机构的签名信息。
https解决了信任问题，又产生新问题了，虽然我不知道你的数据是什么，但是我可以修改，当我中间将密文修改再转发给目标，此时服务端必然解密失败，面对这种捣乱的行为确实无解，但这对攻击者也没啥好处，我们假设攻击者恰巧伪造了一段居然能被解开的数据，但却不是原数据，整个事情就是这么凑巧，那面对这种情况需要引入防篡改机制，哈希就是这个用途，在对数据进行对称加密的同时，原数据会做一次哈希摘要，这个摘要连同密文一并发给对端，对端在解密后，还要对原文做一次哈希摘要来和对端发过来的对比是否原文被篡改过，这在安全层面上又添上了一大保障，哈希算法的本质就是将大区间的数据映射到小范围的数，它不可还原，但不同数据所映射形成的数几乎不可能是同一个，因为https所使用的哈希是带密钥的哈希，每次安全链接的哈希密钥都是协商出来的而且不是同一个，这种概率极低极低。如果奇迹真发生了，不同数据产生了同样的哈希值，并且还是同一次连接，那我们说发生了哈希碰撞，但从https应用的角度讲，没有任何影响。
解决完上述问题后，https诞生了，其流程如下：
1.客户端和服务端建立TLS连接(期间协商了使用的加密算法，还互送了两个随机数给对方)
2.服务器将证书(包含了公钥、签名、有效期、域名、主机等信息)发给了客户端
3.客户端用系统证书来验证该证书的合法性和有效性。
4.客户端生成一个前置加密密钥，使用商定好的RSA算法对该密钥加密，并将该密钥传给服务器。
5.服务器收到后，解密得到前置加密密钥。两端各自使用该密钥配合前面的随机数生成一个实际密钥，该密钥不是一个，而是四个，分别是客户端加密密钥，服务端加密密钥，客户端哈希密钥钥和服务端哈希密钥。因为两端信息对等，所以算出来的都是一致的。
6.客户端使用客户端对称密钥对原文进行加密，同时对原文进行哈希摘要，将密文和哈希摘要发送给服务端。
7.服务端收到后用用客户端对称密钥进行解密，然后对解密后的数据也做一个哈希摘要，进行比对，来验证来源的可靠性。
8.服务端向客户端通信则使用服务端的密钥，方式同客户端加密一致。
上述流程保证了https的安全性，在私钥不泄漏的情况下，即使试出了对称密钥和哈希密钥，你也不可能同时算出客户端的和服务端的，就算都算出来，每一次安全通信，随机数不同，密钥也完全不同，你解出来的信息是过时的，所以https的安全性得到了最大的保障。