Python 爬蟲進階必備 | JA3 指紋在爬蟲中的應用與定向突破

前言

?

之前發(fā)過ja3相關(guān)的文章可以作為初期了解：JS逆向之猿人學第十九題突破ja3指紋驗證?，再來看本篇文章，篇幅略長，如果趕時間的朋友，可以跳過接下來的理論概念介紹，可以直接從后面的【如何突破ja3】開始看

?

到底什么是ja3

簡介

?

git:https://github.com/salesforce/ja3

?

官方解釋：

JA3 是一種創(chuàng)建 SSL/TLS 客戶端指紋的方法，它應該易于在任何平臺上生成，并且可以輕松共享以用于威脅情報

?更權(quán)威的介紹文章：https://engineering.salesforce.com/tls-fingerprinting-with-ja3-and-ja3s-247362855967

?

濃縮一下大概意思就是：

JA3 是一種對傳輸層安全應用程序進行指紋識別的方法。它于 2017 年 6 月首次發(fā)布在 GitHub 上，是 Salesforce 研究人員 John Althouse、Jeff Atkinson 和 Josh Atkins 的作品。創(chuàng)建的 JA3 TLS/SSL 指紋可以在應用程序之間重疊，但仍然是一個很好的妥協(xié)指標 (IoC)。指紋識別是通過創(chuàng)建客戶端問候消息的 5 個十進制字段的哈希來實現(xiàn)的，該消息在 TLS/SSL 會話的初始階段發(fā)送。

?

這.....，2017年就有了，我是2021年才通過閱讀青南大佬的文章知道有這么個東西。

?

然后我猜，ja3名字的由來，是因為有3個研究人員，且他們的姓名縮寫都是ja

?

ja3的由來

?

其實，John Althouse 自己說過，官方解釋：

對這個 TLS 客戶端進行指紋識別的主要概念來自 Lee Brotherston 2015 年的研究（https://blog.squarelemon.com/tls-fingerprinting/）和他的 DerbyCon 演講（https://www.youtube.com/watch?v=XX0FRAy2Mec）。如果不是 Lee ，就不會有JA3的出現(xiàn)

?

?

ja3如何工作的

?

原文解釋的很好了，官方解釋：

TLS 及其前身 SSL 用于為常見應用程序和惡意軟件加密通信，以確保數(shù)據(jù)安全，因此可以隱藏在噪音中。要啟動 TLS 會話，客戶端將在 TCP 3 次握手之后發(fā)送 TLS 客戶端 Hello 數(shù)據(jù)包。此數(shù)據(jù)包及其生成方式取決于構(gòu)建客戶端應用程序時使用的包和方法。服務器如果接受 TLS 連接，將使用基于服務器端庫和配置以及 Client Hello 中的詳細信息制定的 TLS Server Hello 數(shù)據(jù)包進行響應。由于 TLS 協(xié)商以明文形式傳輸，因此可以使用 TLS Client Hello 數(shù)據(jù)包中的詳細信息來指紋和識別客戶端應用程序

?

更多更專業(yè)的，如果很感興趣，勞煩移步John Althouse發(fā)表的文章：

https://engineering.salesforce.com/open-sourcing-ja3-92c9e53c3c41

?

感覺看了上面的話，是不是有點似懂非懂的感覺，沒事，聽我慢慢說，來個圖吧，要來圖的話，先來個三次握手的吧，老圖了，相信各位朋友也都看煩了，我也看煩了，因為這圖都傳包漿了

?

?

詳細的三次握手流程解釋我就不說了，網(wǎng)上能查到的太多了，我就不獻丑解釋了，本篇文章的重點也不是它

?

那么按照ja開發(fā)者自述，是在三次握手之后，客戶端向服務端發(fā)起client hello包，這個包里帶了客戶端這邊的一些特征發(fā)給服務端，服務端拿來解析數(shù)據(jù)包，然后回發(fā)一個hello給客戶端，之后再進行ssl數(shù)據(jù)交互，下面這個圖，就是John Althouse自己畫的

