Posts

TLS 介绍 TLS (和 SSL) 协议位于应用程序协议层和 TCP/IP 层之间，可以在其中保护应用程序数据并将其发送到传输层。 由于协议在应用程序层和传输层之间工作，因此 TLS 和 SSL 可以支持多个应用程序层协议。 TLS 和 SSL 假定使用面向连接的传输（通常为 TCP）， 可以预防如下风险： 消息篡改 消息拦截 消息伪造 TLS 握手 介绍 TLS 整个握手流程如下图所示 客户端请求(clinet hello) 这个阶段主要发送信息如下： 客户端支持的 TLS 版本号 客户端随机数Random 客户端支持的加密方法 客户端支持的压缩算法 服务端响应（server hello） 服务端支持的 TLS 版本号 服务端随机数Random 服务端支持的加密方法 服务端支持的压缩算法 服务端证书发送 服务端发送 server hello 后会发送证书，通常他们俩者在同一个网络包中，即同一个 TLS 记录层消息中。 证书验证（可选） 客户端拿到服务端证书，到证书办法机构的服务器（OCSP responder）验证证书是否可用 Client Key exchange 在此阶段客户端也会生成一个随机数，加上 clinet hello, server hello 生成的随机数一共三个随机数 作为 pre-master，发送给服务器，服务器端收到pre-master算出main master。而客户端当然也能自己通过pre-master算出main master。如此以来双方就算出了对称密钥。 客户端 finished 一个 Finished 消息一直会在一个 change cipher spec 消息后立即发送，以证明密钥交换和认证过程是成功的。一个 change cipher spec 消息必须在其它握手消息和结束消息之间被接收。 ...

问题分析 近期系统出现了部分 IOS 进入 H5 页面很慢的情况，而 Android 进入却正常。 在排除调程序和网络的问题后，最终把问题定位到 SSL 证书上。要想了解整个问题所在，需要从 TLS 协议开始说起 TLS 握手流程如下图所示 问题就出在客户验证证书这里，这里验证证书是通过 在线证书状态协议（OCSP），进行验证的。OCSP 验证原理也比较简单，就是拿证书信息到证书颁发机构的 OCSP 服务器做校验。 由于我们使用的是国外机构颁发的证书，因此验证证书的服务器也在国外，由于国内网络环境受限的因素，验证服务器无法访问，从而导致整个网站的访问卡在了证书校验这一步，无法正常的完成 TLS 握手。 找到了原因解决的方法也就迎刃而解了，我们把站点证书换成了国内机构颁发的，成功的解决了问题。 问题验证 在苹果官网找到了如下说明，佐证了上述猜想 对 TLS 证书信任状态的评估依照既定的行业标准（如 RFC 5280 所列）执行，且整合了新出现的标准，如 RFC 6962（证书透明度）。在 iOS 11 或更高版本以及 macOS 10.13 或更高版本中，Apple 设备会随撤销及受限证书的当前列表来进行定期更新。该列表由 Apple 信任的每个内建根证书颁发机构及其从属的 CA 签发者所发布的证书撤销清单 (CRL) 聚合而成，列表还可能根据 Apple 的要求酌情包括其他限制。每当使用网络 API 函数进行安全连接时都会使用此信息。如果需要单独列出的 CA 撤销证书太多，信任评估可能需要在线证书状态响应 (OCSP)，否则将无法通过信任评估。 其他一些症状 症状1 IOS 有的进入速度很快，有的进入很慢 出现上述问题的原因是：验证服务器一般都是通过 CDN 分发的，有可能部分 IP 未被限制 症状2 IOS 进入慢的用户，更换网络环境可以更快的进入。 运营商的限制策略不同，导致更换网络提供商后有可能解决问题。 一些疑问 问题出现的时候 Android 并未收到影响，一直进入速度都很快，如果说验证证书的服务器出现问题，为什么 Android 不受影响呢？ ...

