08.HTTPS

最新推荐文章于 2024-07-21 20:01:07 发布

Li.CQ

最新推荐文章于 2024-07-21 20:01:07 发布

阅读量178

点赞数

分类专栏：网络原理 # 小码哥文章标签： https

本文链接：https://blog.csdn.net/qq_27074387/article/details/119397780

版权

网络原理同时被 2 个专栏收录

9 篇文章 0 订阅

订阅专栏

小码哥

9 篇文章 0 订阅

订阅专栏

加密解密

私钥和公钥的加密解密
1. 加密可以保证传入过程没有被第三方式读取过
2. 签名可以保证传输过程没有被篡改
混合密码系统
证书

RSA数字签名算法

不使用证书, 直接通过私钥钥签名传输
这里如果文件被篡改过, 则文件的Hash值会改变, 那么通过公钥解密的Hash就和文件的Hash不同了.
如果不使用小明的公钥, 是无法解密通过小明的私钥签名的文件的.

2 .中间人冒充小明
1. 这时候如果有中间人冒充小明, 在网络上使用自己的私钥对文件签名, 然后将自己的公钥和签名+文件上传到网络上, 此时小红通过中间人的公钥解密中间的签名得到的Hash值和文件的Hahs值相同.
使用数字证书和CA防止中间人
1. 小明将自己的公钥 + 个人信息提交给CA机构
2. CA机构将小明的公钥 + 小明的个人信息组成一个文件, 通过对文件的Hash运算, 得到Hash值, 然后通过CA机构的私钥对Hash进行签名,将(小明的公钥 + 小明的个人信息) + 签名放在数字证书上. 然后将证书放在互联网上.
3. 每个电脑在装系统时候, 默认安装了根证书, 根证书里边记录了可以信赖的CA机构信息及其公钥. 根证书预先安装在系统中, 可以杜绝CA机构公钥被伪造的可能.
4. 小红通过CA机构的公钥, 获取到(小明的公钥 + 小明的个人信息)的Hash 和 (小明的公钥 + 小明的个人信息) 的Hash, 对比, 验证签名是否成立.
5. 通过证书验证后, 小红在通过证书中的公钥作解密等处理.

如果数据不使用HTTPS

通过对称加密传输数据
1. 服务端不可能给每个客户端分配一个k, 所以肯定是所有客户端共用一个key;
2. 中间人通过冒充客户端就可以获取到秘钥key.
3. 将客户端将要发送的数据通过 key解密, 然后修改, 在通过k加密, 发给服务端.
通过非对称加密传输数据
1. 中间人通过冒充客户端, 获取到公钥pubKey;
2. 用户通过中间人, 发送经过 pubKey加密的数据给服务端. 此时因为pubKey加密的数据只能通过privKey解密. 所以是安全的.
3. 服务端通过中间人, 发送经过 privKey 加密的数据给客户端. 此时因为中间人有pubKey, 是可以对数据进行解密的, 这时候, 服务端给客户端发送的数据是不安全的.
对称加密 + 非对称加密 (主要是公钥和传输过程中, 不安全. 同时无法验证身份)
1. 客户单每次连接向服务端索要 pubKey.
2. 然后由客户端生成随机数num, 然后通过 pubKey 对 num 加密, 然后传给服务端.
3. num秘钥 key对接下来传输的数据作对称加密.
4. 中间人冒充客户端欺骗服务器, 同时冒充服务端欺骗客户端. 此时中间人有自己的一对 pubKey1 和 privKey1.
5. 客户端连接服务器索要pubKey时候, 被中间欺骗, 返回了 pubKey1. 同时中间人冒充客户端向服务端索要pubKey.
6. 客户端通过 pubKey1 对num加密, 传给中间人, 中间人通过做自己的 privKey1 对 num解密, 获取到num. 然后通过pubKey对num加密, 将结果传给服务端.
7. 接下来所有通过num加密的数据, 都可以被中间人截取到, 然后中间人修改数据后重新加密传给客户端和服务端.
对称加密 + 非对称加密 + CA
1. 将服务端的公钥通过CA的私钥加密, 得到结果licence 给服务端.
2. 客户端向服务端索要licence.
3. 客户端通过系统中存储的公钥解密licence 获取 pubKey.
4. 接下来同3中的流程.

TLS证书

