渗透课程-标签属性、状态码与HTTPS加密原理

lizhi_xx

已于 2023-09-07 16:02:37 修改

阅读量1.4k

点赞数 21

文章标签： web安全网络安全

于 2023-09-07 16:00:08 首次发布

本文链接：https://blog.csdn.net/lizhiiiii/article/details/132737624

版权

问：https status code 502和504的区别？

标签属性

tabindex

网页通常使用鼠标操作，但是某些情况下，用户可能希望使用键盘，或者只有键盘可以用。因此，浏览器允许使用 Tab 键，遍历网页元素。也就是说，只要不停按下 Tab 键，网页的焦点就会从一个元素转移到另一个元素，选定焦点元素以后，就可以进行下一步操作，比如按下回车键访问某个链接，或者直接在某个输入框输入文字。

这里就有一个问题，按下 Tab 键的时候，浏览器怎么知道跳到哪一个元素。HTML 提供了tabindex属性，解决这个问题。它的名字的含义，就是 Tab 的顺序（index）。

encode

用于指定一个字符串的编码方式。

网页可以使用不同语言的编码方式，但是最常用的编码是 UTF-8。UTF-8 编码是 Unicode 字符集的一种表达方式。这个字符集的设计目标是包含世界上的所有字符，目前已经收入了十多万个字符。

每个字符有一个 Unicode 号码，称为码点（code point）。如果知道码点，就能查到这是什么字符。举例来说，英文字母a的码点是十进制的97（十六进制的61）。

不是每一个 Unicode 字符都能直接在 HTML 语言里面显示：

（1）不是每个 Unicode 字符都可以打印出来，有些没有可打印形式，比如换行符的码点是十进制的10（十六进制的A），就没有对应的字面形式。

（2）小于号（<）和大于号（>）用来定义 HTML 标签，其他需要用到这两个符号的场合，必须防止它们被解释成标签。

（3）由于 Unicode 字符太多，无法找到一种输入法，可以直接输入所有这些字符。换言之，没有一种键盘，有办法输入所有符号。

（4）网页不允许混合使用多种编码，如果使用 UTF-8 编码的同时，又想插入其他编码的字符，就会很困难。

HTML 为了解决上面这些问题，允许使用 Unicode 码点表示字符，浏览器会自动将码点转成对应的字符。

字符的码点表示法是&#N;（十进制，N代表码点）或者&#xN;（十六进制，N代表码点），比如，字符a可以写成a（十进制）或者a（十六进制），字符中可以写成中（十进制）或者中（十六进制），浏览器会自动转换。

*Get以地址栏的形式传参 post form表单形式传输

URL 字符转义的方法

在这些字符的十六进制 ASCII 码前面加上百分号（%）。下面是这18个字符及其转义形式。

!：%21
#：%23
$：%24
&：%26
'：%27
(：%28
)：%29
*：%2A
+：%2B
,：%2C
/：%2F
:：%3A
;：%3B
=：%3D
?：%3F
@：%40
[：%5B
]：%5D

不同状态码的差别

传输方式的改变

问：https status code 502和504的区别？

502 bad gateway 网关错误后端服务器tomcat没有起来，应用服务的问题（前提是接入层7层正常的情况下）。

应用服务问题一种是应用本身问题；另一种是因为依赖服务问题比如依赖服务RT高，依赖的服务有大的读取（mysql慢查，http等），以至于调用方超过超时read时间；服务集群压力大时，也会出现502超时（502理解为不可响应或响应不过来，其实还是不可响应）。

504 gateway time-out 顾名思义网关超时一般计算机中的超时就是配置错了，此处一般指nginx做反向代理服务器时，所连接的服务器tomcat无响应导致的。

从网络角度，502已经与后端建立了连接，但超时；504与后端连接未建立，超时。

DNS原理

HTTPS

RSA密钥协商握手过程

TLS

TLS第一次握手

客户端首先会发一个「Client Hello」消息，字面意思我们也能理解到，这是跟服务器「打招呼」。

消息里面有客户端使用的 TLS 版本号、支持的密码套件列表，支持的压缩算法，以及生成的随机数（*Client Random*），这个随机数会被服务端保留，它是生成对称加密密钥的材料之一。

TLS第二次握手