?

?

?

?

怎么說？畫的很傳神很易懂對吧？

?

更多原文解釋，請看這里：https://engineering.salesforce.com/tls-fingerprinting-with-ja3-and-ja3s-247362855967

John Althouse有關(guān)ja3的ppt講義，上面的動圖就是ppt文件里的，費了老大勁搞到的：鏈接: https://pan.baidu.com/s/1pfQwRwg3tbOT2Y2nQZYoAA??提取碼: ptj6 （鏈接失效了可以聯(lián)系我）

?

?

識別原理

?

以下John Althouse的文章里的：

?

1.JA3 不是簡單地查看使用的證書，而是解析在 SSL 握手期間發(fā)送的 TLS 客戶端 hello 數(shù)據(jù)包中設(shè)置的多個字段。然后可以使用生成的指紋來識別、記錄、警報和/或阻止特定流量。

2.JA3 在 SSL 握手中查看客戶端 hello 數(shù)據(jù)包以收集 SSL 版本和支持的密碼列表。如果客戶端支持，它還將使用所有支持的 SSL 擴展、所有支持的橢圓曲線，最后是橢圓曲線點格式。這些字段以逗號分隔，多個值用短劃線分隔（例如，每個支持的密碼將在它們之間用短劃線列出）

?

3. JA3 方法用于收集 Client Hello 數(shù)據(jù)包中以下字段的字節(jié)的十進制值：版本、接受的密碼、擴展列表、橢圓曲線和橢圓曲線格式。然后按順序?qū)⑦@些值連接在一起，使用“,”分隔每個字段，使用“-”分隔每個字段中的每個值

?

其中第一條，也解釋了我前一篇請求時嘗試提交一個ssl證書為啥沒有用的，第二條，服務端會在3次握手之后，收到客戶端過來的hello包，然后解包，收集版本、接受的密碼、擴展列表、橢圓曲線和橢圓曲線格式，在這時候就可以拿著ja3指紋去比對，哪些是限制了，哪些沒有限制的，當確實有在限制名單里，就針對處理，當沒有在限制名單里也返回一個hello，接著再繼續(xù)ssl

?

?

ja3已收錄指紋/黑名單

?

• https://sslbl.abuse.ch/blacklist/sslblacklist.csv? 這個沒有更新了只有上百條

• https://github.com/salesforce/ja3/blob/master/lists/osx-nix-ja3.csv??這個不是很全，只有上百條

• https://ja3er.com/getAllUasJson??這個一直在更新，十幾萬條

• https://ja3er.com/getAllHashesJson? 同上，只是給定標注字段不同

?

我猜測，ja3er.com里的十幾萬ja3指紋，就是所有人訪問過該網(wǎng)站的客戶端（瀏覽器或者語言請求庫）的指紋，有一條算一條的收集

?

?

案例解釋

前面說了一堆理論概念，我們做開發(fā)的，如果只有概念沒有實操或者例子解釋是不夠的，所以，來個案例，還是猿人學19題，同時繼續(xù)祭出wireshark方便分析，先瀏覽器訪問網(wǎng)站，拿到ip，提示一下，你們可別拿著ip去干人網(wǎng)站哈，挺好的一個爬蟲練習平臺，否則后果自負

?

?

這邊wireshark顯示：

?

此時你會看到很多的數(shù)據(jù)數(shù)據(jù)包，過濾一下，直接在過濾器位置輸入ip.，就會有很多指令提示和歷史記錄

?

全部的命令是啥意思這里就不多說了，更多的可以百度，只介紹幾個這里會用到的命令：

?

ip.dst_host就是目標地址，這里你可以理解為就是訪問網(wǎng)站的服務端地址

ip.src_host就是源地址，這里你可以理解為就是你正在操作的電腦的ip，這個ip大多是局域網(wǎng)ip

ip.host 跟上面一樣，但是不會區(qū)分是src還是dst，只要有指定地址的都會過濾出來

