HTTPS 为什么更安全_证书 可以随便申请 为什么会更安全

http需要更安全

任何一个不怀好意的家伙都可以监听我们通信，打开我们发送的数据包。最简单的方式是每次传输之前， 把消息用一个加密算法加密， 然后发到对方这里以后再解密。加密和解密算法是公开的，密钥是保密的， 只有两人才知道， 这样生成的加密消息（密文） 别人就无法得知了(对称加密)。这样做有一个缺点，密钥又无法通过网络发送。
解决这个问题是通过RSA算法。RSA算法非常有意思，它不像之前的算法， 双方必须协商一个保密的密钥， 而是有一对钥匙， 一个是保密的，称为私钥，另外一个是公开的，称为公钥。用私钥加密的数据，只有对应的公钥才能解密，用公钥加密的数据， 只有对应的私钥才能解密（非对称加密）。 当A给B发消息的时候， 就可以先用B的公钥去加密（反正B的公钥是公开的，地球人都知道）。
但这个带来了另一个问题，RSA算法比之前的对称密钥算法要慢上百倍。可以通过分两步走：(1) A生成一个对称加密算法的密钥， 用RSA的方式安全发给B (2) 随后就不用RSA了， 只用这个密钥，利用对称加密算法来通信。
上述的方式还是存在漏洞，当中间人截取了公钥之后，便可以在A和B之间窃听信息。在现实中有公证处，它提供的公证材料大家都信任，那在网络世界也可以建立一个这样的具备公信力的认证中心， 这个中心给大家颁发一个证书， 用于证明一个人的身份，这个证书里除了包含一个人的基本信息之外，还有包括最关键的一环：这个人的公钥。
但是证书怎么传输呢？可以加一个数字签名。B可以把他的公钥和个人信息用一个Hash算法生成一个消息摘要， 这个Hash算法有个极好的特性，只要输入数据有一点点变化，那生成的消息摘要就会有巨变。让有公信力的认证中心（简称CA）用它的私钥对消息摘要加密，形成签名。当B把他的证书发给A的时候， A就用同样的Hash 算法， 对公钥和个人信息再次生成消息摘要，然后用CA的公钥(每个机器都有)对数字签名解密， 得到CA创建的消息摘要， 两者一比，就知道有没有人篡改了。(除非CA的密钥丢失，否则是安全的)。

https

HTTPS是建立在密码学基础上的一种安全通信协议，严格来说是基于HTTP协议和SSL/TLS的组合。理解HTTPS之前有必要弄清楚一些密码学的基础概念，下面逐个解释

密码

密码学中的密码与网站登录的密码(password)是不一样的概念，密码学中的密码(cipher)是一套算法(algorithm)，这套算法用于对消息进行加密和解密，从明文到密文称之为加密，密文反过来生成明文称为解密，加密算法与解密算法结合在一起称为密码算法。

密钥

密钥(key)是在使用密码算法中输入的一段参数，同一个明文在相同的密码算法和不同的密钥计算下会产生不同密文。可以将密码算法想象成一个函数，明文和密钥是输入的加密参数，return的密文因为参数输入不同而不一样。很多知名的密码算法都是公开的，密钥才是决定密钥是否安全的重要参数，通常密钥越长，破解的难度越大，比如一个8位的密钥最多有2的8次方即256种情况，使用穷举法，能非常轻易破解。密钥越长，加密解密时间越长。根据密钥的使用方法，密码可以分为对称加密和公钥加密。

对称加密

对称密钥(Symmetric-key algorithm)又称为共享密钥加密，加密和解密使用相同的密钥。对称密钥的优点是计算速度快，但是它也有缺点，接受者需要发送者告知密钥才能解密，因此密钥如何安全地发送给接受者成了一个问题

非对称加密

公开密钥与私有密钥是一对，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。非对称加密消除了最终用户交换密钥的需要。使用最广泛的非对称加密算法是RSA算法。

消息摘要

消息摘要(message digest)函数是一种用于判断数据完整性的算法，也称为散列函数或哈希函数，函数返回的值叫散列值，散列值又称为消息摘要或者指纹(fingerprint)。这种算法是一种不可逆的算法，因此你没法通过消息摘要反向推倒出消息是什么。所以它也称为单向散列函数。下载软件时如何确定是官方提供的完整版呢，如果有中间人在软件里面嵌入了病毒，你也不得而知。所以我们可以使用散列函数对消息进行运算，生成散列值，通常软件提供方会同时提供软件的下载地址和软件的散列值，用户把软件下载后在本地用相同的散列算法计算出散列值，与官方提供的散列值对比，如果相同，说明该软件是完成的，否则就是被人修改过了。常用的散列算法有MD5、SHA。消息摘要可以看做消息的唯一映射码。
消息摘要算法的主要特征是加密过程不需要密钥，并且经过加密的数据无法被解密，只有输入相同的明文数据经过相同的消息摘要算法才能得到相同的密文。消息摘要算法不存在密钥的管理与分发问题，它是公开的，因此只用来比对。
下载 Eclipse 时，官方网站同时提供了软件地址和消息摘要，数据摘要算法在前端工程化中判断文件是否更新也有用到前端代码部署
摘要算法可以保证数据完整性，但是不能识别出数据是不是伪装的，因为中间人可以把数据和消息摘要同时替换

