স্বচ্ছ এসএসএল প্রক্সি সেট আপ করা হচ্ছে


14

80 টি বন্দর দিয়ে যাওয়া ট্র্যাফিকের জন্য 2 নেটওয়ার্ক কার্ডের সাথে একটি লিনাক্স বাক্স সেটআপ করেছি One একটি কার্ড ইন্টারনেটে যেতে ব্যবহৃত হয়, অন্যটি একটি নেটওয়ার্কিং সুইচটিতে আবদ্ধ হয়। পয়েন্টটি ডিবাগিংয়ের উদ্দেশ্যে সেই স্যুইচ পর্যন্ত থাকা ডিভাইসগুলিতে সমস্ত এইচটিটিপি এবং এইচটিটিপিএস ট্র্যাফিক পরিদর্শন করতে সক্ষম হতে পারে।

আমি iptables জন্য নিম্নলিখিত নিয়ম লিখেছি:

nat

-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.2.1:1337
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 1337

-A POSTROUTING -s 192.168.2.0/24 -o eth0 -j MASQUERADE

192.168.2.1e1377-এ, আমি চার্লস ব্যবহার করে একটি স্বচ্ছ HTTP প্রক্সি পেয়েছি ( রেকর্ডিংয়ের জন্য http://www.charlesproxy.com/ ) ।

80 পোর্টের জন্য সবকিছু ঠিক আছে তবে আমি যখন 443 (এসএসএল) বন্দরটির জন্য 1337 পোর্টের দিকে নির্দেশ করে একই ধরণের নিয়ম যুক্ত করি তখন আমি চার্লসের মাধ্যমে অবৈধ বার্তা সম্পর্কে ত্রুটি পাই।

চার্লসের সাথে আগে আমি একই কম্পিউটারে এসএসএল প্রক্সিং ব্যবহার করেছি ( http://www.charlesproxy.com/docamentation/proxying/ssl-proxying/ ) এর , তবে কোনও কারণে স্বচ্ছতার সাথে এটি করা ব্যর্থ হয়েছে। আমি যে কয়েকটি সংস্থাগুলি সংগ্রহ করেছি তা বলেছি এটি সম্ভব নয় - যদি কেউ এর কারণ ব্যাখ্যা করতে পারে তবে আমি উত্তর হিসাবে তা গ্রহণ করতে রাজি আছি।

একটি নোট হিসাবে, সাবনেট পর্যন্ত আবদ্ধ সমস্ত ক্লায়েন্ট সহ আমার বর্ণিত সেট আপের সম্পূর্ণ অ্যাক্সেস রয়েছে - তাই আমি চার্লসের স্ব-স্বাক্ষরিত শংসাপত্রগুলি গ্রহণ করতে পারি। সমাধানটি চার্লস-নির্দিষ্ট হতে হবে না কারণ তত্ত্ব অনুসারে, যে কোনও স্বচ্ছ প্রক্সি করবে।

ধন্যবাদ!

সম্পাদনা করুন: এটির সাথে কিছুটা খেলার পরে, আমি এটি একটি নির্দিষ্ট হোস্টের জন্য কাজ করতে সক্ষম হয়েছি। আমি যখন আমার আইপটিবলগুলি নিম্নলিখিতগুলিতে সংশোধন করি (এবং 1338 বিপরীত প্রক্সি জন্য চারলে খুলি):

nat

-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.2.1:1337
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 1337

-A PREROUTING -i eth1 -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.2.1:1338
-A PREROUTING -i eth1 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 1338

-A POSTROUTING -s 192.168.2.0/24 -o eth0 -j MASQUERADE

আমি একটি প্রতিক্রিয়া পেতে সক্ষম, কিন্তু কোনও গন্তব্য হোস্ট ছাড়া। বিপরীত প্রক্সিটিতে, আমি যদি কেবল উল্লেখ করি যে 1338 থেকে সমস্ত কিছু নির্দিষ্ট হোস্টে গিয়েছিল যা আমি আঘাত করতে চেয়েছিলাম, এটি হাতের কাঁটাটি যথাযথভাবে সম্পাদন করে এবং আমি যোগাযোগটি পরীক্ষা করার জন্য এসএসএল প্রক্সিং চালু করতে পারি।

সেটআপটি আদর্শের চেয়ে কম কারণ 1338 থেকে আমি সমস্ত কিছু সেই হোস্টের কাছে ধরে নিতে চাই না - গন্তব্যের হোস্টটি ছিনতাই করা হচ্ছে কেন এমন কোনও ধারণা?

আবার ধন্যবাদ


আপনার কোন নির্দিষ্ট সমস্যা হচ্ছে? এটি সম্ভব, যেহেতু আপনি যে শংসাপত্রগুলি গতিশীলভাবে উত্পন্ন করছে তার উপর আপনি বিশ্বাস করছেন - এটি একটি এমআইটিএম হতে পারে এবং যোগাযোগের সরল পাঠ্যকে ধারণ করতে পারে এবং ক্লায়েন্টের দ্বারা সংযোগটি এখনও বিশ্বাসযোগ্য হতে পারে।
শেন ম্যাডেন

আমি আমার পোস্টটি সম্পাদনা করেছি - আমি বিশ্বাস করি যে গন্তব্য হোস্টটি ছিটকে যাবে
খারাপ

উত্তর:


10

আপনি যে সমস্যাগুলি দেখছেন সেগুলি হ'ল একক আইপি ঠিকানা / বন্দরে একাধিক শংসাপত্রের ব্যবহার (সার্ভারের নাম ইঙ্গিত ব্যবহার না করে) প্রতিরোধ করে

সরল এইচটিটিপি-তে আপনার স্বচ্ছ প্রক্সি বলতে পারে যে ক্লায়েন্টটি কোন হোস্টের সাথে সংযোগ স্থাপন করতে চায় তা দেখে Host

এইচটিটিপিএস এমআইটিএম স্বচ্ছ প্রক্সিটি যখন অনুরোধটি পেয়ে যায়, তখন ক্লায়েন্টটি প্রথমে কোন হোস্টের নামটি অনুরোধ করেছিল তা জানতে পারে না। (আমি এমনকি নিশ্চিত নই যে এই নিয়মগুলির সাথে এটি আইপি ঠিকানাটি পেতে পারে, যা সম্ভবত সাধারণ ক্ষেত্রে কাজ না করার সম্ভাবনা সত্ত্বেও, বিপরীত ডিএনএস লুপ ব্যবহার করে এটি অনুমান করার অনুমতি দিতে পারে))

  • প্রত্যাশিত হোস্টের নাম পেতে, এমআইটিএম প্রক্সিটি পড়তে হবে Host এইচটিটিপি বার্তায় , যা কেবলমাত্র সফল হ্যান্ডশেকের পরে ঘটতে পারে।
  • একটি সফল হ্যান্ডশেক পাওয়ার জন্য, এমআইটিএম প্রক্সিটি প্রত্যাশিত হোস্টনামের সাথে মিলে একটি স্পুফ শংসাপত্র তৈরি করতে হবে।

ফলস্বরূপ, এমআইটিএম প্রক্সি হ্যান্ডশেকের আগে কোন শংসাপত্র তৈরি করতে পারে তা জানতে পারে না।

এটি একটি স্বচ্ছ-স্বতন্ত্র এমআইটিএম প্রক্সি নিয়ে কাজ করতে পারে, কারণ আপনি অন্তত HTTP CONNECTপদ্ধতির মাধ্যমে হোস্টের নামটি পাবেন get


এটি আমাকে অনেক কিছু ব্যাখ্যা করার জন্য ধন্যবাদ! আমার মনে হচ্ছে আমি সঠিক প্রশ্ন জিজ্ঞাসা করতে শুরু করতে পারি। কিভাবে একজন স্বচ্ছ এসএসএল প্রক্সি স্থাপন করতে যাবেন? হ্যান্ডশেক কেমন?
Badunk

1
@ ব্যাঙ্ক, আপনি যদি ক্লায়েন্ট পক্ষের সমস্ত শংসাপত্র যাচাইকরণ অক্ষম না করেন তবে আপনি করতে পারবেন বলে আমি মনে করি না।
ব্রুনো

প্রক্সিটির সঠিক হোস্টের নাম পাওয়ার অন্য উপায়টি হ'ল ক্লায়েন্ট এবং প্রক্সিটির মধ্যে হ্যান্ডশেক চালিয়ে যাওয়ার আগে শংসাপত্রটি পেতে তার লক্ষ্য আইপি ঠিকানায় নিজেই একটি অনুরোধ করা।
ব্রুনো

mitmproxy একটি HTTPS প্রক্সি। আপনাকে সমস্ত শংসাপত্র যাচাইকরণ অক্ষম করতে হবে না তবে আপনাকে mitmproxy সার্টিটি ইনস্টল করতে হবে কারণ এটি সমস্ত https সংযোগের জন্য ব্যবহৃত হবে।
টাইলার

3

এই বিষয় সম্পর্কে কিছু প্রাথমিক তথ্য।

আমি জানি যে কেবল কয়েকটি ডিভাইসই সফলভাবে এই ক্রিয়াটি বন্ধ করতে পারে। তবে এগুলি সত্যই সাধারণ জনগণের কাছে উপলভ্য নয়। আমি নিজে এসএসএল অফলোডিং সহ একটি ফোরটিনিট ফোরগেট ব্যবহার করছি।

এটি মূলত যা করে তা হ'ল; এটি হোস্টকে করা SSL সংযোগটি বাধা দেয় এবং হার্ডওয়্যারে সংযোগটি ডিক্রিপট করে, তারপরে আপনি কোথায় যেতে চান তা পরীক্ষা করে এবং সেই তথ্যের ভিত্তিতে ফায়ারওয়ালিং সিদ্ধান্ত নেয় makes

এরপরে এটি ডেটা পুনরুদ্ধার করতে সেই হোস্টের সাথে এটির নিজস্ব সংযোগ স্থাপন করে এবং ব্যবহারকারীর সরবরাহিত সিএ ব্যবহার করে ক্লায়েন্টের কাছে আসল অনুরোধটি পুনরায় স্বাক্ষর করে। এই কাজটি সুচারু করার জন্য ক্লায়েন্টের উপর বিশ্বাসযোগ্য রুট সিএতে সিএ থাকা প্রয়োজন।

এই জাতীয় সেটআপগুলি সংস্থাগুলিতে ইন্টারনেট ব্যবহার সম্পর্কিত কোম্পানির নীতিমালা প্রয়োগ করতে ব্যবহৃত হয়। একটি অ্যাক্টিভ ডিরেক্টরি ব্যবহার করার কারণে ক্লায়েন্টগুলিতে আপনার সংস্থা সিএ ইনস্টল করা সহজ এটি বড় সংস্থাগুলির জন্য কোনও সমস্যা নয়।

এসএসএল ট্র্যাফিক এনক্রিপ্ট করা হওয়ায় এটি কোনও ম্যানুয়াল প্রক্সি তৈরি না করেই আপনি এটি করতে পারেন। এটি মূলত একটি এমআইটিএম তাই কোনও আইনি সমস্যা .েকে রাখা জরুরী।


1

আপনি দেখতে পেতেন এই অন্যান্য প্রশ্নে আরও কয়েকটি পরামর্শ রয়েছে: স্বচ্ছ এসএসএল প্রক্সি মিথ ও ঘটনা । এবং এই লিঙ্কটি রয়েছে যা স্কুইডকে একটি স্বচ্ছ এসএসএল প্রক্সি হওয়ার জন্য ঠিক কীভাবে কনফিগার করতে হবে তা ব্যাখ্যা করে explains আপনি যা সন্ধান করছেন এটি তা নয়, তবে এটি ভুল কি হতে পারে সে সম্পর্কে অন্তত অন্তর্দৃষ্টি দিতে পারে।

Iptables নিয়মগুলি ঠিক আছে বলে মনে হয় তবে আপনি যে প্রক্সি সফটওয়্যারটি ব্যবহার করছেন সেটি আপনি যা করতে চেষ্টা করছেন তা করতে সক্ষম কিনা তা আমার কোনও ধারণা নেই। ডকুমেন্টেশন অবশ্যই এটি দাবি করে।


0

ব্রুনোর সমাধান যোগ করতে, আমি কিছুটা তদন্ত করেছি এবং কীভাবে আমি আরও একটি কম-আদর্শ-দ্রুত দ্রুত সমাধান পেয়েছি তা ভাগ করে নিতে চাই।

এই iptables সেট করার পরে, আমি 1338 বন্দরটিতে একটি বিপরীত প্রক্সি স্থাপন করতে পারি এবং এটি 1337 বন্দরে লোকালহোস্টে পাঠাতে পারি Since যেহেতু 1337 বন্দরটি একটি স্বচ্ছ HTTP প্রক্সি এবং ডেটা ডিক্রিপ্ট করা হয়েছে, তাই এটি হোস্ট শিরোনাম গ্রহণ করবে এবং এটিকে গন্তব্যস্থলে পরিণত করবে হোস্ট।

প্রধান ক্ষতিটি হ'ল আমি একটি https সংযোগটি মূলত HTTP- তে রূপান্তর করেছি - যা সর্বদা প্রতিটি সার্ভারের সাথে কাজ করে না (আমি যে সুরক্ষা গর্তটি প্রকাশ করব তা থেকে উল্লেখ না করে)।

আমি আমার সফ্টওয়্যারটির সীমার মধ্যে থেকে কাজ করছিলাম। আমি বিশ্বাস করি যে ব্রুনো অনুযায়ী একটি ক্লিনার সমাধান 1338 থেকে সমস্ত ট্র্যাফিক ডিক্রিপ্ট করা উচিত বলে ধরে নেওয়া হবে। ডিক্রিপশন পরে, গন্তব্য হোস্টটি পরীক্ষা করুন এবং তারপরে এসএসএল ব্যবহার করে অনুরোধটির প্রক্সি করুন।


নিশ্চিত যে আমি বুঝতে পেরেছি না, আপনি অবশ্যই এটির https://সাথে ক্লায়েন্টের দৃষ্টিকোণ থেকে একটি সঠিক সংযোগ তৈরি করছেন না ?
ব্রুনো
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.