डेबियन एप टूल के लिए कोई https ट्रांसपोर्ट क्यों नहीं है?

45

एनएसए खुलासे और सब कुछ के साथ आया है कि सभी व्यामोह के साथ, मैं सोच रहा हूँ कि क्यों डेबियन पैकेज स्थापना तंत्र अपने परिवहन के लिए HTTPS का समर्थन नहीं करता है, अकेले डिफ़ॉल्ट रूप से इसका उपयोग करते हैं।

मुझे पता है कि डेबियन पैकेज में GPG का उपयोग करके कुछ प्रकार के हस्ताक्षर सत्यापन हैं, लेकिन फिर भी मुझे नहीं लगता कि HTTP के बजाय HTTPS परिवहन का उपयोग करना बहुत कठिन होगा, यह देखते हुए कि यह सुरक्षा के लिहाज से कितना महत्वपूर्ण है।

संपादित करें: मैं ज्यादातर खुद को मित्म हमलों (सिर्फ ट्रैफ़िक सूँघने सहित) से बचाने के लिए चाहता हूं, डेबियन मिरर प्रशासक नहीं। HTTP रिपॉजिटरी में पूरे सिस्टम सेटअप को टेबल पर रखा जाता है, अगर कोई मेरे ट्रैफ़िक पर स्नोबॉप करता है तो डेबियन मिरर में जाता है।

— zaadeh
स्रोत

2

सूचना सुरक्षा पर अनिवार्य रूप से एक ही सवाल : HTTPS पर आवेदन डाउनलोड नियमित रूप से क्यों नहीं किए जाते हैं?

— गिल्स एसओ- बुराई को रोकें '

जरूरत नहीं है ... यह सार्वजनिक सामग्री है ... संकुल ने चेकसम पर हस्ताक्षर किए हैं

— स्केपरन

ठीक है इसलिए आप अपने नेटवर्क व्यवस्थापक को यह नहीं बताना चाहते हैं कि आप कौन से पैकेज स्थापित / अपग्रेड करते हैं।

— स्कैपरन

प्रवेश, या किसी भी अन्य eavesdropper।

— zaadeh

49

वहाँ है। आपको पैकेज स्थापित करने की आवश्यकता है apt-transport-https। फिर आप लाइनों का उपयोग कर सकते हैं

 deb https://some.server.com/debian stable main

आपकी sources.listफ़ाइल में। लेकिन आमतौर पर यह आवश्यक नहीं है, क्योंकि पूरी सामग्री वैसे भी सार्वजनिक है और यह एन्क्रिप्शन ओवरहेड और विलंबता जोड़ता है। चूँकि आप हमलावरों को सार्वजनिक कुंजी पर भरोसा नहीं करते हैं, यहां तक कि http ट्रैफ़िक भी मिटीएम हमलों से सुरक्षित है। aptआपको चेतावनी देगा और जब हमलावर किसी हेरफेर किए गए पैकेज को इंजेक्ट करता है तो पैकेज को स्थापित करने में विफल रहता है।

संपादित करें: जैसा कि टिप्पणियों में बताया गया है कि यह टीएलएस भंडार का उपयोग करने के लिए वास्तव में अधिक सुरक्षित है। अनुसंधान से पता चलता है कि अनएन्क्रिप्टेड रिपॉजिटरी पर एप्ट का उपयोग वास्तव में सुरक्षा जोखिम पैदा कर सकता है क्योंकि HTTP ट्रांसपोर्ट पुनरावृत्त हमलों के लिए असुरक्षित है।

— मार्को
स्रोत

7

नहीं, अधिकांश दर्पण https का समर्थन नहीं करते हैं। केवल इसलिए कि इस तरह के ट्रैफ़िक को एन्क्रिप्ट करने के लिए बहुत अर्थ नहीं है। पैकेजों को वैसे भी सत्यापित किया जा रहा है और जानकारी सार्वजनिक है।

— मार्को

4

मैं उन दो कारणों के बारे में सोच सकता हूं जिन्हें मैं अभी भी टीएलएस पर डाउनलोड करना पसंद कर सकता हूं: 1) मैं पैकेज स्थापित करते समय अपनी गोपनीयता की परवाह कर सकता हूं, और 2) पैकेज सिग्नेचर चेकिंग कोड में बग हो सकते हैं, जिसका एक एमआईटीएम शोषण कर सकता है।

— जैक ओ'कॉनर

2

