渗透总结一
HTTPS的原理
HTTP的安全风险（明文传输的致命缺陷）
- 窃听风险：攻击者在网络链路（如公共WiFi）监听明文传输数据，导致获取账号密码、聊天记录、隐私信息。
- 篡改风险：中间人拦截HTTP数据包并修改内容（如插入恶意代码或广告），导致网页被挂马、下载文件植入病毒。
- 冒充风险：伪造服务器域名或IP，诱导用户访问钓鱼网站，导致银行卡信息被盗、钓鱼诈骗。
- 会话劫持风险：窃取Cookie或Session ID冒充用户身份，导致账号被恶意操作、资金被盗。
HTTPS的解决方案（TLS/SSL的核心机制）
1. 加密传输（解决窃听风险）
对称加密：使用会话密钥加密应用层数据。
非对称加密：握手阶段用非对称算法（如RSA/ECDHE）安全传递会话密钥。
效果：即使数据被截获，攻击者也无法解密（需破解密钥）。
2. 身份认证（解决冒充风险）
数字证书机制：
服务器向CA申请证书，证明域名所有权。
浏览器验证证书有效性（有效期、域名匹配、CA链可信）。
效果：浏览器显示锁图标，用户可确认访问的是真实网站
3. 数据完整性保护（解决篡改风险）
MAC（消息认证码）：对每条数据生成哈希摘要，接收方验证摘要匹配。
效果：若数据在传输中被修改，哈希校验失败，连接立即终止。
4. 安全密钥交换（前向保密）
ECDHE密钥协商：每次会话生成临时密钥，即使服务器私钥泄露，历史通信仍安全。
效果：满足金融级安全要求。
TLS的握手过程
Client Hello：
客户端发起连接，发送第一条消息
支持的TLS版本：如 TLS 1.2。
客户端随机数：一个由客户端生成的随机字节串，用于后续密钥生成。
支持的密码套件列表：客户端支持的所有加密算法组合（如
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256）。支持的压缩方法列表（通常为空或禁用）。
Server Hello：
服务器响应客户端。
包含：
选定的TLS版本：通常是双方支持的最高版本。
服务器随机数：一个由服务器生成的随机字节串，用于后续密钥生成。
选定的密码套件：从客户端提供的列表中，选择一个服务器也支持且认为最安全的套件。
选定的压缩方法（通常为
null）。
Server Certificate：
服务器发送其数字证书（通常是X.509证书）。该证书包含：
服务器的公钥。
服务器的域名等信息。
由受信任的证书颁发机构签名，证明该公钥确实属于该域名对应的服务器。
客户端会验证此证书：
检查证书是否在有效期内。
检查证书中的域名是否与访问的域名匹配。
根据本地信任的根CA列表，逐级验证证书链的签名是否有效可信。这一步是确认服务器身份的关键。
Server Key Exchange：
根据选定的密钥交换算法，服务器发送生成预主密钥所需的额外信息。
对于
ECDHE：服务器发送其椭圆曲线参数。
服务器发送其椭圆曲线公钥。
通常，这个消息会用服务器的私钥（对应证书中的公钥）进行签名，客户端用服务器证书中的公钥验证签名。
Server Hello Done：
服务器表示其握手消息已发送完毕。
Client Key Exchange：
客户端生成一个
pre_master_secret。根据选定的密钥交换算法处理：
对于
ECDHE：客户端使用服务器的椭圆曲线公钥和自身生成的椭圆曲线私钥，通过椭圆曲线Diffie-Hellman算法计算出一个共享密钥，这就是pre_master_secret。
客户端将生成
pre_master_secret所需的信息发送给服务器。
Change Cipher Spec：
客户端发送此简单协议消息，通知服务器：“从现在开始，我将使用我们刚刚协商好的加密套件和密钥来发送消息”。
这是一个独立的协议消息，不是握手消息的一部分。
Client Finished：
客户端发送第一条使用协商好的算法和密钥加密的消息。
包含一个特殊的
Finished消息。该消息是对到目前为止所有握手消息计算的一个哈希摘要（使用协商的PRF），并用会话密钥加密。
作用：验证握手过程是否被篡改（如果哈希对不上，说明中间有人修改了握手消息），并确认客户端拥有正确的密钥。
Change Cipher Spec：
服务器发送此消息，通知客户端：“我也已切换到加密模式”。
Server Finished：
服务器发送其
Finished消息（同样是对所有握手消息的哈希摘要，用会话密钥加密）。作用：验证握手完整性，确认服务器拥有正确的密钥。
注: 完整握手开销较大（尤其RSA证书验证）。TLS 提供了两种机制复用之前的会话参数，减少握手开销：
Session ID：
服务器在第一次完整握手的
Server Hello中发送一个唯一的Session ID。客户端在后续连接的
Client Hello中带上这个 ID。如果服务器缓存中有此 ID 对应的会话状态，则直接跳到
Change Cipher Spec和Finished消息，跳过证书交换和密钥协商。称为简化握手。
Session Tickets：
服务器在第一次完整握手结束时，将加密的会话状态（包含主密钥等信息）作为票据发送给客户端。
客户端在后续连接的
Client Hello的扩展中带上此票据。服务器解密票据，恢复会话状态，同样进入简化握手。优点是会话状态存储在客户端，减轻服务器缓存压力。
DNS解析传输过程
- linux下：nslookup和dig
- Windows下：nslookup
dns的解析流程：
1.用户输入域名 ：用户在浏览器输入域名，系统会检查本地缓存是否有该域名的解析结果。若有则直接返回IP地址，否则进入下一步。
2. 查询本地DNS服务器： 系统向本地DNS服务器发起查询请求。本地DNS服务器若有缓存记录则直接返回结果，否则进入递归查询流程。
3. 递归查询根域名服务器 ：本地DNS服务器向根域名服务器发起请求。根域名服务器不直接解析域名，而是返回负责顶级域的TLD服务器地址。
4. 查询顶级服务器： 本地DNS服务器根据根域名服务器的指引，向顶级服务器查询。顶级服务器返回负责该域名的权威DNS服务器地址。
5. 查询权威DNS服务器 本地DNS服务器向权威DNS服务器发起请求。权威服务器存储域名的具体解析记录，返回对应的IP地址。
6. 返回结果并缓存 本地DNS服务器将IP地址返回给用户端，同时缓存该记录。用户端也缓存结果，后续请求可直接使用。
7. 建立连接 浏览器获得IP地址后，与目标服务器建立TCP连接，开始传输数据。
附：linux下可以用dig来追踪dns每一步解析过程：
走本地缓存---->看host文件---->找到就解析
------------------------->找不到就走路由器
--->查询13台根域服务器（看后缀是哪个域名）
--->交给后缀的dns服务器
--->看到xxx.后缀 交给xxx.后缀的dns服务器
--->最终解析出ip--->将ip返回给服务器（一层一层）
--->下发给电脑--->把缓存记录在本地