HTTP中的发送证书
1. HTTPS核心的一个部分是数据传输之前的握手，握手过程中确定了数据加密的密码。在握手过程中，网站会向浏览器发送SSL证书，SSL证书和我们日常用的身份证类似，是一个支持HTTPS网站的身份证明，SSL证书里面包含了网站的域名，证书有效期，证书的颁发机构以及用于加密传输密码的公钥等信息，由于私钥加密只能由公钥解密，因此浏览器在生成密码之前需要先核对当前访问的域名与证书上绑定的域名是否一致，同时还要对证书的颁发机构进行验证，如果验证失败浏览器会给出证书错误的提示。
访问网站的流程
1. 当用户访问一个网站时，浏览器会查看该网站的SSL证书，并很迅速地检查该SSL证书的真实性。除此以外，浏览器还会检查该SSL证书的有效期，证书与域名的匹配，并确认该证书没有被吊销，验证证书的数字签名。
根证书
1. 根证书（root certificate）是属于根证书颁发机构（CA）的公钥证书
  1. 公钥证书: 包含了公钥信息、拥有者身份信息（主体）、以及数字证书认证机构（发行者）对这份文件的数字签名，以保证这个文件的整体内容正确无误。
2. 根证书都是自签证书, 许多应用软件（例如操作系统、网页浏览器）会预先安装可被信任的根证书.
中间证书
1. 为了保护根证书，CA机构会颁发中级证书，使中级证书也受到信任。接着，CA机构使用中级证书颁发终端用户的服务器SSL证书

苹果开发者证书

证书
1. 是用来给应用程序签名的，只有经过签名的应用程序才能保证他的来源是可信任的，并且代码是完整的、未经修改的。才可以被手机安装. 证书的后缀为.cer. 通常包括(电脑公钥+企业信息) + Hash(电脑公钥+企业信息)通过苹果私钥的签名.
CSR文件
1. 在我们申请证书前，需要先申请一个CSR（即Certificate Signing Request）文件，此过程实际上是生成一对密钥（即公钥和私钥），这对密钥将保存在开发者Mac电脑的Keychain（即钥匙串访问）中，CSR文件中则包含公钥。
2. 所以可以将CSR文件发送给苹果. 因为CSR不包含私钥信息, 只包含公钥信息,
3. 所以申请下来的证书只有自己可以用, 如果需要给别人使用用, 需要生成p12文件. 因为私钥在我们自己的钥匙串中. 而私钥不可以给别人.
p12文件
1. 其本身就是一个加密的证书，后缀为.p12。开发者将CSR文件发给苹果服务器，由此苹果服务器会生成Certificate文件（含公钥），接着开发者将其下载到本地，再导入钥匙串中后，就可以从钥匙串中导出p12证书。显然，p12文件里面有匹配的公钥和私钥。
描述文件
1. 一个描述文件包含了App ID、Certificate、Device，其后缀为.mobileprovision
  1. 描述文件中还包含Entitlements（权限信息），权限信息指明了app使用的苹果服务，如iCloud权限、推送、苹果内购等。
  2. 描述文件中的签名是用苹果的私钥对 (Apple证书+iOS devices+appId+app权限文件entitlements) 的摘要算法的签名
2. 限制只有在苹果后台注册过的设备才可以安装
3. 限制签名只能针对某一个具体的App

iOS签名原理

在这里插入图片描述

苹果官方有一对密钥A(私钥在苹果后台，公钥在iOS系统中). 在Mac系统打包app时也会生成一对密钥M(保存在钥匙串中).

在向苹果服务器申请证书前，会先向钥匙串申请一个CSR文件，同时生成一对非对称加密密钥M，并将公钥M放在CSR中。然后把CSR文件发送给苹果服务器，用于申请证书。
苹果服务器用私钥A对收到的公钥M进行签名，生成Certificate文件（即证书，后缀名为.cer，里面有公钥M）。接着对Certificate、Devices、App ID以及Entitlements一起组成的数据用私钥A进行签名，生成Provisioning Profile（即描述文件），并将它发给开发者。
iOS项目在编译完成之后会生成.app文件，XCode先使用私钥M对.app进行签名，然后，把.app和描述文件一起压缩成安装包.ipa文件。
1. 对.app的签名是对资源文件的签名，生成的签名文件名为CodeResources，存放在.app目录下的_CodeSignature文件夹中。
2. 对.app的签名是对app的签名，其签名信息存放在Mach-O的Code Signature中.
iPhone对安装包进行验证，
1. 用公钥A验证描述文件中的签名解密然后对描述文件中的(Apple证书+iOS devices+appId+app权限文件entitlements)做摘要算法作对比. 验证通过则说明描述文件里的数据是苹果授权的.
然后用公钥A验证证书中的签名。验证通过则说明描述文件中的公钥M是安全可信任的
1. 用公钥A验证证书中的签名解密然后对证书中的(公钥M+企业信息)做摘要算法作对比. 验证通过, 则表示公钥M可信.
然后以取出描述文件里的数据做各种验证，包括用公钥M验证App签名，验证iPhone是否在设备列表中，App ID是否对得上，使用的权限是否跟Entitlements对应等。当这些全部验证通过，iPhone就可以安装app了。