@ JackO'Connor, जबकि गोपनीयता के बारे में पहली आपत्ति समझ में आती है, दूसरा यह कहने जैसा है कि मुझे पीजीपी कुंजी के साथ अपनी सामग्री पर हस्ताक्षर करने के लिए वेबसाइटें पसंद हैं क्योंकि टीएलएस कोड में कीड़े हो सकते हैं। PGP और TLS दोनों ही विश्वास स्थापित करते हैं; उसके लिए आपको दोनों की आवश्यकता नहीं है।

— पॉल ड्रेपर

7

@ मार्को आपका उत्तर गलत है; कई शोध पत्रों ने APT और YUM रिपॉजिटरी दोनों को दिखाया है कि जब GPG हस्ताक्षर के साथ भी HTTP के माध्यम से रिपॉजिटरी को एक्सेस किया जाता है, तो वे रिप्ले हमलों के प्रति संवेदनशील होते हैं। भंडार को केवल टीएलएस के माध्यम से एक्सेस किया जाना चाहिए, समय का 100%।

— जो डेमैटो

6

यहाँ पेपर @Joe Damato संदर्भित है - उसका उत्तर भी यहाँ

— SauceCode

17

आपकी धारणा गलत है: आप HTTPS डाउनलोड का उपयोग कर सकते हैं। आपको बस एक दर्पण ढूंढना है जो इसका समर्थन करता है, और अपने स्रोतों की सूची में इसका URL डालें। आपको apt-transport-httpsपैकेज स्थापित करना होगा ।

डेबियन HTTPS डाउनलोड को आसान नहीं बनाता है क्योंकि इसमें बहुत कम लाभ होता है। डेबियन पैकेज वितरण में पहले से ही पैकेजों को सत्यापित करने के लिए एक तंत्र शामिल है: सभी पैकेज Gpg के साथ हस्ताक्षरित हैं । यदि एक सक्रिय मानव-मध्य आपके सर्वर को दूषित पैकेज वाले सर्वर पर पुनर्निर्देशित करता है, तो भ्रष्टाचार का पता लगाया जाएगा क्योंकि GPG हस्ताक्षर मान्य नहीं होंगे। HTTPS के बजाय GPG का उपयोग करने से यह फायदा होता है कि यह अधिक खतरों से बचाता है: न केवल एंड-यूज़र कनेक्शन पर सक्रिय मानव-मध्य के खिलाफ, बल्कि एक दुष्ट या संक्रमित दर्पण या पैकेज वितरण श्रृंखला में कहीं भी अन्य समस्याओं के खिलाफ भी ।

HTTPS एक मामूली गोपनीयता लाभ प्रदान करता है जिसमें यह आपके द्वारा डाउनलोड किए गए पैकेजों को अस्पष्ट करता है। हालाँकि, एक निष्क्रिय पर्यवेक्षक अभी भी आपके कंप्यूटर और पैकेज सर्वर के बीच ट्रैफ़िक का पता लगा सकता है, इसलिए उन्हें पता होगा कि आप डेबियन पैकेज डाउनलोड कर रहे हैं। वे यह भी अच्छी तरह जान सकते हैं कि आप किन फ़ाइल आकारों से डाउनलोड कर रहे हैं।

एक स्थान जहां HTTPS मदद करेगा ट्रस्ट बूटस्ट्रैपिंग के लिए है, एक ज्ञात-मान्य स्थापना छवि प्राप्त करने के लिए। डेबियन प्रदान करने के लिए प्रतीत नहीं होता है: स्थापना मीडिया के चेकसम हैं , लेकिन केवल HTTP पर।

— गिल्स 'SO- बुराई होना बंद करो'
स्रोत

स्थापना मीडिया का HTTPS संस्करण है: cdimage.debian.org/debian-cd

— Fedir RYKHTIK

2

बहुत कम फायदा? Justi.cz/security/2019/01/22/apt-rce.html के बारे में क्या ?

— एरोन फ्रेंके

@AaronFranke एचटीटीपीएस की तुलना में HTTP के साथ दोहन करने के लिए आसान एक विशिष्ट बग बहुत कम लाभ गिनाता है, हाँ। ऐसा नहीं है कि एचटीटीपीएस की तुलना में एचटीटीपी की एक बड़ी हमले की सतह है: वास्तव में एचटीटीपीएस में एक बड़ी हमले की सतह है क्योंकि इसमें अधिक कोड शामिल हैं। तो यह बिल्कुल भी शुद्ध लाभ नहीं है: यह दो सीमांत जोखिमों के बीच एक व्यापार बंद है।