?

?

給定過濾指令，回車，此時有可能你輸入過濾命令之后，看不到有任何數(shù)據(jù)包，小問題，可能你打開wireshark完了，沒抓到包，重新刷新下網(wǎng)頁就行了，此時就看到如下的數(shù)據(jù)：

?

?

注意看，最開始的6個數(shù)據(jù)包就是上面說的流程，前三個是三次握手，第四個開始到第6個就是ja3的hello數(shù)據(jù)包，個人感覺這段過程也很像三次握手，再后續(xù)的數(shù)據(jù)包就是實質(zhì)的ssl數(shù)據(jù)交互了，

?

?

有了這個，看看ja3指紋到底是啥樣的，雙擊這個client hello，然后服務端返回的sever hello就不看了，此時不需要看，忘掉它吧

?

?展開client hello：

?

?

?

滑到最后，就能看到ja3指紋了

?

?

然后，看JA3 Fullstring ：

771,43690-4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53,64250-0-23-65281-10-11-35-16-5-13-18-51-45-43-27-17513-51914-21,51914-29-23-24,0

對應：

TLSVersion,Ciphers,Extensions,EllipticCurves,EllipticCurvePointFormats

?

以【,】分割，第一個數(shù)，771，根據(jù)官方解釋，就是ssl/tls版本，也就是這個：

?

python終端跑一下，0x0303就是771，對上了：

?

?

?

后續(xù)的就不細說了，直接看

?

?ja3圖1

?

?

細心的你發(fā)現(xiàn)了，我截圖這里是沒有第四個數(shù)相關(guān)的套件，?但是ja自己的文章里是有第四個數(shù)EllipticCurves相關(guān)的：

?

?

其實不是沒有的，是現(xiàn)在第四個參數(shù)由EllipticCurves改成了supported_groups

?

ja3圖2

注：ja3圖1是公司電腦，ja3圖2是家里電腦，所以看著ja3字段有點不一樣，tls版本也不一樣

?

說到版本，糾正下我前一篇給的說明，ja3指紋不是一定在tls1.3上支持的，上面的截圖各位朋友應該也看得到，tls1.2也支持的，不過也確實是需要wireshark的最新版才能看到ja3指紋

有關(guān)第三個數(shù)Extensions擴展列表，感興趣的可以看看更詳細的解釋：https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml

實際的案例作為ja3概念解釋就到這里了。

?

如何突破ja3

?

終于到了大家都很感興趣的環(huán)節(jié)，怎么破它了。

完全突破tls，我知道的有兩種，一種是hello包hook改寫，一種是自編譯openssl重新改默認的指紋

?

python半突破

在上一篇的解決方案里，修改cipher里的加密算法即可，也就是TLSVersion,Ciphers,Extensions,EllipticCurves,EllipticCurvePointFormats里的【Ciphers】，

有關(guān)ciphers相關(guān)套接字的，可以看看openssl的官方解釋：https://www.openssl.org/docs/man1.1.1/man1/ciphers.html，，并且華為官網(wǎng)的waf介紹里也有不同tls版本對應的套接字：https://support.huaweicloud.com/bestpractice-waf/waf_06_0012.html

?

?

也就是說，我們要想改，可以直接復制上面的套件覆蓋下即可，例如：

?

urllib3.util.ssl_.DEFAULT_CIPHERS = 'EECDH+AESGCMEDH+AESGCM'

?

但是，相信對這個tls有過相關(guān)經(jīng)驗的大佬來說，其實在調(diào)試requests請求時，調(diào)試到這個http/client.py文件庫里時，就能看到，在開始connect 時 http版本直接寫死成了1.0，還有這個建立連接的tunnel_headers，代碼給了個空值

?

?

??

如果你再配上fiddler或者charles抓包看的時候，明顯能看到，在python發(fā)送實際請求前的CONNECT請求如下：

?

?

而瀏覽器的這個CONNECT請求是http1.1，且headers是有值的，如下：

?

?

