本文章中所有内容仅供学习交流,抓包内容、敏感网址、数据接口均已做脱敏处理,严禁用于商业用途和非法用途,否则由此产生的一切后果均与作者无关,若有侵权,请联系我立即删除!
tls实际上前身就是 ssl,由于访问 https页面的时候,网络层建立连接过程中,涉及到了tl握手问题,
所以tls指纹就有可能被反爬手段所检测,目前有一些防火墙已经将此技术应用。
目前为止,tls指纹的检测手段依然停留在 将tls内容做哈希操作,由此检测黑名单的方案,而并非使用了白名单手段。
用下某网站做测试 且此网站也有有Ja3指纹加密的
aHR0cHM6Ly9nZ3p5LmppYW5neGkuZ292LmNuL3h3ZHQvMDAxMDAyL3NlYzEuaHRtbA==
!注意 fiddler要想抓Ja3-tls指纹 包
要把CONNECTS选项取消勾选,不然抓包指纹包
然后我们抓到了很多指纹包,然后我们挨个打开看看
然后我们看到很多的加密算法,还有加密方式
其实这种包其实本质上就是加入黑名单
已经tls的版本也有
相比较fiddler charles抓到的包就很有限了。
但是操作也更加的简单了
我们直接打开charles 然后刷新网站
这里直接就显示了tls的信息
我们接着点开详细信息 这里显示了tls的加密方式 已经加密的两种方式.
这两种抓包方式终究还是图一乐,真要抓包还得看wireshark
步骤如下
771,4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53,18-51-35-23-45-5-27-10-13-43-65281-11-16-17513-0-21,29-23-24,0
指纹信息分析其实很简单,
我们接下来用三种方式去获取这个指纹信息
也就是上文的771,4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53,18-51-35-23-45-5-27-10-13-43-65281-11-16-17513-0-21,29-23-24,0
这里我们选择直接用上文抓包抓到的指纹
还有一种方式
https://tls.browserleaks.com/json 直接去网站看自己的浏览器指纹也是可以的
由于上面已经获取了浏览器的指纹了,我们直接就拿来用了
771,4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53,18-51-35-23-45-5-27-10-13-43-65281-11-16-17513-0-21,29-23-24,0
接着我们使用requests原生库,即正常访问,携带基本的参数去请求即可
我们使用代码去访问下这个网站https://tls.browserleaks.com/json
import requests r = requests.get('https://tls.browserleaks.com/json', verify=True) print(r.text)
结果
{ "ja3_hash": "8d9f7747675e24454cd9b7ed35c58707", "ja3_text": "771,4866-4867-4865-49196-49200-49195-49199-52393-52392-159-158-52394-49327-49325-49326-49324-49188-49192-49187-49191-49162-49172-49161-49171-49315-49311-49314-49310-107-103-57-51-157-156-49313-49309-49312-49308-61-60-53-47-255,0-11-10-16-22-23-49-13-43-45-51-21,29-23-30-25-24,0-1-2", "ja3n_hash": "a790a1e311289ac1543f411f6ffceddf", "ja3n_text": "771,4866-4867-4865-49196-49200-49195-49199-52393-52392-159-158-52394-49327-49325-49326-49324-49188-49192-49187-49191-49162-49172-49161-49171-49315-49311-49314-49310-107-103-57-51-157-156-49313-49309-49312-49308-61-60-53-47-255,0-10-11-13-16-21-22-23-43-45-49-51,29-23-30-25-24,0-1-2", "akamai_hash": "", "akamai_text": "" }
所以这个指纹是
771,4866-4867-4865-49196-49200-49195-49199-52393-52392-159-158-52394-49327-49325-49326-49324-49188-49192-49187-49191-49162-49172-49161-49171-49315-49311-49314-49310-107-103-57-51-157-156-49313-49309-49312-49308-61-60-53-47-255,0-11-10-16-22-23-49-13-43-45-51-21,29-23-30-25-24,0-1-2
我们再试试 Python有关SSL的魔改库
其实这类库有很多
简单举例两个吧 一个是 curl_cffi
一个是 tls_client
我们这里使用curl_cffi 去访问一下看看这个指纹是什么
from curl_cffi import requests r = requests.get("https://tls.browserleaks.com/json", impersonate="chrome101") print(r.text)
结果
{ "ja3_hash": "cd08e31494f9531f560d64c695473da9", "ja3_text": "771,4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53,0-23-65281-10-11-35-16-5-13-18-51-45-43-27-17513-21,29-23-24,0", "ja3n_hash": "aa56c057ad164ec4fdcb7a5a283be9fc", "ja3n_text": "771,4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53,0-5-10-11-13-16-18-21-23-27-35-43-45-51-17513-65281,29-23-24,0", "akamai_hash": "4f04edce68a7ecbe689edce7bf5f23f3", "akamai_text": "1:65536;3:1000;4:6291456;6:262144|15663105|0|m,a,s,p" }
而这个指纹是
771,4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53,0-23-65281-10-11-35-16-5-13-18-51-45-43-27-17513-21,29-23-24,0
然后我们把这三个指纹拿出来做个对比
浏览器: 771,4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53,18-51-35-23-45-5-27-10-13-43-65281-11-16-17513-0-21,29-23-24,0 python原生库: 771,4866-4867-4865-49196-49200-49195-49199-52393-52392-159-158-52394-49327-49325-49326-49324-49188-49192-49187-49191-49162-49172-49161-49171-49315-49311-49314-49310-107-103-57-51-157-156-49313-49309-49312-49308-61-60-53-47-255,0-11-10-16-22-23-49-13-43-45-51-21,29-23-30-25-24,0-1-2 python魔改库: 771,4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53,0-23-65281-10-11-35-16-5-13-18-51-45-43-27-17513-21,29-23-24,0
可以清楚地看到 python的魔改库和浏览器的指纹是长度是一样的。
这样我们可以知道了,这个指纹长度只要和浏览器相同就可以了。
我们使用魔改库访问开头所要访问的网站实验一下
发现可以正常访问
那该如何不借助魔改库去完成Ja3网站的解密呢
可以通过修改ssl的套接字 使得防火墙黑名单失效
从而保证指纹长度一致 即可完成解密
**临时方案: **
注意 requests库必须在2.4 以上版本 不然会失败
requests.packages.urllib3.util.ssl_.DEFAULT_CIPHERS ='ALL'
修改了requests内部包的 ssI里面的套接字设置,使防火墙黑名单失效
动态 DEFAULT CIPHERS :
https://www.openssl.org/docs/man1.1.1/man1/openssl-ciphers.html
https://support.huaweicloud.com/bestpractice-waf/waf_06_0012.html
这种方法国内处理就已经够了
非临时方案:
自设ssl,并覆写requests中的类的一些方法
https://stackoverflow.com/questions/60407057/python-requests-being-fingerprinted
https://stackoverflow.com/questions/64967706/python-requests-https-code-403-without-but-code-200-when-using-burpsuite
深入理解requests中 建立 tls的过程
先抓包看下正常的访问 tls,和requests访问的区别
我们需要单步调试requests源码,并且想办法修改 tls访问过程中的UA
按照上面的思路,加上对 ssl的理解,就可以实现一个针对于 *ka**i tls检测的高并发方案