— गिल्स एसओ- बुराई को रोकें '23

9

अभी हाल ही में मैं अपनी कंपनी के उपयुक्त भंडार के साथ इस मुद्दे पर आया था। समस्या यह थी कि यदि हम मानक http परिवहन का उपयोग करते हैं तो किसी और को आसानी से पैकेज मिल सकता है। जैसा कि कंपनी अपने स्वयं के मालिकाना सॉफ्टवेयर की पैकेजिंग कर रही है और इसे हर किसी के साथ साझा नहीं करना चाहती है, http ट्रांसपोर्ट एक समस्या बन जाती है। एक त्रासदी नहीं, बल्कि एक समस्या है। पैकेज तक पहुंच को सीमित करने के कुछ तरीके हैं - फ़ायरवॉलिंग, वेब-सर्वर स्तर पर पहुंच को प्रतिबंधित करना, परिवहन के रूप में ssh का उपयोग करना। इस विषय पर पढ़ने के लिए काफी आसान यहां पाया जा सकता है: आपके निजी डेबियन रिपॉजिटरी तक पहुंच को प्रतिबंधित करना

हमारे मामले में, हमने https परिवहन + ग्राहक प्रमाणपत्र प्रमाणीकरण का उपयोग करने का निर्णय लिया। संक्षेप में, यह सब है:

स्व-हस्ताक्षरित प्रमाण पत्र, क्लाइंट और सर्वर (आसान-आरएसए का उपयोग करके) तैयार करें;

वेबसर्वर को कॉन्फ़िगर करें जो केवल https स्वीकार करने के लिए रिपॉजिटरी को फ्रन्ट करता है; नग्नेक्स के मामले में ऐसा लग सकता है:

server {

  listen 443;

  root /path/to/public;
  server_name secure_repo;

  ssl on;
  ssl_certificate /etc/nginx/ssl/server.crt;
  ssl_certificate_key /etc/nginx/ssl/server.key;

  ssl_session_timeout 5m;

  ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:;

  ssl_prefer_server_ciphers on;
  ssl_client_certificate /etc/nginx/ssl/ca.crt;
  ssl_verify_client on;

  location / {
     autoindex on;
  }
}

ग्राहक प्रमाण पत्र, क्लाइंट कुंजी और सीए / / / apt / ssl के लिए सर्टिफिकेट और, Ubuntu के मामले में, /etc/apt/apt.conf.d के लिए 00https फ़ाइल जोड़ें:

Debug::Acquire::https "true"; Acquire::https::example.com { Verify-Peer "true"; Verify-Host "false"; CaInfo "/etc/apt/ssl/ca.crt"; SslCert "/etc/apt/ssl/client.crt"; SslKey "/etc/apt/ssl/client.key"; };

ध्यान रखें, यदि आप स्व-हस्ताक्षरित प्रमाणपत्र का उपयोग कर रहे हैं, तो मेजबान सत्यापन को बंद करना महत्वपूर्ण है: Verify-Host "false";यदि आप ऐसा नहीं करते हैं, तो आप एक लिंक भेजेंगे: SSL: certificate subject name (blah-blah-blah) does not match target host name 'example.com'

और यहां हम जाते हैं, रिपॉजिटरी तक कोई अनधिकृत पहुंच नहीं है। इसलिए यह काफी उपयोगी और शक्तिशाली चीज है।

— at0S
स्रोत

3

महान जवाब के लिए धन्यवाद। लेकिन मुझे लगता है कि मुख्य मुद्दा अभी भी है। HTTPS वास्तव में विशेष रूप से वेब और डेबियन पैकेज पर स्थानान्तरण के लिए डिफ़ॉल्ट प्रोटोकॉल बनना चाहिए। तर्क यह नहीं होना चाहिए कि एचटीटीपीएस क्यों नहीं होना चाहिए?

— zaadeh

1

@aalizadeh, मैं आपसे सहमत हूं, https का उपयोग करते समय ओवरहेड है, लेकिन कोई भारी ओवरहेड नहीं है। मुझे लगता है, मुख्य कारण है कि https एक डिफ़ॉल्ट परिवहन नहीं है, कुछ संगठन स्पष्ट रूप से किसी भी एन्क्रिप्ट किए गए ट्रैफ़िक को रोकते हैं (जैसा कि वे चाहते हैं कि कर्मचारी इंटरनेट पर क्या कर रहे हैं) में अपनी नाक छड़ी करने में सक्षम हों, जिसका अर्थ है कि रिपॉजिटरी का समर्थन करना है http और https दोनों ट्रांसपोर्ट। हो सकता है अन्य कारणों देखते हैं

— at0S

1

स्व-हस्ताक्षरित प्रमाण पत्र के साथ भी, "सत्यापित-होस्ट" "झूठ" का उपयोग करना गलत है। आपको अपने ग्राहकों को इसके बजाय (सही) सर्वर प्रमाणपत्र के बारे में पता करने की आवश्यकता है।

— एक्सल बेकर्ट

1

वास्तव में, लेकिन यहाँ मेरे ग्राहक केवल आंतरिक सिस्टम थे। इसलिए सभी उचित पक्की बुनियादी संरचना बनाने के बजाय मैंने कोने को काट दिया। और हाँ, बाद में पिकी को ठीक से व्यवस्थित किया गया और वेरिफ़-होस्ट असत्य; हटा दिया गया था। और हाँ, बात मान्य है।

— 23

1

ubuntu xenial apt संकुल को अनपेक्षित उपयोगकर्ता _apt के रूप में प्राप्त किया जाता है, क्या आप कृपया इस थ्रेड को विवरण के साथ अपडेट कर सकते हैं कि आपने फ़ाइल अनुमति समस्याओं को कैसे प्रबंधित या हल किया है।

— डेविड

7

ध्यान दें कि जैसे कमजोरियों के कारण

https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1647467

... जो InRelease पर हस्ताक्षर करने से इनकार करता है, वैसे भी HTTPS को कॉन्फ़िगर करना एक अच्छा विचार है।

— रोयस विलियम्स
स्रोत

1

और अब यह एक के रूप में अच्छी तरह से: mirror.fail AKA usn.ubuntu.com/3746-1 AKA CVE-2018-0501। InRelease हस्ताक्षर पर्याप्त नहीं है । "लेकिन सभी दर्पणों को HTTPS में ले जाने में समय और समन्वय लगेगा!"। हाँ। अभी शुरू करो। यह अंतिम InRelease विफलता नहीं होगी।

— रॉयस विलियम्स

1

यहाँ एक और उदाहरण है, एक अलग पारिस्थितिकी तंत्र से - अल्पाइन। इसकी पैकेज प्रबंधन प्रणाली डिफ़ॉल्ट रूप से HTTPS का उपयोग नहीं करती है, और पैकेज की अखंडता को सत्यापित करने के लिए पूरी तरह से हस्ताक्षर करने पर निर्भर करती है ... और उस सत्यापन का सितंबर 2018 में दूरस्थ रूप से दोहन योग्य बग था: justi.cz/security/2018/09/13/alpine apk-rce.html अल्पाइन चलती शुरू कर देना चाहिए अब डिफ़ॉल्ट रूप से HTTPS का उपयोग कर सकते हैं।

— रॉयस विलियम्स

4

"बेनामी" उपयोग-मामले के लिए भी है apt-transport-torजो तब आपको URIs tor+http://को source.list फ़ाइलों में रखने की अनुमति देता है । यह आपके दर्पण से कनेक्शन को एन्क्रिप्ट करने की तुलना में बहुत बेहतर गुमनामी संरक्षण है।

उदाहरण के लिए, एक स्थानीय पर्यवेक्षक को अभी भी पता होगा कि आप HTTPS के साथ भी सॉफ़्टवेयर को अपडेट या इंस्टॉल कर रहे हैं, और संभवत: कुछ सभ्य अनुमान लगा सकते हैं कि आप उनमें से कौन सा कर रहे हैं (और संभवतः जो पैकेज भी आकार के आधार पर)।

डेबियन टोर "प्याज सेवाओं" के माध्यम से एपीटी रिपॉजिटरी प्रदान करता है ताकि आप डोमेन-नाम प्रणाली पर भरोसा किए बिना एंड-टू-एंड एन्क्रिप्शन (टीएलएस के समान) प्राप्त कर सकें। इस प्रकार उपलब्ध सभी डेबियन सेवाओं के लिए onion.debian.org देखें । मुख्य डेबियन एफ़टीपी भंडार हैvwakviie2ienjx6t.onion

— meejah
स्रोत