所以，這很明顯的差異好嗎？是很容易被識別到的

?

而且根據(jù)我多方查閱，加上咨詢了各位大佬之后，python目前只能改Ciphers里面的算法套件，來生成非默認的ja3指紋，然后可以騙過檢測不是太高的反爬機制。

但是其他的Extensions,EllipticCurves,EllipticCurvePointFormats是沒法改的，原因是??python跟openssl沒有很直接的聯(lián)系，python發(fā)https請求最后還是借助openssl庫暴露出來的方法，也就是的ssl_.py里的方法create_urllib3_context，因為openssl庫對外提供的方法或者接口是沒辦法這么高度自定義的，Ciphers部分也最多能改改算法，都不能給個自己定義的算法進去的，而chrome可以訪問是因為chrome有自己的ssl，且chrome肯定是不會被禁止的（鬧呢，禁止了瀏覽器正常用戶怎么訪問？）

也就是說這是python自身的缺陷了？所以我之前測試時不管用requests，httpx，還是aiohttp都不行，因為這三個庫底層都借助了openssl庫發(fā)請求。

假如這種反爬手段滿天飛的時候，python層面還沒有成型的方案解決怎么辦？

?

WTF？python的業(yè)務方向中引以為傲的爬蟲居然有缺陷？而且這個問題非常致命啊，感覺被降維打擊了，傷心的是目前還沒法改變局面，你說焦慮不焦慮？

?

那有朋友估計會想問，“那為啥之前猿人學19題可以過？” ，那是因為19題檢測的不嚴，只要ja3指紋長度小于等于瀏覽器的指紋長度都可以過，但其實還有很多特征的可以檢測到的，來，看圖，還是上次的圖，看最后一個數(shù)有很大區(qū)別的，這個我在上一篇的結(jié)尾里也把這個問題拋出來了

?

?

這么明顯的特征，如果是一個實際的網(wǎng)站案例，你覺得他會放過你嗎？

所以目前python針對tls指紋的有兩個缺陷，第一個發(fā)起CONNECT請求時http1.0被寫死，headers為空（當然這個可以改源碼臨時解決），第二個指紋沒法完全自定義，有很多特征被識別

說到這里，有朋友可能不信，口說無憑，這次來個實際的案例，一個大佬給我的某網(wǎng)站

?

瀏覽器打開（抱歉，我必須馬賽克馬到位），正常訪問是這樣的

??

python代碼，這里我用之前介紹的簡寫形式了，只加這兩行，其他地方不用改就行的

?

?

?

?

運行時發(fā)現(xiàn)程序卡住且一直沒有響應的狀態(tài)，測試得知原因是這個網(wǎng)站強制驗證了http2.0的問題，requests暫不支持http2被該服務器識別一直不響應結(jié)果導致卡住。

?

那換成httpx，（有關(guān)httpx詳細的代碼如何突破ja3的，可以看我之前寫的這篇：python爬蟲- requests、httpx、aiohttp、scrapy突破ja3指紋識別?）

?

發(fā)現(xiàn)運行還是不行的。

?

?

怎么改都不成功的，這個就是實際例子說明了，這是python語言層面的問題啊，難道python真的有缺陷？

?

golang 之ja3transport庫突破ja3

?

之后在蔡老板朋友圈里，青南大佬評論中說了是可以替換ja3指紋的，我請教青南大佬之后，他給了我一個方案，用golang突破，原文鏈接：一日一技：Golang 如何突破 JA3?

核心就是，代碼里加了第三方庫，ja3transport，這個庫可以直接偽造ja3，刺不刺激？

?

一執(zhí)行，一看，就發(fā)現(xiàn)真的改變了ja3指紋，驚呆！激動！刺激！興奮！

?

大概的看了下ja3transport的介紹，它在發(fā)起請求的時候，會將請求的client hello數(shù)據(jù)包里的ja3指紋修改為我們自己的給定的，這樣就達到了修改 JA3指紋的目的，妙啊

?

ja3transport簡介

