zblog认证https的简单介绍

本篇文章给大家谈谈zblog认证https，以及对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、https的认证过程
• 2、iOS中的HTTPS认证
• 3、zblogphp怎么设置https跳转到带www

https的认证过程

① 浏览器发送一个连接请求给安全服务器。

② 服务器将自己的证书，以及同证书相关的信息发送给客户浏览器。

③ 客户浏览器检查服务器送过来的证书是否是由自己信赖的 CA 中心所签发的。如果是，就继续执行协议；如果不是，客户浏览器就给客户一个警告消息：警告客户这个证书不是可以信赖的，询问客户是否需要继续。

④ 接着客户浏览器比较证书里的消息，例如域名和公钥，与服务器刚刚发送的相关消息是否一致，如果是一致的，客户浏览器认可这个服务器的合法身份。

⑤ 服务器要求客户发送客户自己的证书。收到后，服务器验证客户的证书，如果没有通过验证，拒绝连接；如果通过验证，服务器获得用户的公钥。

⑥ 客户浏览器告诉服务器自己所能够支持的通讯对称密码方案。

⑦ 服务器从客户发送过来的密码方案中，选择一种加密程度最高的密码方案，用客户的公钥加过密后通知浏览器。

⑧ 浏览器针对这个密码方案，选择一个通话密钥，接着用服务器的公钥加过密后发送给服务器。

⑨ 服务器接收到浏览器送过来的消息，用自己的私钥解密，获得通话密钥。

⑩ 服务器、浏览器接下来的通讯都是用对称密码方案，对称密钥是加过密的。

① 客户端的浏览器向服务器传送客户端SSL协议的版本号，加密算法的种类，产生的随机数，以及其他服务器和客户端之间通讯所需要的各种信息。

② 服务器向客户端传送SSL协议的版本号，加密算法的种类，随机数以及其他相关信息，同时服务器还将向客户端传送自己的证书。

③ 客户利用服务器传过来的信息验证服务器的合法性，服务器的合法性包括：证书是否过期，发行服务器证书的CA是否可靠，发行者证书的公钥能否正确解开服务器证书的"发行者的数字签名"， 服务器证书 上的域名是否和服务器的实际域名相匹配。如果合法性验证没有通过，通讯将断开;如果合法性验证通过，将继续进行第四步。

④ 用户端随机产生一个用于后面通讯的"对称密码"，然后用服务器的公钥(服务器的公钥从步骤②中的服务器的证书中获得)对其加密，然后将加密后的"预主密码"传给服务器。

⑤ 如果服务器要求客户的身份认证(在握手过程中为可选)，用户可以建立一个随机数然后对其进行数据签名，将这个含有签名的随机数和客户自己的证书以及加密过的"预主密码"一起传给服务器。

⑥ 如果服务器要求客户的身份认证，服务器必须检验客户证书和签名随机数的合法性，具体的合法性验证过程包括：客户的证书使用日期是否有效，为客户提供证书的CA是否可靠，发行CA 的公钥能否正确解开客户证书的发行CA的数字签名，检查客户的证书是否在证书废止列表(CRL)中。检验如果没有通过，通讯立刻中断;如果验证通过，服务器将用自己的私钥解开加密的"预主密码 "，然后执行一系列步骤来产生主通讯密码(客户端也将通过同样的方法产生相同的主通讯密码)。

⑦ 服务器和客户端用相同的主密码即"通话密码"，一个对称密钥用于SSL协议的安全数据通讯的加解密通讯。同时在SSL通讯过程中还要完成数据通讯的完整性，防止数据通讯中的任何变化。

⑧客户端向服务器端发出信息，指明后面的数据通讯将使用的步骤⑦中的主密码为对称密钥，同时通知服务器客户端的握手过程结束。

⑨ 服务器向客户端发出信息，指明后面的数据通讯将使用的步骤⑦中的主密码为对称密钥，同时通知客户端服务器端的握手过程结束。

⑩ SSL的握手部分结束，SSL安全通道的数据通讯开始，客户和服务器开始使用相同的对称密钥进行数据通讯，同时进行通讯完整性的检验。

