https原理和使用流程

发表于 更新于 分类于

https原理

比较严肃，看这里

下面的部分比较好懂，其实是抄的这里

引言：从传纸条的困境说起

想象一下，你和班上的心仪对象相距甚远，只能依赖中间的同学帮忙传递纸条来交流。一开始一切甜蜜，但很快就出现了两个致命的问题：一是有人偷看纸条，把你们的秘密作为茶余饭后的谈资；二是有人篡改内容，导致你们之间产生误会。

为了解决这个问题，你必须在所有信息交互都必须通过中间人传递的前提下，找到一种安全通讯的方法。这套“顶级的阳谋”就是今天网络安全传输的基石——HTTPS协议。

第一步：保护内容——对称加密

最初的想法很简单：把要传递的消息放到一个带锁的盒子里。发送方使用一把钥匙上锁，接收方再用同一把钥匙解锁。这把钥匙就是“密钥”，这种加密和解密都使用相同密钥的方式，被称为对称加密。

对称加密虽然保护了信息本身的安全，但在现实场景中存在一个根本性缺陷。由于所有信息必须通过中间人传递，这把用来加密的密钥也必须通过中间人来传递。一旦中间人知道了密钥的信息，你们的通信就不再安全了。

问题核心： 如何在不安全的通道中安全地传输密钥？简单地用多层对称加密套娃是行不通的，因为最外层的密钥始终存在泄露的风险。

第二步：保护密钥——非对称加密

为了解决密钥传输问题，聪明的人们发明了一种神奇的锁，它拥有两把钥匙：A和B。

这种锁的神奇之处在于：如果用A钥匙加锁，必须用B钥匙解锁；反之，如果用B钥匙加锁，则必须用A钥匙解锁。这种加密和解密使用不同密钥的方式，被称为非对称加密。

在这种机制下，我们定义两种密钥：

  1. 私钥 (Private Key A)： 只有你自己知道，没有告诉任何人。
  2. 公钥 (Public Key B)： 对所有人公开。

通过非对称加密，我们得出一个关键结论：公钥加密，私钥解密，可以实现消息的保密传输。

利用非对称加密传输对称密钥（M）

现在，我们可以利用非对称加密的特性，安全地传输用来进行日常通信的对称密钥（M）。

这个过程分为三步，目的是让你的对象把密钥M安全传输到你手中：

  1. 公开公钥： 你将你的公钥 B 传给你的对象（相当于对外公开了，中间人可以保留一份，无所谓）。
  2. 加密密钥： 你的对象用收到的 公钥 B 加密他们手中的对称密钥 M。
  3. 安全接收： 你的对象把加密后的消息传给你。只有你手里的 私钥 A 才能解密拿到对称密钥 M。

此时，双方手中掌握了同一个对称密钥 M，就可以安全通信了。由于中间人没有你的私钥 A，他们无法解密。

第三步：防止篡改——中间人攻击与数字签名

虽然非对称加密保护了对称密钥 M 的传输安全，但新的问题随之出现：公钥 B 的传输仍然是明文的。尽管你不怕中间人看到公钥，但你必须警惕他们篡改公钥。

中间人攻击 (MITM)

中间人攻击的过程是绝妙且危险的：

  1. 在你将公钥 B 传给你的对象时，中间人将其拦截并替换成自己伪造的伪造公钥发送给你的对象。
  2. 你的对象用中间人伪造的公钥加密 M。此时，中间人可以轻易解密拿到 M。
  3. 随后，中间人再用真正的公钥 B 加密 M，发送给你。
  4. 你用自己的私钥 A 解密，成功拿到 M，并未发现任何问题。
  5. 你的对象也未发现问题。

最终，中间人神不知鬼不觉地知道了你们的通信内容 M。

解决方法：签名与验证

为了防止信息被篡改或伪造，我们引入了另一个非对称加密的应用：私钥加密，公钥解密。

  • 私钥加密：通常叫做签名。
  • 公钥解密：则是验证签名的过程，叫做验签。

通过这种方式，我们可以在传输公钥 B 时，再套一层非对称加密，用一个私钥 C 加密，让对方用对应的公钥 D 来解密。如果中间人想要篡改里面的信息，他们就需要用私钥 C 重新加密，而私钥 C 是中间人不知道的，因此无法篡改。