?

這個大佬給了一段解釋：

JA3 的問題在于它僅比基于用戶代理字符串的指紋識別客戶端好一點。到目前為止，用戶代理字符串比 TLS ClientHello 數(shù)據(jù)包更容易更改。JA3 簽名的參數(shù)仍由 TLS 客戶端控制，因此不能作為可信的信息來源。在 Jeff 和 John 的 ShmooCon 談話中，他們提到 JA3 不是靈丹妙藥。他們提出的顛覆 JA3 檢測的方法是使用操作系統(tǒng)的 HTTPS 客戶端繞過 TLS 客戶端特定的 JA3 簽名。我們提出了另一種通過制作與其他 TLS 客戶端（如瀏覽器）匹配的 ClientHello 數(shù)據(jù)包來破壞 JA3 檢測的方法

?

?

ja3transport突破原理

官方解釋：

要想顛覆JA3，需要修改5個JA3參數(shù)，可以在Refraction Networking的utls項目ClientHelloSpec提供的struct中修改。該包允許用戶構(gòu)建和執(zhí)行 ClientHello 握手。第一個參數(shù)，TLS 版本，可以用和成員修改。第二個參數(shù)，可用密碼套件，可以通過更新成員來更改。第三個參數(shù) TLS 擴展可以通過更新成員來更改。參數(shù)的一個問題是所有參數(shù)都必須遵循 TLSVersionMinTLSVersionMaxCipherSuitesExtensionsExtensionsTLSExtension界面。第四個和第五個參數(shù)，橢圓曲線和橢圓曲線點格式，分別是 TLS 擴展SupportedCurvesExtension和 的一部分SupportedPointsExtension

我們不是根據(jù) JA3 字符串創(chuàng)建客戶端，而是可以生成與 Web 瀏覽器等良性簽名匹配的 JA3 簽名。有一些預設(shè)允許 JA3 簽名匹配 Chrome 或 Firefox，甚至更多。我們僅限于屏蔽使用 Go 可用的相同擴展的應用程序。例如，如果 Chrome 使用 Go 不支持的擴展程序，我們無法屏蔽它。屏蔽密碼套件比較棘手，因為任何密碼套件都可以進行廣告，即使它沒有實現(xiàn)。如果執(zhí)行握手的服務器接受客戶端通告但實際上并不支持的密碼套件，則會出現(xiàn)問題。只要服務器接受實際支持的密碼套件，虛假宣傳比可用密碼套件多的密碼套件就不是問題

?

Go 的net/http庫有一個名為Transport. 傳輸結(jié)構(gòu)負責編寫如何將數(shù)據(jù)包發(fā)送到目標服務器。由于 JA3 的簽名是基于 ClientHello 數(shù)據(jù)包的，我們可以進行 TLS 握手，讓 Go 完成剩下的工作。該Transport對象是一個參數(shù)http.Client結(jié)構(gòu)其中大部分進入開發(fā)人員都很熟悉。通過生成Transport結(jié)構(gòu)體，我們的庫應該可以與任何現(xiàn)有的 Go 項目無縫協(xié)作

?

濃縮下梗概，意思就是在go構(gòu)建請求，三次握手之后，到實際要發(fā)起client hello包之前，ja3transport把數(shù)據(jù)包攔截了，即上面說的hello包hook的方法，然后把原來的ja3指紋修改成了自傳遞的ja3字段發(fā)出client hello，服務端就認了，然后就通過了。

?

太牛逼了，他不是直接修改的tls里的那五個數(shù)組套件，因為ja3transport作者自己也說了，要想突破ja3，他認為的方法和選擇的方法也是避開了直接改5個JA3參數(shù)，而是在5個JA3參數(shù)創(chuàng)建好之后進行攔截替換

?

那么也就是說，其實golang跟python比也并沒有在語言上占有很大優(yōu)勢，唯一就是golang多了這么一群人提前就研究并寫好了這個第三方庫，而python沒法解決只是還沒有人寫出能夠攔截數(shù)據(jù)包并替換ja3指紋的庫，也就是這個并不是python的缺陷啊。當然，如果你急于求得結(jié)果，我建議你還是學一下golang來解決問題。