① 浏览器发送请求给服务器，服务器首先返回证书；

② 浏览器比对服务器返回证书是否由信赖的CA中心签发，以及证书里的消息如：域名和公钥，通过后证明此服务器是安全的目标服务器，此时浏览器得到服务器的公钥；

③ 浏览器发送客户端证书给服务器进行验证，通过后建立连接，此时服务器获得客户端的公钥；

④ 客户端用各自的公钥、私钥发送对称秘钥，之后的通信就用对称秘钥进行加解密。（公钥和私钥为不对称秘钥，性能开销大于对称秘钥）

① 如双向认证前两步一样；

② 客户端用服务端公钥传送对称秘钥， 后续就用对称秘钥进行加解密再传送数据。

参考资料：

iOS中的HTTPS认证

iOS 中会话认证机制共有四种，大体分为两种类型：

枚举类如下：

说明：

HTTPS 通信中一般都是单向认证，这样可以保证数据的加密传输，也能够防止没有证书的钓鱼网站。而双向认证一般用于企业来禁止接口被第三方调用和解析。iOS 中的 NSURLSession 的默认实现、AFN 的默认实现都是单向认证，此时代理方法只会受到一种类型的回调，即： NSURLAuthenticationMethodServerTrust 。

双向认证建立在单向认证的基础上，需要自己去额外实现：

双向认证中代理方法会收到两个类型的回调：

与会话层面的认证机制相对的是特殊任务认证机制：

这些枚举的意义是？？？（见后文）

TLS （Transport Layer Security）就是 SSL（Secure Socket Layer），只不过版本不同而已：

SSL 和 HTTPS 的概念等不再赘述；

HTTPS 中的单向认证流程图如下：

其具体的流程为：

简化版流程图如下：

一般的 HTTPS 请求都采用单向认证，只有极少数对安全性要求很高的企业采用双向认证如金融企业，或者是企业对涉及到核心业务的接口采用双向认证；

单向认证中客户端认证服务端证书的特性就决定了，只要客户端愿意且服务端的证书正常，那么任意客户端都可以访问该服务器；

双向认证中，除了客户端对服务端进行认证，服务端还要对客户端进行认证。因此，服务端对客户端证书的认证逻辑就决定了客户端是被动的，能否访问该服务器完全由服务端决定。有的服务端只是单纯的对客户端证书进行 CA 认证，还有的会对证书的主体进行认证，非白名单内的主体不允许访问服务器；

NTLM 和 Kerberos 用于早期的 Windows 中，本文不做过多了解：

双向认证和白名单有这相同的作用，就是服务端限制某些客户端的访问，白名单机制的存在有这更方面成熟的实现机制，可能这就是双向认证不常用的原因？

是指使用某种算法计算出元数据的哈希值，以此确保元数据没有被篡改，最初的签名算法采用摘要算法，证书体系中的签名采用摘要算法+ 非对称加密的方式进行签名；

因为黑客可以修改元数据的同时修改摘要算法得出的哈希值，所以出现了证书，其目的是通过非对称加密来保证元数据的哈希值不被破解；

证书分为 TBSCertificate（To-Be-Signed） 和 Certificate，即待签名的证书和签名过的证书。TBSCertificate 证书中包含拥有者的各种信息，同时还包含拥有者的公钥。我们一般说的证书是经过签名的，这种证书中除了包含 TBSCertificate ，还会包含签名使用的算法、签名值；

非对称加密效率较低，所以证书的签名一般先对 TBSCertificate 使用摘要算法得到固定长度的哈希值，然后使用私钥对这个哈希值进行非对称加密，最终得到签名，所以证书体系中的签名已经不是单纯的摘要算法了；

最初的证书是自签名证书，拥有者使用自己的私钥对 TBSCertificate 进行签名，如果黑客攻击了证书发送者，并将证书上的公钥替换为自己的公钥，甚至直接将拥有者的私钥给窃取或者替换，那么接收者接收到的也是被篡改过的数据；