新的挑战： 然而，公钥 D 此时又变成了明文传输，仍然可能被中间人篡改。如果不断套用非对称加密来保护上一层的公钥，问题永远无法根治。

第四步：信任体系——引入 CA 机构

光凭通信双方自身，无法解决公钥被篡改的根本问题，必须引入一个可信的第三方来帮忙。

现在的核心问题是：如何防止中间人在公钥 B 传输过程中篡改它？

  1. 委托第三方签名： 你将公钥 B 交给一个可信的第三方（CA机构）。这个第三方机构也拥有一套公私钥。
  2. 生成数字签名： 第三方用自己的私钥对公钥 B 进行加密，形成一个数字签名。
  3. 传输与验证： 你将这个数字签名和你的公钥 B 一起发给你的对象。
  4. 信任验证： 你的对象使用第三方的公钥解密。一方面可以拿到你的公钥 B，另一方面也可以进行比对，确认它是否被篡改。

有人可能会问：中间人是否可以伪造一个第三方的公钥，像刚刚那样进行中间人攻击呢？

答案是：可以，但中间人胡乱生成的公钥不具备可信度。只要接收方增加一步验证环节——如果这个公钥不属于大家公认可信的第三方，就拒绝后续的通信过程。

我们将这个公认可信的第三方权威机构叫做 CA（Certificate Authority），即证书颁发机构。

总结：HTTPS 的诞生

将你和你的对象换成计算机，将中间传递纸条的同学换成网络环境，那么这一整套用于网络安全传输的协议就叫做 HTTPS。

现在我们访问网站，地址基本都是以 https:// 开头的。例如，在 Chrome 浏览器中打开百度，你可以看到 CA 机构的名称、网站的公钥以及数字签名等信息。

HTTPS 的目标：帮助通信双方协商出一个用于对称加密的密钥 M。而中间人的目标是想方设法神不知鬼不觉地知道这个 M 是什么。

为了实现这一目标，HTTPS 建立了一个层层保护的机制：

  1. 内容保护： 使用 M 进行对称加密。
  2. 密钥 M 保护： 套上一层非对称加密来传输 M。
  3. 公钥保护： 再通过 CA 机构做签名，防止非对称加密中使用的公钥被篡改。

当你毫不在乎地在浏览器里输入地址时，请记住这个毫不起眼的 HTTPS，它是人类的智慧结晶。这是深处完全不可信的网络环境中的一套顶级阳谋，让你可以在全世界的眼皮子底下安心对话。

小结：HTTPS就像一个高度复杂的邮寄系统。我们最终目的是用一把简单的锁（对称加密 M）来传输信件。但为了安全地把这把锁的钥匙 M 送到对方手上，我们先把它放进一个只有你才能打开的保险箱里（非对称加密）。为了确保这个保险箱的接收地址（公钥）没有被邮递员（中间人）偷偷换掉，我们请来一个公证处（CA）盖章认证。只有公证处认证过的地址，这个保险箱才会被信任和接收。

使用流程

  1. 上阿里云或七牛云的免费ssl服务，阿里云不用填什么资料直接就审核了，七牛云好像麻烦一点。
  2. 配置DNS
  3. 审核通过之后，下载证书文件，将证书文件放在Nginx安装目录cert中，一般为/etc/nginx
  4. 配置nginx，主要是将http重定向到https上
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    server {
        listen       80;
        server_name  _;

        location / {
            rewrite ^/(.*)$ https://yongxinxue.xin/$1 permanent;
        }
    }

    server {
        listen 443;
        server_name _;
        ssl on;
        ssl_certificate   cert/214462643660969.pem;
        ssl_certificate_key  cert/214462643660969.key;
        ssl_session_timeout 5m;
        ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_prefer_server_ciphers on;
        location / {
            if ( $host != 'yongxinxue.xin' ){
                rewrite ^/(.*)$ https://yongxinxue.xin/$1 permanent;
            }
            proxy_pass http://127.0.0.1:8080;
            proxy_set_header Host $host;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }