tls-attacker/tls-scannerपेंटेस्टर और शोधकर्ताओं के लिए स्वचालित TLS सर्वर और क्लाइंट कॉन्फ़िगरेशन स्कैनर। सिफर सूट, प्रोटोकॉल संस्करण और सुरक्षा दिशानिर्देशों का मूल्यांकन करता है, अनुकूलन योग्य स्कैन गहराई और मशीन-पठनीय आउटपुट के साथ।
# TLS-Scanner
[](https://hydrogen.cloud.nds.rub.de/job/TLS-Scanner/)
TLS-Scanner एक उपकरण है जो पेंटेस्टर्स और सुरक्षा शोधकर्ताओं को TLS सर्वर और क्लाइंट कॉन्फ़िगरेशन के मूल्यांकन में सहायता करता है।
**कृपया ध्यान दें:** *TLS-Scanner एक शोध उपकरण है जो TLS डेवलपर्स, पेंटेस्टर्स, प्रशासकों और शोधकर्ताओं के लिए है। इसमें कोई GUI नहीं है। यह पहले संस्करण में है और इसमें कुछ बग हो सकते हैं।*
# कंपाइल करना
TLS-Scanner को कंपाइल और उपयोग करने के लिए, आपको यह चलाना होगा:
```bash
$ cd TLS-Scanner
$ git submodule update --init --recursive
$ mvn clean package
```
वैकल्पिक रूप से, यदि आप जल्दी में हैं, तो आप इसका उपयोग करके परीक्षणों को छोड़ सकते हैं:
```bash
$ mvn clean package -DskipTests=true
```
यदि आप TLS-Scanner को लाइब्रेरी के रूप में उपयोग करना चाहते हैं, तो आपको इसे निम्नलिखित कमांड से इंस्टॉल करना होगा:
```bash
$ mvn clean install
```
# चलाना
TLS-Scanner को चलाने के लिए आपको apps/ फ़ोल्डर में मौजूद jar फ़ाइलों में से एक को चलाना होगा।
ये आप स्वयं ऐप को कंपाइल करके या
[GitHub से जारी की गई jar फ़ाइलों को डाउनलोड करके](https://github.com/tls-attacker/TLS-Scanner/releases) प्राप्त कर सकते हैं।
```bash
$ java -jar apps/TLS-Server-Scanner.jar -connect localhost:4433
```
TLS-Scanner निर्दिष्ट सर्वर (यहाँ `localhost` पोर्ट `4433` पर) का मूल्यांकन करेगा, और अंत में एक रिपोर्ट प्रिंट करेगा।
रिपोर्ट निष्कर्षों की गंभीरता बताने के लिए रंगों का उपयोग करती है:
- हरा: एक अच्छा परिणाम।
- पीला: एक चेतावनी, जो एक संभावित समस्या हो सकती है।
- पीली पृष्ठभूमि: ऐसे परिणाम जहाँ स्कैनर अनिश्चित है कि लक्ष्य असुरक्षित है या नहीं।
- लाल: एक गंभीर समस्या, जिसे ठीक किया जाना चाहिए।
- डिफ़ॉल्ट रंग (आपके टर्मिनल के आधार पर, संभवतः काला या सफ़ेद): एक तटस्थ परिणाम, जो न अच्छा है न बुरा। इसमें सूचनात्मक परिणाम शामिल हैं।
- नीला: स्कैनर इस विशिष्ट परीक्षण के लिए सर्वर को स्कैन नहीं कर सका। यह संभवतः इस परीक्षण के लिए एक पूर्वापेक्षा के समर्थित न होने के कारण है।
- बैंगनी: इस विशिष्ट परीक्षण के लिए सर्वर को स्कैन करते समय स्कैनर को एक त्रुटि का सामना करना पड़ा। यह स्कैनर में एक बग का परिणाम हो सकता है, लेकिन सर्वर द्वारा आवश्यक सुविधा का समर्थन न करने के कारण भी हो सकता है।
- सियान: रिपोर्ट को संरचित करने के लिए उपयोग किया जाता है (शीर्षक, ...)।
## महत्वपूर्ण पैरामीटर
आपको -connect पैरामीटर के साथ एक होस्ट निर्दिष्ट करना होगा जिसे आप स्कैन करना चाहते हैं।
यदि आप स्कैन के प्रदर्शन को बेहतर बनाना चाहते हैं, तो आप उपयोग किए जाने वाले थ्रेड्स की संख्या बढ़ाने के लिए `-threads` पैरामीटर का उपयोग कर सकते हैं।
प्रदर्शन कारणों से एक और महत्वपूर्ण पैरामीटर `-scanDetail` पैरामीटर है, जिसका उपयोग यह कॉन्फ़िगर करने के लिए किया जा सकता है कि आप कितना विस्तृत स्कैन करना चाहते हैं। तेज़ से बहुत विस्तृत तक संभावित मान हैं: QUICK, NORMAL, DETAILED, ALL।
आउटपुट का विवरण `-reportDetail` पैरामीटर से कॉन्फ़िगर किया जा सकता है। Guidelines के बारे में अधिक विवरण देखने के लिए, `-reportDetail ALL` का उपयोग करें।
डिफ़ॉल्ट रूप से, परिणाम केवल कंसोल पर लिखे जाते हैं। यदि आप मशीन-पठनीय आउटपुट चाहते हैं, तो आप परिणामों को स्वचालित रूप से JSON फ़ाइल में लिखने के लिए `-outputFile output.json` का उपयोग कर सकते हैं।
## उपयोग के मामले
बदलने के लिए सबसे महत्वपूर्ण पैरामीटर `-scanDetail` और `-reportDetail` हैं। निम्नलिखित में, हम इन पैरामीटरों के लिए कुछ उपयोग के मामलों की व्याख्या करते हैं।
### डिफ़ॉल्ट स्कैन
अधिकांश मामलों के लिए, हमारी डिफ़ॉल्ट पैरामीटर सेटिंग्स पर्याप्त हैं। यह दोनों विवरण स्तरों को `NORMAL` पर सेट करके स्कैन करता है।
### तेज़ स्कैन
यदि आप एक तेज़ स्कैन करना चाहते हैं और अपने सिस्टम का त्वरित अवलोकन प्राप्त करना चाहते हैं, तो हम दोनों विवरण स्तरों को `QUICK` पर सेट करने की सलाह देते हैं। यह रनटाइम को कम करने के लिए कुछ निष्पादित प्रोब्स के विस्तार को सीमित करता है और रिपोर्ट विवरण को बहुत विस्तृत और तकनीकी जानकारी शामिल न करने तक सीमित करता है।
### विस्तृत स्कैन
यदि आप अपने सिस्टम का पूरी तरह से मूल्यांकन करना चाहते हैं और हमारे पास जो कुछ भी है उसे निष्पादित करना चाहते हैं, तो हम दोनों विवरण स्तरों को `ALL` पर सेट करने की सलाह देते हैं। यह सभी मौजूदा प्रोब्स को पूरी तरह से निष्पादित करता है और आगे के विश्लेषण और मूल्यांकन के लिए बहुत विस्तृत जानकारी प्रिंट करता है।
## स्कैन प्रोफ़ाइल
`-scanDetail` जैसे पैरामीटर को व्यक्तिगत रूप से सेट करने के बजाय (या उसके अतिरिक्त), आप
कौन से प्रोब्स चलाने हैं और इनमें से कौन से पैरामीटर उपयोग करने हैं, को `-profile <path/to/profile.json>` पैरामीटर के साथ
एक पुन: प्रयोज्य JSON स्कैन प्रोफ़ाइल में बंडल कर सकते हैं। यह `TlsServerScanner` और
`TlsClientScanner` दोनों पर उपलब्ध है।
एक प्रोफ़ाइल एक JSON फ़ाइल है जिसमें शामिल हैं:
- `inheritedFromProfiles`: अन्य प्रोफ़ाइलों के पथ जिनसे प्रोब्स को संयोजित करना है, उन्हें घोषित करने वाली प्रोफ़ाइल फ़ाइल की निर्देशिका के सापेक्ष हल किया जाता है (एक पूर्ण पथ जैसा है वैसा ही उपयोग किया जाता है)।
- `probes`: चलाने के लिए प्रोब्स, एक `ProbeType` enum क्लास के पूर्ण योग्य नाम से उसके चलाने के लिए कॉन्स्टेंट नामों की सूची तक एक मैप के रूप में। यह प्रत्येक एकल प्रोब के लिए प्रकार को दोहराने के बजाय प्रकार के अनुसार प्रोब्स को समूहित करता है, जबकि एक एकल प्रोफ़ाइल अभी भी विभिन्न `ProbeType` कार्यान्वयनों से प्रोब्स को स्वतंत्र रूप से संयोजित कर सकती है, जैसे `TlsProbeType` और `QuicProbeType`। प्रत्येक प्रति-प्रकार सूची `"*"` (उस प्रकार के सभी कॉन्स्टेंट) और `"!CONSTANT_NAME"` (नाम से या `"*"` द्वारा पहले जोड़े गए कॉन्स्टेंट को हटाना) भी स्वीकार करती है, क्रम में संसाधित — उदाहरणों के लिए [`scan-profiles/`](https://github.com/tls-attacker/tls-scanner/blob/main/scan-profiles) में `Everything.json` और `demo.json` देखें।
- `settings` (वैकल्पिक): `-scanDetail`, `-reportDetail`, `-postAnalysisDetail`, `-noColor`, `-outputFile`, `-probeTimeout`, `-parallelProbes`, और `-threads` जैसे पैरामीटरों के लिए ओवरराइड। छोड़ा गया कोई भी फ़ील्ड अपना सामान्य डिफ़ॉल्ट (या कमांड लाइन पर जो भी पास किया गया था) बनाए रखता है। **`probes` के विपरीत, `settings` विरासत में नहीं मिलते** — केवल उस प्रोफ़ाइल पर सीधे घोषित सेटिंग्स लागू होती हैं जिस पर आप `-profile` इंगित करते हैं, भले ही वह अन्य प्रोफ़ाइलों से प्रोब्स विरासत में लेती हो।
केवल सक्रिय प्रोफ़ाइल (और वह जो कुछ भी विरासत में लेती है) से हल किए गए प्रोब्स निष्पादित किए जाते हैं;
बाकी सब कुछ छोड़ दिया जाता है।
उदाहरण, एक बेस प्रोफ़ाइल के प्रोब्स को अपने स्वयं के प्रोब्स के साथ संयोजित करना और स्कैन विवरण को ट्यून करना:
`base.json`:
```json
{
"probes": {
"de.rub.nds.tlsscanner.core.constants.TlsProbeType": ["PROTOCOL_VERSION", "CIPHER_SUITE"]
}
}
```
`quic.json` (`base.json` के समान निर्देशिका में):
```json
{
"inheritedFromProfiles": ["base.json"],
"settings": {
"scanDetail": "QUICK"
},
"probes": {
"de.rub.nds.tlsscanner.core.constants.QuicProbeType": ["SUPPORTED_VERSIONS"]
}
}
```
```bash
$ java -jar apps/TLS-Server-Scanner.jar -connect localhost:4433 -profile quic.json
```
यह `-scanDetail QUICK` के साथ `PROTOCOL_VERSION`, `CIPHER_SUITE`, और `SUPPORTED_VERSIONS` चलाता है।
किसी स्कैनर के लिए उपलब्ध प्रत्येक प्रोब देखने के लिए (लक्ष्य से कनेक्ट किए बिना), `-listProbes` का उपयोग करें।
यह उन्हें `ProbeType` क्लास द्वारा समूहित करके ठीक उसी JSON सिंटैक्स में प्रिंट करता है जिसकी एक प्रोफ़ाइल के `probes` फ़ील्ड
को अपेक्षा होती है, ताकि आप इसे सीधे एक प्रोफ़ाइल में कॉपी-पेस्ट कर सकें:
```bash
$ java -jar apps/TLS-Server-Scanner.jar -listProbes
{
"de.rub.nds.tlsscanner.core.constants.TlsProbeType" : [ "ALPN", "ESNI", "CERTIFICATE", ... ],
"de.rub.nds.tlsscanner.core.constants.QuicProbeType" : [ "SUPPORTED_VERSIONS", ... ]
}
```
## सभी पैरामीटर
सभी संभावित पैरामीटरों के बारे में विस्तृत जानकारी प्राप्त करने के लिए, `-help` पैरामीटर का उपयोग करें या बिना कोई पैरामीटर सेट किए jar को निष्पादित करें।
# Docker
हम TLS-Server-Scanner के आसान उपयोग के लिए पूर्व-निर्मित docker इमेज प्रदान करते हैं।
```bash
$ docker run -it --network host ghcr.io/tls-attacker/tlsscanner -connect localhost:4433
```
यह इमेज सर्वर-स्कैनिंग के लिए उपयोग की जाने के लिए बनाई गई है लेकिन इसमें अन्य jar फ़ाइलें भी शामिल हैं।
इन्हें एंट्रीपॉइंट को बदलकर एक्सेस किया जा सकता है।
```bash
$ docker run -it --network host --entrypoint java ghcr.io/tls-attacker/tlsscanner -jar TLS-Client-Scanner.jar
```
हम आपको कंटेनर स्वयं बनाने के लिए एक Dockerfile भी प्रदान करते हैं:
```bash
$ docker build . -t tlsscanner
$ docker run -t tlsscanner
```
**कृपया ध्यान दें:** *मैं Docker की सर्वोत्तम प्रथाओं से किसी भी तरह परिचित नहीं हूँ। यदि आप जानते हैं कि Dockerfile को कैसे बेहतर बनाया जाए
तो बेझिझक एक pull request जारी करें*
# आवश्यकता प्रणाली
(TLS) प्रोब्स में कभी-कभी पूर्वापेक्षाएँ होती हैं जो इस विशिष्ट प्रोब को निष्पादित करने के लिए आवश्यक होती हैं। आवश्यकता प्रणाली आपको ऐसी आवश्यकताओं के सेट परिभाषित करने की अनुमति देती है जिन्हें प्रोब के निष्पादित होने के लिए पूरा किया जाना चाहिए।
प्रत्येक आवश्यकता एक `evaluate` फ़ंक्शन प्रदान करती है जो एक बूलियन मान लौटाती है जो दर्शाता है कि आवश्यकता पूरी हुई है या नहीं।
आवश्यकताओं को प्रसिद्ध तार्किक संक्रियाओं का उपयोग करके कई तरीकों से जोड़ा जा सकता है। प्रत्येक आवश्यकता कई आवश्यकताओं को श्रृंखलाबद्ध करने के लिए `and`, `or`, `not`, और `xor`
इंस्टेंस मेथड्स प्रदान करती है। निम्नलिखित प्रोब्स वर्तमान में कार्यान्वित हैं और तैयार उपयोग किए जा सकते हैं:
- `FulfilledRequirement` - हमेशा `true` का मूल्यांकन करता है, किसी आवश्यकता को इंगित न करने के लिए उपयोगी।
- `UnfulfillableRequirement` - हमेशा `false` का मूल्यांकन करता है, प्रोब्स के निष्पादन को रोकता है।
- `ProbeRequirement` - `true` का मूल्यांकन करता है यदि निर्दिष्ट प्रोब(्स) निष्पादित किया गया है।
- `PropertyRequirement` - `true` का मूल्यांकन करता है यदि निर्दिष्ट विश्लेषित प्रॉपर्टीज़ का एक पूर्वनिर्धारित मान है। मान या तो कंस्ट्रक्टर पैरामीटर के रूप में प्रदान किया जा सकता है या `TestResults.TRUE` और `TestResults.FALSE` के लिए शॉर्टहैंड के रूप में `PropertyTrueRequirement` और `PropertyFalseRequirement` का उपयोग किया जा सकता है।
- `PropertyComparatorRequirement` - `true` का मूल्यांकन करता है यदि एक विश्लेषित प्रॉपर्टी का संग्रह परिणाम एक स्थिर मान से छोटा, बराबर, या बड़ा है।
- `ProtocolRequirement` - `true` का मूल्यांकन करता है यदि कुछ प्रोटोकॉल संस्करण समर्थित हैं।
- `ExtensionRequirement` - `true` का मूल्यांकन करता है यदि रिमोट पीयर द्वारा कुछ एक्सटेंशन समर्थित हैं।
- `OptionsRequirement` - `true` का मूल्यांकन करता है यदि अतिरिक्त cli फ्लैग सेट हैं। वर्तमान में कुछ क्लाइंट प्रोब्स (ALPN, SNI, session resumption) में उपयोग किया जाता है।
- `WorkingConfigRequirement` - `true` का मूल्यांकन करता है यदि एक कार्यशील कॉन्फ़िगरेशन पाया गया है।
इन पूर्वनिर्धारित आवश्यकताओं के अलावा, कोई `getRequirements` मेथड के भीतर `Requirement` क्लास को अनाम रूप से विस्तारित भी कर सकता है। यदि कुछ भी आवश्यक नहीं है, तो आप एक `FulfilledRequirement` लौटा सकते हैं जो हमेशा true का मूल्यांकन करता है।
आवश्यकताओं का उपयोग कैसे करें इसके उदाहरण `tls-client-scanner` और `tls-server-scanner` के `probe` पैकेजों में पाए जा सकते हैं।
```java
@Override
public Requirement<ClientReport> getRequirements() {
return new ProbeRequirement<ClientReport>(TlsProbeType.CIPHER_SUITE)
.and(new PropertyTrueRequirement<>(TlsAnalyzedProperty.SUPPORTS_DHE));
}
```