自签名证书中，私人的私钥安全性隐患很大，因此才有了权威的 CA 机构，证书体系中默认 CA 机构的安全性不会被破解，所以理论上 CA 的私钥不会被窃取。CA 机构会对个人信息进行验证，并且使用自己的私钥对 TBSCertificate 证书进行签名之后颁发给申请者；

CA 机构的私钥理论上绝对安全，公钥会被嵌入到计算机基础体系中，如被嵌入到操作系统、浏览器中，所以浏览器可以直接使用 CA 的公钥对证书进行验签；

验签的流程就是先提取签名时使用的签名算法（signatureAlgorithm），这里主要是要知道签名时摘要算法采用的哪一种。然后提取出 TBSCertificate，使用摘要算法对 TBSCertificate 进行哈希，得到 Hash1。接着，使用 CA 公钥对签名值（signatureValue）进行解密，得到 Hash2，如果 Hash1 = Hash2，则证书校验成功；

至此，CA + 非对称加密 + 摘要算法就组成了证书体系；

Root CA 基本上就那几个，他们的公钥会被嵌入到计算机基础体系中。如果直接使用 Root CA 的公钥进行签发，那么一旦 Root CA 的私钥发生变化，如撤销、过期等，牵连范围极大。

所以 intermediate CA 出现了， intermediate CA 作为 Root CA 的代理，先向 Root CA 申请证书，其流程和上面的基本一致， intermediate CA 将自己的信息和公钥发送给 Root CA ，Root CA 验证信息后颁发 TBSCertificate 并使用自己的私钥进行签名，最后颁发给 intermediate CA；

Root CA 只对 intermediate CA 颁发证书， intermediate CA 使用自己的私钥对申请者的证书进行签名，这样就实现了代理的作用；

一张图做总结：

首先，三个随机数的正常使用流程如下：

最终客户端和服务端都有三个随机数，然后根据三个随机数使用协议中的算法计算出一个 master_random，后续都使用 master_random 对报文进行对称加密之后传输；

这里有几个重点：

要回答这两个问题，这里就涉及到 HTTPS 中计算对称加密最终 key 的两种算法：

如果只是用一个随机数，这个随机数由客户端生成之后，使用 RSA 加密之后传送给服务端，服务端和客户端都是用这个随机数作为对称加密的 key 进行对称加密，这种情况有两个问题：

流程如下：

HTTPS 中的 RSA 加密，通过 premaster_random 这一个随机数来计算 master_random 的算法就是只使用一个随机数，并且使用 RSA 加密传输。

这种算法存在上述两个问题，因此，开发出了 DH 算法，现在 HTTPS 一般通过 DH 算法计算最后的 master_random；

很显然，除非中间人攻击，即便知道g、p，窃取到X1、X2，也很那倒推出来P1、P2，也就没法计算出最后密钥。

流程如下：

DH 算法原理：

如果不清楚上面的计算原理，只需要知道 DH 算法通过 3 个随机数来计算最终的 master_random 作为对称加密的 key，解决了伪随机数不一定随机的问题，还解决了 RSA 加密的向前攻击的问题；

为什么需要三个随机数，总结：

附-破解 HTTPS 的三种方法：

TCP报文格式：

序号：seq，用来标识从TCP源端向目的端发送的字节流。tcp中传输数据时，会把数据中的每个字节用序号进行标志，确保数据按顺序传输

确认号：ack，小写的。只有ACK标志位为1时，确认序号字段才有效，ack=Seq+1。确认方Ack=发起方Req+1，无论哪一端的确认号都是如此。比如A向B发送建立连接的请求时，seq=x，B回复的报文中 ACK 标志位为1，且确认号就是ack=x+1，表示收到了序列号为x的报文。

标志位：表示报文的六种格式，为1时才有效，默认为0；注意，ACK是标志位，而ack是确认号。

（A）URG：紧急指针（urgent pointer）有效。

（B）ACK：确认序号有效。

（C）PSH：接收方应该尽快将这个报文交给应用层。

（D）RST：重置连接。

（E）SYN：发起一个新连接。

（F）FIN：释放一个连接。

四次分手：

完整的通信流程：