?

?

更多的解釋請看原文：https://medium.com/cu-cyber/impersonating-ja3-fingerprints-b9f555880e42

?

?

ja3transport后續(xù)問題

?

作者也說了，如果你隨意地偽造ja3，假如服務端通過一些方式得知你客戶端訪問進程跟實際的ja3不匹配，那應該也會屏蔽你

我們能想到的最簡單的檢測改進是將 JA3 簽名與生成 TLS ClientHello 數(shù)據(jù)包的進程映像配對。如果有客戶端生成與 Firefox 匹配的 JA3 簽名，但該進程不是 Firefox，則可能會發(fā)生一些奇怪的事情

?

ja3transport缺陷

?

但是，用這個庫ja3transport執(zhí)行的剛才那個案例網(wǎng)站的時候發(fā)現(xiàn)報了如下錯，提示就是說這個服務器不支持版本304的協(xié)議

?

tls: server selected unsupported protocol version 304

?

?

一搜這個報錯，就看到有個大佬說是因為不支持http2.0導致的：

?

對啊，這個網(wǎng)站上面它強制http2了，那也就是說，ja3transport不支持http2.0，這就是他的缺陷啊

?

golang之CycleTLS庫http2.0+ja3指紋突破

?

那只要能解決http2這個問題，是不是就破了這個站呢？再看上面這個大佬發(fā)的日期：

?

?

?

7 May，那現(xiàn)在已經(jīng)過去這么久了，大膽猜測一下，是不是這個大佬已經(jīng)解決了呢？此時估計有朋友應該回想，“你這個人怎么這么不嚴謹，什么都靠猜嗎？上一篇解決猿人學19題刪一大片cipher加密算法解決問題也是猜的”

?

哈哈哈，是啊，因為我個人覺得，爬蟲跟前后端開發(fā)還是有點區(qū)別的，前后端開發(fā)，按照我的理解，講究的邏輯嚴密，事先考慮各個層面的問題，盡量少bug然后服務能夠長期穩(wěn)定運行，但是爬蟲的話，有時候沒思路的情況下真的是大膽猜測出來的，我現(xiàn)在的思維已經(jīng)轉(zhuǎn)向這個方面了，雖然以前也干過后端開發(fā)，但是思維已經(jīng)回不去了。

?

我開始嘗試了這個庫：git地址：https://github.com/Danny-Dasilva/CycleTLS，真的就是抱著試一試的心態(tài)，執(zhí)行，結(jié)果真的跟瀏覽器訪問一樣的，搞定，牛逼！

代碼就不貼了，git地址上有。

所以，也就是說，之前用的庫github.com/CUCyber/ja3transport，不夠適合當下場景 http2+ja3雙重驗證

這輩子沒想到搞了幾年爬蟲逆向開發(fā)會為了解決ja3問題去學golang

?

nodejs

?

還是用上面大佬Danny-Dasilva的CycleTLS庫即可，他也開發(fā)了node的庫：https://github.com/Danny-Dasilva/CycleTLS#example-cycletls-request-jsts

?

直接npm install cycletls，然后照著案例的代碼來就行了，可能對于大部分爬蟲開發(fā)來說，node相對golang來說會更熟悉一點的。

驗證python指紋

既然已經(jīng)可以隨意改了對吧，那我改成python默認的指紋訪問下這個網(wǎng)站看看呢？我下面只改了ja3指紋，看運行結(jié)果，果然是被拉黑了，哈哈哈哈

??

換接口驗證

?

為了驗證真的成功了，哈哈，該嚴謹?shù)牡胤酱_實得嚴謹一點，還是用的golang，我換了另一個接口地址執(zhí)行，確實有結(jié)果了。

?

用wireshark做最后的驗證

?

