网络安全协议如何保护隐私安全

互联网迅速发展，互联网大厂相继推出独有特色的软件和不同类型的平台，成为企业提升品牌知名度和竞争力的重要工具。科技发展的速度不仅为广大群众带来生活上的改变，带来了各种便捷性，从网购或是办理业务，到社交都有互联网的身影。

从2016年至如今，已经实现了“出门只需拿手机”的概念。随着广泛的应用，每个人担心的问题也浮出水面。数据库容纳数据之大，又要怎么样保全用户的数据安全与隐私安全？

在互联网发展的早期，蒂姆·伯纳斯·李在设计的网络传输超文本的协议（HyperText Transfer Protocol)，以明文的方式来实现不同设备之间的信息交换和资源共享。成为最为广泛的协议之一。为电子商务、社交、在线办公等各种互联网应用奠定了基础。

由于HTTP（HyperText Transfer Protocol)还是存在安全缺陷及广大群众对网络安全需求不断提升，SSL（Secure Sockets Layer)协议，即“安全套接层”协议由此而生，SSL诞生于上世纪90年代，通过在应用层和传输层之间添加一个安全层，实现对数据的加密、身份认证和完整性保护。在标准化后名称更改为TLS（Transport Layer Security)即“传输层安全”协议。

在HTTP协议的基础上引入了SSL/TLS协议来保障数据传输的安全性，这就是所谓的HTTPS（HyperText Transfer Protocol Secure)。以安全为目标的HTTP通道，通过传输加密和身份认证保证了传输过程的安全性。网络传输不再像上述中提及的“明文”传输，而是加密之后的“密文”。

我们来可以看下它是怎么实现。

首先简单了解一下“加密与解密”的概念。加密是把明文经过一系列变换，形成密文。解密是把密文经过一系列变换，还原成明文。明文就是我们能看懂的信息，密文就是我们看不懂的东西。比如现在就是以明文的形式显示的，但如果我将其变为火星文，所有人都看不懂，那它就变成密文了

在加密和解密的过程中需要一个或者多个辅助数据，我们称为“密钥”。假设我们要加密的消息（明文）是“Hello”，并且我们选择的密钥是3（意味着字母表中的每个字母向后移动3位）得出：

l H -> K（H向后移3位是K）

l E -> H（E向后移3位是H）

l L -> O（L向后移3位是O）

l L -> O（同上）

l O -> R（O向后移3位是R）

（如果这里超过了Z则重新循环到A）

经过加密后哦的密文是“KHOOR”。

现在，如果我们收到的密文“KHOOR”并知道密钥是3，通过反向操作来解密，也就是把每个字谜向前移3位还原明文：

l K -> H（K向前移3位是H）

l H -> E（H向前移3位是E）

l O -> L（O向前移3位是L）

l O -> L（同上）

l R -> O（R向前移3位是O）

这样就成功把密文“KHOOR”还原成明文“HELLO”。在这个例子中，密钥就是那个固定的数字3，在加密和解密的过程中起到至关重要的作用，确保只有拥有密钥的人才能正确解码信息。

那么为什么要加密解码呢？

因为信息如果都是明文形式传输，很难避免会遭到手机个人信息等隐患，其次是可能存在信息劫持，个人信息泄露等问题，所以才需要进行加密，保护隐私安全。

举一个关于明文传输弊端的例子：假设我们需要下载软件A，我们点击“下载”其实就是给服务器发送一个HTTP请求，我们通过网络传输的任何数据包都会经过运营商的网络设备（路由器，交换机等），所以我们发出的HTTP请求会先经过运营商的网络设备（路由器，交换机等），然后再回到软件A的服务端，原路返回HTTP响应，获取到的HTTP响应就是包含了这个软件A的下载链接。

原路返回HTTP响应式，还是会经过运营商的设备，这时候运营商可以选择劫持这个 HTTP请求，劫持之后会发现这个请求是要下载软件A，它不想让我们下载软件A，于是把服务器交给用户的HTTP响应给偷偷篡改成软件B的下载地址，再把这个响应返回给用户。而这时候用户本来想下载软件A，却变成了软件B。

因为HTTP的内容是明文传输的，明文数据会经过路由器、WiFi热点、通信服务运营商、代理服务器等多个物理节点，如果信息在传输过程中被劫持，传输的内容就完全暴露了。劫持者还可以篡改传输的信息且不被双方察觉，这就是“中间人攻击”，所以我们才需要对信息进行加密。

在互联网上，明文传输是比较危险的事情！HTTPS就是再HTTP的基础上进行了加密，进一步保证用户的信息安全。实现的原理首先是应用层将HTTP响应/请求传递给SSL/TLS这个过渡层，然后再传递给传输层。各种软件下载、互联网大厂、企业官网等都必然会采取这种手段，保障双方数据安全。

加密的方案有非常多的类型，在这里也简单了解下。

1. 使用对称加密：比如通信双方都各自持有同一个密钥X，且没别人知道，这两方的通信安全当然是可以保证的，即使数据被解惑，由于黑客不知道密钥是什么，因此无法进行解密，也不会知道内容是什么了（除非密钥被破解）。但事情没那么简单，服务器同一时间其实在给很多客户端提供服务，这么多客户端，每个人用的都必须是不同的密钥，因此服务器就需要维护每个客户端和每个密钥之间的关联关系，由于结果不好和实现难度大，一般人不会考虑单独使用堆成加密。

2. 使用非对称加密：我们要知道，不是只有公钥才能加密，私钥也可以加密，同理公钥能解密，私钥也能解密。但鉴于非堆成加密的机制，如果服务器先把公钥以明文方式传输给浏览器，之后浏览器向服务器传数据前都先用这个公钥加密好再传递，从客户端到服务器信道似乎是安全的（有安全隐患），因为只有服务器有相应的私钥才能解开公钥的数据。但是如果服务器应用私钥来对数据进行加密，然后传给浏览器，那么浏览器用公钥可以解密它，而这个公钥是一开始通过明文传输的，若这个公钥被“中间人攻击”劫持到了，那么劫持者也能用这个公钥解密服务器传来的信息。

3. 双方都使用非对称解密：服务端拥有公钥A1与对应私钥A11，客户端拥有公钥B1和对应的私钥B11。服务器先把公钥A1明文传输给浏览器，浏览器将公钥B1传递给服务器。客户端给服务端发信息：先用A1对数据加密再发送，只能由服务器解密，因为只有服务器有私钥A11。服务端给客户端发信息：先用B1对数据加密再发送，只能由客户端解密，因为只有客户端有私钥B11。（可行，但是效率比较低）

4. 非对称加密+对称解密：这种方案是弥补了第一个方案的遗憾。来看下运行过程：

服务端具有非对称公钥S1和私钥S11 -> 客户端发起HTTPS请求 -> 获取服务端公钥S1 -> 服务端以明文方式发送公钥S1给客户端 -> 客户端在本地生成对称密钥C，通过公钥S1加密，发送给服务器。

由于中间的网络设备没有私钥，即使截获了数据，也无法还原出内部原文。

服务器通过私钥S11解密，还原出客户端发送的对称密钥C，并使用这个对称密钥C加密给客户端返回的响应数据。由于该密钥只有客户端和服务器梁哥主机知道，其他主机/设备不知道密钥即使解惑数据也没有意义，后续客户端和服务器的通信只需要用对称加密即可。