总结：网络存在延迟、丢失的情况，两次握手会导致服务端开启多个无效连接，进而导致服务端在传送数据但是客户端并没有连接上的情况，而四次握手又多余了。

总结：客户端请求断开连接时，server有可能存在未发送完毕的数据，这种特性导致server将ACK和FIN报文分开发送，所以就会出现比三次握手时多一次的报文，三次握手时，server将ACK和SYN合并发送了；

结果：客户端和服务端的 master_random 是相同的，后面都使用这个数字作为对称加密的 key 来对数据进行对称加密之后进行传输；

ATS，即 App Transport Security，ATS 默认情况下要求 App 所有的请求都使用 HTTPS 连接，且对 HTTPS 认证中的摘要算法版本、对称算法版本等进行要求。Apple 利用自己的强势地位推动了客户端的安全性。

如果不额外在 info.plist 中设置 ATS，那么就相当于开启 ATS。

此时，所有的连接/请求都会被 ATS 机制拦截并使用 ATS 中默认的设置来进行连接的认证和建立，符合 ATS 要求的请求才能够通过，否则会被拒绝，ATS 默认策略的检测包括且不限于：

最常用的两个设置就是 NSAllowsArbitraryLoads 和 NSAllowsArbitraryLoadsInWebContent 。两者组合时，会根据版本的不同（是否大于 iOS10）而有不同的表现。鉴于现在的 iOS9 版本已经很少了，可以直接使用 iOS10 的版本，两个设置的优先级： NSAllowsArbitraryLoadsInWebContent NSAllowsArbitraryLoads 。即设置了前者之后，后者会被忽略；

如果需要完全关闭 ATS，需要设置 NSAllowsArbitraryLoads = YES ，并且在提交审核时进行说明。

对于浏览器类 App，如果只是允许浏览器中使用非安全的请求(HTTP)，那么只需要设置 NSAllowsArbitraryLoadsInWebContent = YES 即可。

另外，还可以使用 NSExceptionDomains 来设置允许 HTTP 请求的白名单域名，这种设置相对于直接关闭 ATS 更容易过审，使用如下：

可以直接使用该网站来检测所请求的域名是否符合 ATS 标准： ;port=443

如图：

综上，如果公司使用的证书是 CA 申请下来的，且服务器端支持的加密算法符合 ATS 的要求，那么无论是 NSURLSession 还是 AFNetworking，都是可以直接进行网络请求的，Apple 已经完成了 HTTPS 中客户端对服务器证书的验证操作，不需要开发者额外实现而且安全性能够得到保证。

所以，ATS 是 Apple 对客户端请求的安全标准和实现（封装）；

此种模式下，App 需要验证证书的签名，步骤如下：

使用签名校验的方式有一个缺点：

而公钥验证可以规避掉这个缺点，起流程如下：

我们在制作证书密钥时，公钥在证书的续期前后都可以保持不变（即密钥对不变），所以可以避免证书有效期问题；

如果采用证书锁定方式（Certificate Mode），则获取证书的摘要 hash，以 infinisign.com 为例：

所以其中的 wLgBEAGmLltnXbK6pzpvPMeOCTKZ0QwrWGem6DkNf6o= 就是我们将要进行证书锁定的指纹 (Hash) 信息。

如果采用公钥锁定方式（PublicKey Mode），则获取证书公钥的摘要hash，以 infinisign.com 为例

所以其中的 bAExy9pPp0EnzjAlYn1bsSEGvqYi1shl1OOshfH3XDA= 就是我们将要进行证书锁定的指纹 (Hash) 信息。

见文章： AFN中的鉴权

对于容器而言，这样做是合理的，因为浏览器可能会访问不安全的网站；

疑问：

参考：

zblogphp怎么设置https跳转到带www

1.根据IIS版本备份以下文件：IIS6.0路径：C:\WINDOWS\Help\iisHelp\common\403-4.htmIIS7.0以上路径：C:\inetpub\custerr\zh-CN\403.htm。2.把以下内容全部拷贝替换（403-4或403）里面所有内容，保存即可

关于zblog认证https和的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。