那邊go程序在執(zhí)行，還是這個被馬死的目標，這邊wireshark抓包看結(jié)果，是的，相信你也看出貓膩了，它居然發(fā)了兩次client hello包

??

而之前我們看到的，比如猿人學19題，內(nèi)部題22，29題的那個，實際只會發(fā)一次的，這里發(fā)兩次就很奇怪，然后，這兩次發(fā)出去的ja3指紋還不一樣：

?

哪里不一樣，以逗號作為分割，除了第一個數(shù)和最后一個數(shù)，其他的字段的開頭一個數(shù)組都不一樣（以【-】作為分割）

?

然后，此時此刻，我們先去ja3官網(wǎng)看看瀏覽器本來的指紋呢？

?

chrome訪問ja3官網(wǎng)返回得到的：
　　　　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-21,29-23-24,0

chrome訪問目標網(wǎng)站用wireshark抓包得到：

　　第一個：
　　　　771,43690-4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53,60138-0-23-65281-10-11-35-16-5-13-18-51-45-43-27-17513-51914-41,14906-29-23-24,0

　　第二個：
　　　　771,10794-4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53,14906-0-23-65281-10-11-35-16-5-13-18-51-45-43-27-17513-2570-21,60138-29-23-24,0

?

仔細對比之后，也就剛好多了標記的

?

去掉上面標記出來的，其實第一個和第二個是一樣的，僅僅是這個被我馬賽克馬死的平臺是這樣，我猜應該是這個平臺自己多加了一層握手流程，所以會有2個client hello，具體為啥有兩個不糾結(jié)了，我也不是該平臺的開發(fā)，也沒法得知具體原因，不重要了，能獲取數(shù)據(jù)就行了。

?

不過等等，突然有個疑問？為啥wireshark的ja3指紋，同一個golang腳本啊，就算兩個client hello，也應該是兩個一樣的ja3指紋啊，為了進一步分析，先用瀏覽器訪問ja3后，同時看看wireshark抓包的是啥，這？我該信哪個？怎么wireshark多了點其他的東西

?

?

這引出了一個新的問題，哪個才是對的

?

ja3到底存在嗎？?

?

按理來說，應該信ja3官方，因為這玩意兒就是別人搞出來的，那既然如此，是wireshark在搞事咯？（此時此刻突然想起了學生時代的一個數(shù)學邏輯題，假如你是偵探，現(xiàn)在有幾個嫌疑人，已知里面有個人說了謊，從幾個嫌疑人的供詞里找出真兇。。。扯遠了）

?

為了進一步確認這個問題，根據(jù)青南大佬給文章的方案，可以偽造ja3指紋，那此時此刻，試下吧，現(xiàn)在的邏輯就是，我用一個我已知的指紋去請求ja3，然后看看ja3官方的返回，再看wireshark的ja3指紋對比，如果wireshark里的ja3不全等于我們自定義的ja3，那就確認是wireshark在他喵的搞事了

?

首先澄清，沒作弊哈，我用的第一個，跟我瀏覽器里的ja3是不一樣的

??

這里我用的ja3transport庫了，因為ja3官網(wǎng)沒有強制HTTP2了，運行下面的代碼，發(fā)現(xiàn)返回的確實改變了的，且值正是我們給定的

?

再看wireshark這邊：

?

?

發(fā)現(xiàn)也是自定義的那個值，沒有奇怪的數(shù)組了

?

?

相信有朋友會問，這就奇怪了，為啥這里又一樣了？難道wireshark沒有騙我們？啊這。。。，不是吧，忘了嗎？ja3transport這個庫會在在三次握手后，即將發(fā)起client hello數(shù)據(jù)包時，攔截這個包，然后把自定義的ja3指紋替換原有的啊，這是ja3transport庫的原理，所以，這里wireshark能跟我們給定的ja3指紋對應上