NGINX 和 PHP 是一对很好的搭档，那么 nginx 是如何与 php 结合实现 对外的网络访问呢？ 首先 NGINX 作为一个 web 服务器只能处理静态请求，关于动态请求，是通过 CGI 具备的动态请求能力。 NGINX会将动态请求交给 CGI 处理，CGI 将处理结果返回给 NGINX，NGINX 再将请求的结果返给给浏览器 CGI 的作用 当在浏览器中输入一个动态地址时，如 /index.php， 通过 DNS 解析，最终请求会到 web 服务器上，当 NGINX 发现请求时动态请求。会交给 PHP 解释器处理此请求，那再给 NGINX 需要给 PHP 解释器传输哪些数据呢？请求地址，请求方法，请求参数这些东西总归是要有的，但是也不能仅仅是这些，像请求头和 cookie … 也应该包含其中。 那么怎么确定到底该传输哪些数据，以及以什么样的格式传输呢？ CGI 就是解决这个问题而生的。 CGI 全程通用网关接口 (英语：Common Gateway Interface，CGI) 是为提供网络服务而执行控制台应用的程序，提供于服务器上实现动态网页的通用协议。通常情况下，一次请求对应一个CGI 脚本的执行，生成一个 HTML。 CGI 接口规定了 nginx 与动态解释器之前传输数据的参数和格式，为 nginx 和脚本解释器之间建立起了一个桥梁。 CGI 的存在使 web 服务器与动态语言之间的关系进行了解耦，使得 web 服务器可以处理的动态请求，但是 CGI 的设计使通过进程的方式来处理动态请求的，当动态请求过来后，CGI 会起一个进程进行处理，请求结束后关闭进程. ...

当一个新盘挂载的 linux 上，可以通过 fdisk -l 指令，查看挂载的磁盘信息，此时虽然已经挂载到主机上，但是主机还不能正常使用。 要想使用新磁盘，需要经过如下几步： 磁盘分区 磁盘格式化 挂载分区到某个目录 经过上面三部后，就可以使用上新的磁盘了，接下来讲解每一步具体应该如何操作 磁盘分区 $ fdisk -l #查看主机所有的磁盘列表 如上图可以看出 /dev/vda 是新的磁盘并且没有进行分区操作，接下来对 /dev/vda 磁盘进行分区操作 $ fdisk /dev/vda // 进入分区操作，这里要填写你的新磁盘信息，不一定和示例一致 $ m //查看帮助 上图为分区对应的各个操作 $ p #输入 p 查看分区列表 目前并没有划分分区，接下来进行第一个分区的划分 $ n #输入 n 划分分区 $ p # 输入 P 划分为主要分区 接下来需要填写编号（1-4之间）和 磁盘的开始扇区和结束山区 这里由于磁盘不大就没有进行过于细的划分，将所有磁盘容量全部划分到主分区1中 $ w # 输入 w 保存 到此磁盘的划分就已经全部完成，再次输入 fdisk -l 可以看到新划分的主分区 /dev/vda1 格式化磁盘 磁盘划分好后，继续要格式分区，这里使用 ext4 进行格式化 ...

所谓"公钥登录"，原理很简单，就是用户将自己的公钥储存在远程主机上。登录的时候，远程主机会向用户发送一段随机字符串，用户用自己的私钥加密后，再发回来。远程主机用事先储存的公钥进行解密，如果成功，就证明用户是可信的，直接允许登录shell，不再要求密码。 要实现公钥登陆的前提是需要用户端需要先生成公/私钥对，正常情况下都是有的，目录为：用户目录下的 .ssh 文件夹，私钥没有后缀，公钥后缀为 .pub。 如果没有公私密钥的话可以使用 ssh-keygen 进行生成. 复制代码 ssh-keygen -f test // -f 制定公司钥名称，回车进入下一步 Enter passphrase (empty for no passphrase): // 这里是密钥口令，如果担心私钥安全可以设置一下 Enter same passphrase again: // 确认密钥口令，回车后完成生成 服务器导入公钥 命令行导入 3ssh-copy-id -i ~/.ssh/test.pub user@host 手动导入 通过账号密码登陆服务器，将公钥复制到 ~/.ssh 目录下,执行下方命令: cat RemotePPK.pub >> authorized_keys xshell 使用公钥登陆演示 输入用户名 选择公钥登陆 导入密钥 选择导入好的密钥点 Ok 点击OK 完成登陆