做网站怎么让百度收录了,wordpress怎么填写横幅图片,连锁餐厅vi设计公司,没有证书编号目录
一、概念
1、HTTPS
2、加密解密
3、加密的必要性
4、常见的加密方式
4.1、对称加密
4.2、非对称加密
5、数据摘要 数据指纹
6、数字签名
二、HTTPS的工作过程
1、只使用对称加密
2、只使用非对称加密
3、双方都使用非对称加密
4、非对称加密 对…目录
一、概念
1、HTTPS
2、加密解密
3、加密的必要性
4、常见的加密方式
4.1、对称加密
4.2、非对称加密
5、数据摘要 数据指纹
6、数字签名
二、HTTPS的工作过程
1、只使用对称加密
2、只使用非对称加密
3、双方都使用非对称加密
4、非对称加密 对称加密
5、中间人攻击
6、证书
6.1、CA认证
6.2、理解数据签名
7、非对称加密 对称加密 证书认证
三、证书可靠性解释
1、中间人有没有可能篡改证书
2、中间人掉包整个证书
四、补充内容
1、为什么摘要内容在网络传输的时候一定要加密形成签名
2、为什么签名不直接加密⽽是要先hash形成摘要
3、常见的摘要算法
4、完整流程
五、总结 一、概念
1、HTTPS HTTPS也是⼀个应⽤层协议是在HTTP协议的基础上引⼊了⼀个加密层。直接使用HTTP协议进行传输可能会被第三方抓取数据并直接读取正文中的明文信息。 而使用HTTPS协议发送数据会在应用层先把数据传递给SSL/TLS进行加密操作完成后才继续向下传递给传输层。接收数据时也同样传输层要先把数据传递给SSL/TLS解密完成后再传递到应用层。
HTTPS的端口号是443。
2、加密解密
加密把 明⽂要传输的信息进⾏⼀系列变换⽣成 密⽂。 解密把 密⽂ 再进⾏⼀系列变换还原成 明⽂。 在这个加密和解密的过程中往往需要⼀个或者多个中间的数据辅助进⾏这个过程这样的数据称为 密钥 。
3、加密的必要性 因为http的内容是明⽂传输的明⽂数据会经过路由器、wifi热点、通信服务运营商、代理服务器等多个物理节点如果信息在传输过程中被劫持传输的内容就完全暴露了。劫持者还可以篡改传输的信息且不被双⽅察觉这就是 中间⼈攻击 所以我们才需要对信息进⾏加密。
4、常见的加密方式
4.1、对称加密 采⽤单钥密码系统的加密⽅法同⼀个密钥可以同时⽤作信息的加密和解密这种加密⽅法称为对称加密也称为单密钥加密特征加密和解密所⽤的密钥是相同的。 常⻅对称加密算法DES、3DES、AES、TDEA、Blowfish、RC2等。 特点算法公开、计算量⼩、加密速度快、加密效率⾼。
对称加密其实就是通过同⼀个 密钥 把明⽂加密成密⽂并且也能把密⽂解密成明⽂。
4.2、非对称加密 需要两个密钥来进⾏加密和解密这两个密钥是公开密钥public key简称公钥和私有密钥private key简称私钥。 常见非对称加密算法RSADSAECDSA 特点算法强度复杂、安全性依赖于算法与密钥。但是由于其算法复杂而使得加密解密速度没有对称加密解密的速度快。
5、数据摘要 数据指纹 数字指纹(数据摘要)其基本原理是利⽤单向散列函数(Hash函数)对信息进⾏运算⽣成⼀串固定⻓度的数字摘要。数字指纹并不是⼀种加密机制但可以⽤来判断数据有没有被窜改。 摘要常⻅算法有MD5、SHA1、SHA256、SHA512等算法把⽆限的映射成有限因此可能会有碰撞两个不同的信息算出的摘要相同但是概率⾮常低 摘要特征和加密算法的区别是摘要严格意义不是加密因为没有解密只不过从摘要很难反推原信息通常⽤来进⾏数据对⽐。
6、数字签名 摘要经过加密就得到数字签名。
二、HTTPS的工作过程 既然要保证数据安全就需要进⾏加密。⽹络传输中不再直接传输明⽂了⽽是加密之后的密文。加密的⽅式有很多但是整体可以分成两⼤类对称加密 和 非对称加密。
1、只使用对称加密 如果通信双方都各⾃持有同⼀个密钥X且没有别⼈知道这两⽅的通信安全当然是可以被保证的除非密钥被破解。 引⼊对称加密之后即使数据被截获由于⿊客不知道密钥是什么因此就⽆法进⾏解密也就不知道请求的真实内容是什么了。 但事情没这么简单服务器同⼀时刻其实是给很多客⼾端提供服务的。这么多客⼾端每个⼈⽤的秘钥都必须是不同的(如果是相同那密钥就太容易扩散了⿊客就也能拿到了)。因此服务器就需要维护每个客⼾端和每个密钥之间的关联关系这也是个很⿇烦的事情。 ⽐较理想的做法就是能在客⼾端和服务器建⽴连接的时候双⽅协商确定这次的密钥是什么。 但是如果直接把密钥明⽂传输那么⿊客也就能获得密钥了。此时后续的加密操作就形同虚设了。
所以只使用对称加密的方式是不可以的。
2、只使用非对称加密 鉴于非对称加密的机制如果服务器先把公钥以明文方式传输给浏览器之后浏览器向服务器传数据前都先⽤这个公钥加密好再传从客⼾端到服务器信道似乎是安全的(有安全问题)因为只有服务器有相应的私钥能解开公钥加密的数据。
但是服务器到浏览器的这条路怎么保障安全 如果服务器⽤它的私钥加密数据传给浏览器那么浏览器⽤公钥可以解密它而这个公钥是⼀开始通过明⽂传输给浏览器的若这个公钥被中间⼈劫持到了那他也能⽤该公钥解密服务器传来的信息了。
所以只使用非对称加密的方式是不可以的。
3、双方都使用非对称加密 服务端拥有公钥S与对应的私钥S客⼾端拥有公钥C与对应的私钥C。 客⼾和服务端交换公钥 客⼾端给服务端发信息先⽤S对数据加密再发送只能由服务器解密因为只有服务器有私钥S。 服务端给客⼾端发信息先⽤C对数据加密在发送只能由客⼾端解密因为只有客⼾端有私钥C。
这种方式看似可行但是效率太低了而且这种方式仍然有安全问题。
4、非对称加密 对称加密
先解决效率问题 服务端具有⾮对称公钥S和私钥S。 客⼾端发起https请求获取服务端公钥S。 客⼾端在本地⽣成对称密钥C通过公钥S加密发送给服务器。 由于中间的⽹络设备没有私钥即使截获了数据也⽆法还原出内部的原⽂也就⽆法获取到对称密钥(真的吗)。 服务器通过私钥S解密还原出客⼾端发送的对称密钥C。并且使⽤这个对称密钥加密给客⼾端返回的响应数据。 后续客⼾端和服务器的通信都只⽤对称加密即可。由于该密钥只有客⼾端和服务器两个主机知道其他主机/设备不知道密钥即使截获数据也没有意义。 由于对称加密的效率⽐非对称加密⾼很多因此只是在开始阶段协商密钥的时候使⽤非对称加密后续的传输仍然使⽤对称加密。 看似方案4已经很完善了但是仍然有安全问题。
5、中间人攻击
Man-in-the-MiddleAttack简称 “MITM攻击” 。 确实在⽅案4中客⼾端获取到公钥S之后对客⼾端形成的对称秘钥X⽤服务端给客⼾端的公钥S进⾏加密中间⼈即使窃取到了数据此时中间⼈确实⽆法解出客⼾端形成的密钥X因为只有服务器有私钥S。 但是中间⼈的攻击如果在最开始握⼿协商的时候就进⾏了那就不⼀定了假设hacker已经成功成为中间⼈。 服务器具有非对称加密算法的公钥S私钥S。 中间⼈具有⾮对称加密算法的公钥M私钥M。 客⼾端向服务器发起请求服务器明⽂传送公钥S给客⼾端。 中间⼈劫持数据报⽂提取公钥S并保存好然后将被劫持报⽂中的公钥S替换成为⾃⼰的公钥M并将伪造报⽂发给客⼾端。 客⼾端收到报⽂提取公钥M(⾃⼰当然不知道公钥被更换过了)⾃⼰形成对称秘钥X⽤公钥M加密X形成报⽂发送给服务器。 中间⼈劫持后直接⽤⾃⼰的私钥M进⾏解密得到通信秘钥X再⽤曾经保存的服务端公钥S加密后将报⽂推送给服务器。 服务器拿到报⽂⽤⾃⼰的私钥S解密得到通信秘钥X。 双⽅开始采⽤X进⾏对称加密进⾏通信。但是⼀切都在中间⼈的掌握中劫持数据进⾏窃听甚⾄修改都是可以的。 问题本质在于客⼾端⽆法确定收到的含有公钥的数据报⽂就是⽬标服务器发送过来的。
6、证书
6.1、CA认证 服务端在使⽤HTTPS前需要向CA机构申领⼀份数字证书数字证书⾥含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器浏览器从证书⾥获取公钥就⾏了证书就如⾝份证证明服务端公钥的权威性。 这个 证书 可以理解成是⼀个结构化的字符串⾥⾯包含了以下信息
证书发布机构证书有效期公钥证书所有者签名...... 需要注意的是申请证书的时候需要在特定平台⽣成查会同时⽣成⼀对⼉密钥对⼉即公钥和私钥。这对密钥对⼉就是⽤来在⽹络通信中进⾏明⽂加密以及数字签名的。 其中公钥会随着CSR⽂件⼀起发给CA进⾏权威认证私钥服务端⾃⼰保留⽤来后续进⾏通信其实主要就是⽤来交换对称秘钥。 可以使⽤在线⽣成CSR和私钥https://myssl.com/csr_create.html。 形成CSR之后后续就是向CA进⾏申请认证不过⼀般认证过程很繁琐⽹络各种提供证书申请的服务商⼀般真的需要直接找平台解决就⾏。
6.2、理解数据签名 签名的形成是基于非对称加密算法的注意目前暂时和https没有关系不要和https中的公钥私钥搞混了。 当服务端申请CA证书的时候CA机构会对该服务端进⾏审核并专⻔为该⽹站形成数字签名过程如下
CA机构拥有非对称加密的私钥A和公钥A。CA机构对服务端申请的证书明⽂数据进⾏hash形成数据摘要。然后对数据摘要⽤CA私钥A加密得到数字签名S。
细节说明
只能用CA的私钥形成签名CA私钥只有CA自己知道。所以只有CA能够完成签名的过程。因为CA是权威机构为了保证合法性一般OS和浏览器内部在出厂下载的时候就已经内置了CA的公钥。 服务端申请的证书明⽂和数字签名S共同组成了数字证书这样⼀份数字证书就可以颁发给服务端了。
7、非对称加密 对称加密 证书认证 在客⼾端和服务器刚⼀建⽴连接的时候服务器给客⼾端返回⼀个证书证书包含了之前服务端的公钥也包含了⽹站的⾝份信息。 客⼾端进⾏认证 当客⼾端获取到这个证书之后会对证书进⾏校验(防⽌证书是伪造的) 判定证书的有效期是否过期。 判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构)。 验证证书是否被篡改从系统中拿到该证书发布机构的公钥对签名解密得到⼀个 hash值(称为数据摘要)设为 hash1。然后计算整个证书的 hash 值设为 hash2。对⽐ hash1 和 hash2 是否相等。如果相等则说明证书是没有被篡改过的。
三、证书可靠性解释
1、中间人有没有可能篡改证书 中间⼈篡改了证书的明⽂。 由于他没有CA机构的私钥所以⽆法hash之后⽤私钥加密形成签名那么也就没法办法对篡改后的证书形成匹配的签名。 如果强⾏篡改客⼾端收到该证书后会发现明⽂和签名解密后的值不⼀致则说明证书已被篡改证书不可信从⽽终⽌向服务器传输信息防⽌信息泄露给中间⼈。
2、中间人掉包整个证书 因为中间⼈没有CA私钥所以⽆法制作假的证书。 所以中间⼈只能向CA申请真证书然后⽤⾃⼰申请的证书进⾏掉包。 这个确实能做到证书的整体掉包但是别忘记证书明⽂中包含了域名等服务端认证信息如果整体掉包客⼾端依旧能够识别出来。 永远记住中间⼈没有CA私钥所以对任何证书都⽆法进⾏合法修改包括⾃⼰的
四、补充内容
1、为什么摘要内容在网络传输的时候一定要加密形成签名
因为如果不加密就意味着CA放弃使用私钥那么证书就可以被中间人修改了。
2、为什么签名不直接加密⽽是要先hash形成摘要
为了缩⼩签名密⽂的⻓度加快数字签名的验证签名的运算速度。
3、常见的摘要算法
常⻅的摘要算法有MD5 和 SHA 系列。
以 MD5 为例我们不需要研究具体的计算签名的过程只需要了解 MD5 的特点 定⻓⽆论多⻓的字符串计算出来的 MD5 值都是固定⻓度 (16字节版本或者32字节版本)。 分散源字符串只要改变⼀点点最终得到的 MD5 值都会差别很⼤。 不可逆通过源字符串⽣成 MD5 很容易但是通过 MD5 还原成原串理论上是不可能的。
4、完整流程
左侧都是客⼾端做的事情右侧都是服务器做的事情 五、总结
HTTPS ⼯作过程中涉及到的密钥有三组 第⼀组(⾮对称加密)⽤于校验证书是否被篡改。服务器持有私钥(私钥在形成CSR⽂件与申请证书时获得)客⼾端持有公钥(操作系统包含了可信任的 CA 认证机构有哪些同时持有对应的公钥)。服务器在客⼾端请求是返回携带签名的证书。客⼾端通过这个公钥进⾏证书验证保证证书的合法性进⼀步保证证书中携带的服务端公钥权威性。 第⼆组(⾮对称加密)⽤于协商⽣成对称加密的密钥。客⼾端⽤收到的CA证书中的公钥(是可被信任的)给随机⽣成的对称加密的密钥加密传输给服务器服务器通过私钥解密获取到对称加密密钥。 第三组(对称加密)客⼾端和服务器后续传输的数据都通过这个对称密钥加密解密。
