Q：请你说一下对HTTPS的理解。
A：Https协议是对http协议的改进。首先我来说一下http协议以及它的安全性问题。
http是超文本传输协议，可以对文本、图像、音频、视频等多媒体信息在网络上进行传输与格式的排版，是tcp/ip协议中的应用层协议。HTTP协议是明文传输的，在一些共享式局域网中，比如我们经常使用到的以太网，可能会出现一些比如流量嗅探甚至man in the middle攻击（篡改用户和服务器之间的通讯的流量）。一般情况下，网卡只接受目的mac地址是自己的mac地址的报文，但是，大多数网卡有混淆功能，即，开启了这个功能，不管是什么mac目的地址，网卡都会接受，同时，http报文又是明文传输，比如一些网站的用户名密码就在这个明文报文当中。如果局域网中有人这么做，那么自己的隐私甚至资产会得不到保障。
另外，配合arpspoof（arp欺骗）攻击，会形成更为强大的中间人攻击（黑客冒充用户与服务器直接对话，另一方面，又冒充服务器与用户进行对话），可以任意更改客户端与服务器之间的流量。所以，为了解决http的这种问题，就有大牛提出了https协议。
https协议可以看作是对http协议的一个封装，末尾的s可以认为是secure的含义。这个sucure是通过tls来实现的。
既然http是明文形式的，不安全，那么，对传输的数据进行加密就可以了。但是，因为客户端和服务器在通信之前是互不相识的，所以，他们在传输加密报文前，一定会有密钥的明文传输。如果这个密钥被hacker窃取，那么就算客户端和服务器之后是通过密文传输的，也是没有任何作用的，因为hacker手中就有解锁密文的钥匙。所以，就有了第二种方案，第二种方案是通过非对称加密技术来实现。首先，服务器在本地生成用于非对称加密的公钥和私钥，私钥自己留着，将公约通过明文传输给客户端，客户端再将后续用于加密的对称加密的密钥，使用服务器传送来的公钥进行加密，将这个加密的密钥传送给服务器，因为hacker没有私钥，所以不能对这个公钥加密的报文进行解密。服务器收到后可以进行解密，得到后续用于和客户端进行通讯加密时所用的密钥。整个密钥的传输过程结束。
但是这个第二种方案也有一定的问题，虽然可以防止流量嗅探，但是，却防不了中间人攻击。原因是：hacker冒充用户，接受到服务器传输来公钥，另一方面，自己生成一对和服务器不同的公钥和私钥，以服务器的身份将公钥传送给真正的用户。用户此时并不知道这个公钥是hacker假冒的，因此按照正常流程生成对称加密的密钥传给hacker。hacker此时就得到了这个密钥，然后冒充用户将这个密钥用真正的服务器给自己的公钥进行加密。此后，服务器和用户进行正常通讯，但是，却以hacker作为报文中转站，hacker对流量拥有了绝对的控制权。
所以，先采用的不是上面说的前两种方案，而是第三种。第三种方案采用数字证书（CA）的方式进行。服务器A和客户端B在通信之前相互不认识对方，因此，他们找CA签发机构C来互相为对方做证明。这个C是被大家公认的没有安全性问题的对象。首先，在A服务器部署时，就要向C申请一份CA证书，这个证书里有C给自己的公钥k1和密钥k2。在A和B通讯时，A将k1以明文形式传输给B，B收到这个k1后，要先向C询问，这个k1是否是C提供给A的。通过这个“询问”的过程，就可以破解第二种方案的hacker的中间人攻击。
还有几点需要补充的是，这个CA证书的可靠性一般是信任传递的过程，C信任D，D信任E，如果我们信任C，那么默认我们也信任D、E。C就叫做根证书。在https通讯前，需要先进行TCp的三次握手，然后再进行HTTPS的密钥交换（HTTPS握手），之后就可以进行正常的通讯了。最后，TLS协议是一个移植性非常好的协议，SSH也是用的TLS进行的加密。