当服务端收到客户端的「Client Hello」消息后，会确认 TLS 版本号是否支持，和从密码套件列表中选择一个密码套件，还有选择压缩算法（安全性原因，一般不压缩），以及生成随机数（*Server Random*）。

接着，返回「Server Hello」消息，消息里面有服务器确认的 TLS 版本号，也给出了随机数（Server Random），然后从客户端的密码套件列表选择了一个合适的密码套件。

可以看到，服务端选择的密码套件是 “Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256”。

这个密码套件看起来真让人头晕，好一大串，但是其实它是有固定格式和规范的。基本的形式是「密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法」，一般 WITH 单词前面有两个单词，第一个单词是约定密钥交换的算法，第二个单词是约定证书的验证算法。

小总结

就前面这两个客户端和服务端相互「打招呼」的过程，客户端和服务端就已确认了 TLS 版本和使用的密码套件，而且你可能发现客户端和服务端都会各自生成一个随机数，并且还会把随机数传递给对方。

那这个随机数有啥用呢？其实这两个随机数是后续作为生成「会话密钥」的条件，所谓的会话密钥就是数据传输时，所使用的对称加密密钥。

然后，服务端为了证明自己的身份，会发送「Server Certificate」给客户端，这个消息里含有数字证书。

随后，服务端发了「Server Hello Done」消息，目的是告诉客户端，我已经把该给你的东西都给你了，本次打招呼完毕。

客户端验证证书

在这里刹个车，客户端拿到了服务端的数字证书后，要怎么校验该数字证书是真实有效的呢？

数字证书和 CA 机构

在说校验数字证书是否可信的过程前，我们先来看看数字证书是什么，一个数字证书通常包含了：

公钥；
持有者信息；
证书认证机构（CA）的信息；
CA 对这份文件的数字签名及使用的算法；
证书有效期；
还有一些其他额外信息；

那数字证书的作用，是用来认证公钥持有者的身份，以防止第三方进行冒充。说简单些，证书就是用来告诉客户端，该服务端是否是合法的，因为只有证书合法，才代表服务端身份是可信的。

数字证书签发和验证流程

TLS第三次握手

客户端验证完证书后，认为可信则继续往下走。接着，客户端就会生成一个新的随机数 (pre-master)，用服务器的 RSA 公钥加密该随机数，通过「Change Cipher Key Exchange」消息传给服务端。

服务端收到后，用 RSA 私钥解密，得到客户端发来的随机数 (pre-master)。

至此，客户端和服务端双方都共享了三个随机数，分别是 Client Random、Server Random、pre-master。

于是，双方根据已经得到的三个随机数，生成会话密钥（Master Secret），它是对称密钥，用于对后续的 HTTP 请求/响应的数据加解密。

生成完会话密钥后，然后客户端发一个「Change Cipher Spec」，告诉服务端开始使用加密方式发送消息。

然后，客户端再发一个「Encrypted Handshake Message（Finishd）」消息，把之前所有发送的数据做个摘要，再用会话密钥（master secret）加密一下，让服务器做个验证，验证加密通信是否可用和之前握手信息是否有被中途篡改过。

可以发现，「Change Cipher Spec」之前传输的 TLS 握手数据都是明文，之后都是对称密钥加密的密文。

TLS 第四次握手

服务器也是同样的操作，发「Change Cipher Spec」和「Encrypted Handshake Message」消息，如果双方都验证加密和解密没问题，那么握手正式完成。

最后，用「会话密钥」加解密 HTTP 请求和响应。

lizhi_xx

关注

21
点赞
踩
15

收藏

觉得还不错? 一键收藏
0
评论
渗透课程-标签属性、状态码与HTTPS加密原理

就前面这两个客户端和服务端相互「打招呼」的过程，客户端和服务端就已确认了 TLS 版本和使用的密码套件，而且你可能发现客户端和服务端都会各自生成一个随机数，并且还会把随机数传递给对方。那这个随机数有啥用呢？其实这两个随机数是后续作为生成「会话密钥」的条件，所谓的会话密钥就是数据传输时，所使用的对称加密密钥。然后，服务端为了证明自己的身份，会发送「」给客户端，这个消息里含有数字证书。随后，服务端发了「」消息，目的是告诉客户端，我已经把该给你的东西都给你了，本次打招呼完毕。
复制链接

扫一扫