那么，也就是說，wireshark有一套的自己的ja3指紋解析套件解析并顯示了，但是這個解析套件跟ja3官網(wǎng)是不一樣的，所以顯示不一樣。當然這是我經(jīng)過多次分析推理得出來的結(jié)論，查了wireshark的文檔，暫時沒找到相關(guān)的介紹和解釋，姑且這么理解吧，肯定信ja3官方不能信wireshark啊，畢竟這ja3是別人搞出來的。

?

而且仔細看下面這個圖，我鼠標放到ja3上面的時候，下面的進制數(shù)據(jù)并不會對應顯示

?

?

?

用微信好友chao的話，"所有真實的信息都有二進制的數(shù)據(jù)，而wireshark的ja3都沒有對應的二進制數(shù)據(jù)"

?

所以我跟chao討論之后，認為ja3其實并不存在（上一次這么醍醐灌頂還是讀到《三體》里的那句臺詞"物理學不存在"，不好意思又扯遠了。。。），或者說ja3并不是實質(zhì)性存在的字符，而是通過TLSVersion,Ciphers,Extensions,EllipticCurves,EllipticCurvePointFormats這五個tls組件根據(jù)自己的加密算法另類存在的，因為wireshark都能通過自己的解析邏輯解析顯示啊。以上推論僅代表個人觀點，有誤請指正

?

?

需要注意的點

1.有沒有發(fā)現(xiàn)，其實ja3在2017年就有了，據(jù)我了解，有很多公司的開發(fā)正在研究中。?

2.有了一個ja3，那我覺得后續(xù)肯定會出現(xiàn)升級版或者替代版了，紅藍對抗，反爬與反反爬，一直在對抗中進步，是好是壞，只能用時間來判定了。很多新東西靠自己一個人摸索是沒法走到更遠的，好比這個ja3，如果一開始沒有Lee Brotherston大佬在2015公開講解，也就不會有這么牛逼的ja3指紋出現(xiàn)了，很喜歡微信好友Regionover在一篇文章里的一句話：【故事要留給過去，但成長要用于分享】

3.另外，希望國內(nèi)外能有大神可以仿照這個ja3transport庫或者CycleTLS庫寫一個python的庫出來，唉，我自己也想寫出來啊，過去這么久了，我也在看原理，還得花時間研究啊。

?

后續(xù)怎么繼續(xù)學習tls指紋

1. 練習題：猿人學外部題19題，內(nèi)部題22，29，32題，32題是app版的tls指紋校驗，強的一批，網(wǎng)洛者練習平臺第9題（這個題正常的瀏覽器都會返回假數(shù)據(jù)，作者看了一會兒我的文章一晚上就搞了這道題出來，強的一批），只提示下，有幾頁假數(shù)據(jù)。?

2. 志遠大佬的最新課程里有tls指紋的，感興趣可以整一個。他的方法就是自編譯openssl

3. 感興趣可以讀下openssl源碼
   

之前說的tls指紋研究怎么樣了

說來慚愧，搞了這么久，也沒搞出個所以然來，我越去了解，就越覺得這個東西不是那么容易的，資料太少，全靠摸索，只能慢慢來了，因為我想實現(xiàn)的是完全自定義tls指紋，這個想法說實話，越來越覺得難實現(xiàn)了，不過一有空就在研究的。不僅研究突破tls，也在研究怎么利用它更好實現(xiàn)反爬，歡迎有興趣的朋友一起討論。

結(jié)語

1.真誠感謝一路下來認識的大佬們。以上都是個人見解，如果有誤還望指正，有任何問題，我很樂意跟各位大佬們交流，我微信id：geekbyte，備注來意

2.另外應有些朋友的建議建了個群，里面很多大佬，安全滲透，爬蟲，web+app逆向，前后端開發(fā)，ios開發(fā)的大佬都有，已滿200人，想進群的可以加我微信

3.推薦下蔡老板的星球，web逆向必須學的ast技術(shù)。他雖然不在爬蟲圈，但是在爬蟲圈一直有他的傳說，我能有今天，能認識這么多大佬，很大一部分原因是因為他。真的很感謝蔡老板。

?