TLS和HTTPS加密，公钥私钥体系

 写在最前面

最近一段时间，国内各大网站纷纷用上了https连接，在访问这些网站的时候，很多浏览器会给予“特别关照”，给它们的链接旁边加上一个绿色的小锁，那么，什么是https，它与网络安全又有什么关系呢?今天我们就来谈谈https与tls(传输层安全)。

我不是计算机专业的学生，没有系统学过计算机网络相关的知识，写这篇文章是因为之前给自己挖过一个坑不得不填上，文章内容大部分来自于网络，我大概只是做了下整合，所以如果有什么错误还请大家指出，谢谢。

http之罪，为什么不安全?

http协议在制定之初，其目的仅仅是为了方便地完成html网页内容的交换，没有过多考虑安全性问题，http连接不进行身份认证，同时内容是明文传输，因此采用http协议传输的内容对于任何人来说都是公开的;这带来了很严重的安全问题：如果有人创建一个开放热点，并对连接该热点的用户http数据进行抓包，便可以轻松获取用户的用户名、密码或者其他敏感信息;这里有一个通过Wireshark抓包获取用户名、密码的例子：Wireshark如何抓明文用户名和密码;其它情况下还可以做到的，诸如分析你浏览的页面内容、替换页面内容等等，在此不再一一举例;

什么是https/TLS?

HTTPS(全称：Hyper Text Transfer Protocol over Secure Socket Layer)，是以安全为目标的HTTP通道，简单讲是HTTP的安全版，它建立在SSL(Secure Sockets Layer 安全套接层)之上，其目的是保障网络数据传输的安全。TLS(Transport Layer Security 传输层安全)是SSL的继任者，从对应关系上看应该可以算是SSL的子集。可以说，目前的https都是基于TLS而得以实现的，因此下面我们就来着重讲一讲TLS的实现及其安全性。

TLS

一个形象的解释(感谢知乎的天才老哥们)

生活中大家应该都用过一种锁，你可以用对应的钥匙打开它，打开之后如果拔出钥匙，你将合不上锁(我知道现在很多锁拔出钥匙后也能合上了，但请大家稍微配合一下_(:з)∠)_)：

下面我们用锁来讲一个故事，帮助大家更好地理解TLS的工作方式。

A和B是分隔两地的商业伙伴，两地之间除了信件往来没有其他的通讯方式，并且两地之间的信件通行状况非常糟糕，经常有人伪装成邮递员私拆信件甚至更改信件内容，曾经也有人用普通锁锁上坚固的盒子来快递，但是并没有安全的方法能把钥匙安全地送给对方而不被中间人复制;A与B想要互通信件，但是又不想让交流的内容被别人知道;恰好两人都了解有一个很聪明的人发明了一种锁，这种锁不同于以往，它需要用两把钥匙分别完成开锁和合锁的过程，一把钥匙只能开不能合，另一把只能合不能开(非对称加密)，于是两人在信件内容没有被篡改的情况下约定了一种交流方式：

* A现在手持一把特殊锁{Special_Lock}和两把对应的钥匙{Public_Key}(公钥)与{Private_Key}(私钥)，其中{Public_Key}只能用来合锁，{Private_Key}只能用来开锁;首先A用私钥打开{Special_Lock}，并把打开的{Special_Lock}与{Public_Key}通过快递寄给B; * B收到寄来的{Special_Lock}和{Public_Key}之后，把一把普通的锁{Lock_B}(对称加密)和钥匙{Key_B1}装到一个足够坚固不会被破坏的盒子里，用寄来的{Special_Lock}锁上(锁的时候需要用到{Public_Key})，并寄还给A，同时B手上还有这把普通锁的备用钥匙{Key_B2}，它与{Key_B1}一模一样;

* A收到B寄来的使用{Special_Lock}锁着的包裹后，悄悄地拿出藏起来的{Private_Key}，把特殊锁打开，拿到了属于B的{Lock_B}和能够锁上、打开这把锁的{Key_B1}，于是A很开心地写了封“Hello world!”，找了个坚固的盒子放了进去，并且用{Lock_B}和对应的钥匙{Key_B1}锁上了盒子，保留了{Key_B1}并把盒子寄还给了B * B收到快递后，使用备用钥匙{Key_B2}打开了锁{Lock_B}，得到了信件;

完成以上动作之后：A拥有了B提供的锁与钥匙，此后两人便可以用这个锁来进行安全的通信({Lock_B}的钥匙只有两人拥有)，也就是说，两人通过非对称加密的方式协商了一个{Lock_B}以及对应的钥匙{Key_B1}、{Key_B2}，此后一直通过对称加密{Lock_B}进行通讯;

现在还有一点疑问，诚然，有了第一步的特殊锁之后，送信人员不可能打开这把锁了(因为TA没有私钥{Private_Key})，但这还有一个问题，如果送信人员M悄悄扣留了A的特殊锁及其公钥，然后送给B一个自己的特殊锁及其公钥{FAKE_Special_Lock}和{FAKE_Public_Key},在B给A回信送{Lock_B}以及{Key_B1}的时候，M就可以用{FAKE_Private_Key}打开那个盒子，取出锁和钥匙，复制一份钥匙，并用之前扣留的{Special_Lock}和{Public_Key}封装起来还给A;经过这个操作，M在两者都不知情的情况下获得了接下来A、B通信所需要使用的加密密码{Key_B1};

对此TLS提出了一个解决办法： * 找一个德高望重的人(CA)，用他独一无二的签名给最初的A的那把{Special_Lock}做一个认证：这把锁是A所有——由“X”CA认证;这名德高望重的人X恪守规矩——绝对不会给不是A的锁作这个认证;因为这位大人的签名没人能模仿，因此B收到特殊锁之后只要看一眼签名是不是发给A的就知道锁有没有被掉包过了，当然前提是，A、B都信任这位德高望重的大人。

可是某一天A需要和一位与B住在同一城市的商业伙伴C联系，A与C想要效仿之前的操作建立一个安全的联系方式，但是C并不信任X这个人，因此B只好又找了个德高望重的人Y，A、B、C都信任这个Y先生;Y先生很忙，没法直接认证A的特殊锁，因此Y仅仅签名认证了X，并委托X在锁上加上了“X经过Y的‘CA认证，可以认证锁的从属’”的字样;下次C拿到{Special_Lock}之后，看到这行字，就选择信任X对特殊锁的认证，并成功和A建立了加密通信;

A的商业伙伴越来越多，人们的信任关系错综复杂，即使找来更有威望的Z给Y先生认证，也终究不是办法，最后人们选出了一个最有威望的人“ROOT”，并且大家约定，只要是“ROOT”认证过的人或者是锁，大家都无条件地信任;这位“ROOT”就是根CA，TA所写的“ROOT认证xxx”的内容，称为根证书。

（编辑：新余站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!