消息认证码

消息认证码(message authentication code)是一种可以确认消息完整性并进行认证(消息认证是指确认消息来自正确的发送者)的技术，简称MAC。消息认证码可以理解为一种与密钥相关的单向散列函数。
A 给 B发送消息前，先把共享密钥（key）发送给 B，A 把消息计算出 MAC 值，连同消息一起发送给 B，B 接收到消息和 MAC 值后，与本地计算得到 MAC 值对比，如果两者相同，就说明消息是完整的，而且可以确定是 A 发送的，没有中间人伪造。不过，消息认证码同样会遇到对称加密的密钥配送问题，因此解决密钥配送问题还是要采用公钥加密的方式。

数字签名

A发邮件找B借1000块钱，而邮件可以被篡改为10万，也可以被伪造，或者A借了钱之后不承认。
消息认证码可以解决篡改和伪造的问题，A不承认借钱时，B找第三方机构做公证，公证方也无法判断A是否真的借钱，因为它们共享了密钥，也就是说两个人都可以计算出正确的MAC值。
数字签名(Digital Signature)可以解决否认的问题，发送消息时，A和B使用不同的密钥，把公钥加密算法反过来使用，发送者使用私钥对消息进行签名，而且只能是拥有私钥的A可以对消息签名，B用配对的公钥去验证签名，第三方机构也可以用公钥验证签名，如果验证通过，说明消息一定是B发的。
它的流程是:

第一步：发送者 A 把消息哈希函数处理生成消息摘要，摘要信息使用私钥加密之后生成签名，连同消息一起发送给接收者 B。

第二步：数据经过网络传输，B收到数据后，把签名和消息分别提取出来。

第三步：对签名进行验证，验证的过程是先把消息提取出来做同样的Hash处理，得到消息摘要，再与 A 传过来的签名用公钥解密，如果两者相等，就表示签名验证成功，否则验证失败，表示不是 A发的。
所以数字签名在使用中就是签了名的消息摘要。

公钥证书

如何保证公钥是合法的呢，如果遭到中间人攻击，掉包怎么办，这时候公钥就应该交给一个第三方权威机构来管理，这个机构就是CA，CA把用户的姓名、组织、邮箱地址等个人信息收集起来，还有此人的公钥，并有CA提供数字签名生成公钥证书。
数字证书一般会包含公钥，公钥拥有者名称，CA的数字签名，有效期，授权中心名称，证书序列号等信息。
CA会用自己的私钥将证书内容加密，因为CA的公钥是公开的，任何人都可以用公钥解密出CA的数字签名的摘要，再用同样的算法提取出证书的摘要，一致说明这个证书没有被篡改过。
所以CA的作用在于，让通信双方需要拿公钥的时候拿到真正的公钥。
A 向 B 发送消息时，是通过 B 提供的公钥加密后的数据，而 A 获取的公钥并不是由 B 直接给的，而是由委托一个受信任的第三方机构给的。而CA的权威性是怎么保证的，互联网中会有一个顶级的CA最受信任，其他的CA机构可以向上一级机构申请成为中间CA，然后生成自己的中间证书。当A获得B的数字证书后，会找到B申请的CA，然后沿着证书链查找，假如某个中间证书或者根证书在本机安装中有，则认证的时候，会将B的证书设置为可信任的。

B 生成密钥对，私钥自己保管，公钥交给认证机构 T。
T 经过一系列严格的检查确认公钥是 B本人的
T 事先也生成自己的一套密钥对，用自己的私钥对 B 的公钥进行数字签名(让接收方确认是T颁发的)并生成数字证书。证书中包含了 B 的公钥。公钥在这里是不需要加密的，因为任何人获取 B 的公钥都没事，只要确定是 B 的公钥就行。
A 获取 T 提供的证书。
A 用 T 提供的公钥对证书进行签名验证，签名验证成功就表示证书中的公钥是 B的。
于是 A 就可以用 B 提供的公钥对消息加密后发送给 B。
B 收到密文后，用与之配对的私钥进行解密。
到了这一步，中间人攻击已经很难发生了，有三种手段

• 需要从A服务器中直接获取域名数字证书
• 得到A的域名管理，向CA申请证书
• 自己签发证书，然后要求B安装自己的证书
  对于第一，二个问题的防范，在服务器端，只要保护好私钥和服务器，域名的安全就可以了。
  对于第三个问题，在客户端不要随便安装不信任的证书。

至此，一套比较完善的数据传输方案就完成了。HTTPS（SSL/TLS）就是在这样一套流程基础之上建立起来的。