এসএসএল এবং ম্যান-ইন-মধ্যম ভুল বোঝাবুঝি


91

আমি এই সমস্যার সাথে সম্পর্কিত অনেকগুলি ডকুমেন্টেশন পড়েছি তবে আমি এখনও সমস্ত টুকরো একসাথে পেতে পারি না, তাই আমি বেশ কয়েকটি প্রশ্ন জিজ্ঞাসা করতে চাই।

  1. সবার আগে আমি প্রমাণীকরণের প্রক্রিয়াটি সংক্ষিপ্তভাবে বর্ণনা করব যেমনটি আমি এটি বুঝতে পেরেছি, যেমনটি সম্পর্কে আমার ভুল হতে পারে: একটি ক্লায়েন্ট একটি সংযোগ শুরু করে, যা একটি সার্ভার পাবলিক কী, কিছু মেটাডেটা এবং ডিজিটাল স্বাক্ষরের সংমিশ্রণে সাড়া দেয় বিশ্বস্ত কর্তৃপক্ষ। তারপরে ক্লায়েন্ট সিদ্ধান্তটি গ্রহণ করে যদি সে সার্ভারকে বিশ্বাস করে, সার্বজনীন কী সহ কিছু এলোমেলো সেশন কী এনক্রিপ্ট করে এবং এটিকে আবার প্রেরণ করে। এই সেশন কীটি কেবলমাত্র সার্ভারে থাকা ব্যক্তিগত কী দ্বারা ডিক্রিপ্ট করা যায়। সার্ভার এটি করে এবং তারপরে এইচটিটিপিএস সেশন শুরু হয়।

  2. সুতরাং, আমি যদি উপরে সঠিক হয়ে থাকি তবে প্রশ্নটি হয় এই জাতীয় দৃশ্যে কীভাবে ম্যান-ইন-দ্য মিডল আক্রমণ হতে পারে? আমি বলতে চাইছি, এমনকি যদি কেউ সার্বজনীন (যেমন www.server.com) জনসাধারণের কীটির প্রতিক্রিয়াটিকে বাধা দেয় এবং আমাকে যে তিনি www.server.com বলে মনে করার জন্য কিছু উপায় রেখেছেন, তবুও তিনি আমার সেশন কীটি ডিক্রিপ্ট করতে পারবেন না ব্যক্তিগত কী ছাড়া।

  3. মিউচুয়াল অথেন্টিকেশন সম্পর্কে কথা বলতে গেলে, ক্লায়েন্টের পরিচয় সম্পর্কে সার্ভারের আত্মবিশ্বাসের বিষয়টি কি সব? আমি বলতে চাইছি, ক্লায়েন্টটি ইতিমধ্যে নিশ্চিত হতে পারে যে সে সঠিক সার্ভারের সাথে যোগাযোগ করছে, তবে এখন সার্ভারটি ক্লায়েন্টটি কে, ঠিক তা আবিষ্কার করতে চায়?

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

উত্তর:


106

এসএসএলের মধ্য-মধ্য-আক্রমণগুলি কেবলমাত্র তখনই সম্ভব যখন এসএসএলের পূর্ব শর্তগুলির একটি ভেঙে যায়, এখানে কয়েকটি উদাহরণ দেওয়া হয়েছে;

  • সার্ভার কীটি চুরি হয়ে গেছে - এর অর্থ আক্রমণকারী সার্ভার হিসাবে উপস্থিত হতে পারে এবং ক্লায়েন্টের পক্ষে এটি জানার কোনও উপায় নেই

  • ক্লায়েন্ট একটি অবিশ্বাস্য সিএ বিশ্বাস করে (বা এটির মূল কীটি চুরি হয়ে গেছে) - যে কোনও বিশ্বস্ত সিএ কী রাখে সে সার্ভার বলে ভান করে একটি শংসাপত্র তৈরি করতে পারে এবং ক্লায়েন্ট এটি বিশ্বাস করবে। ব্রাউজারগুলিতে আজ বিদ্যমান সিএর সংখ্যার সাথে, এটি একটি আসল সমস্যা হতে পারে। এর অর্থ সার্ভার শংসাপত্রটি অন্য কোনও বৈধ একটিতে পরিবর্তিত হবে বলে মনে হচ্ছে যা বেশিরভাগ ক্লায়েন্ট আপনার কাছ থেকে আড়াল করবে।

  • ক্লায়েন্টটি তার বিশ্বস্ত সিএ-এর তালিকার বিরুদ্ধে শংসাপত্রটি সঠিকভাবে যাচাই করতে বিরত করে না - যে কোনও সিএ তৈরি করতে পারে। কোনও বৈধতা না থাকলে, "বেনের গাড়ি এবং শংসাপত্রগুলি" ভেরিসাইন এর মতোই বৈধ বলে মনে হবে।

  • ক্লায়েন্টকে আক্রমণ করা হয়েছে এবং তার বিশ্বাসযোগ্য মূল কর্তৃপক্ষগুলিতে একটি নকল সিএ ইনজেকশনের ব্যবস্থা করা হয়েছে - আক্রমণকারীকে তার পছন্দ মতো কোনও শংসাপত্র তৈরি করতে দেয় এবং ক্লায়েন্ট এটি বিশ্বাস করবে। ম্যালওয়্যার উদাহরণস্বরূপ এটি করতে ঝোঁক fake

বিশেষত # 2 বরং কদর্য, এমনকি যদি আপনি অত্যন্ত বিশ্বস্ত শংসাপত্রের জন্য অর্থ প্রদান করেন, আপনার সাইটটি কোনওভাবেই সেই শংসাপত্রের সাথে তালাবদ্ধ থাকবে না, আপনাকে ক্লায়েন্টের ব্রাউজারে সমস্ত সিএ- তে বিশ্বাস করতে হবে যেহেতু তাদের মধ্যে কোনও জাল শংসাপত্র তৈরি করতে পারে আপনার সাইট যে ঠিক বৈধ। এটিতে সার্ভার বা ক্লায়েন্টের অ্যাক্সেসের প্রয়োজন নেই।


4
Sslstrip এর মতো সরঞ্জামও রয়েছে , যা https লিঙ্কগুলিকে HTTP লিঙ্কগুলিতে স্বচ্ছভাবে পুনরায় লেখার চেষ্টা করবে।
এমপন্টিলো

4
শংসাপত্র যাচাইয়ের সম্পর্কে আরেকটি বিষয় হ'ল ক্লায়েন্টের হোস্টের নাম যাচাই করা দরকার। সার্টিফিকেটটি আসল কিনা তা যাচাই করার পক্ষে এটি যথেষ্ট ভাল নয়, এটি আপনি যে সত্তার সাথে কথা বলতে চান সেই সত্তাকে ইস্যু করতে হবে ( এখানে এবং এখানে দেখুন )। Sslstrip হিসাবে, চূড়ান্তভাবে তারা ব্যবহারকারীর উপর নির্ভর করে যে তারা দুর্ভাগ্যক্রমে SSL / TLS ব্যবহার করতে চান (যদিও এইচএসটিএস সাহায্য করতে পারে)।
ব্রুনো

আমি কি কোনও ক্রোম (বা অন্য কোনও ব্রাউজারের জন্য) এই প্লাগইনটি লিখতে পারি যা ব্রাউজারটি এনক্রিপ্ট করার আগে ডেটাটিকে বাধা দেয়?
রোসদী কাসিম

অন্য কারণ হ'ল "বিশ্বাসের অপব্যবহার", যেমন ট্র্যাক ট্রাস্ট ইস্যুতে।
অনুষ্ঠান

4
@ রিমোভারটি আসলে নয় ... # 1 হ'ল প্রকৃত পাবলিক কীটির সাথে যুক্ত, সার্ভারে থাকা ব্যক্তিগত কী। এই পরিস্থিতিতে আপনি প্রকৃত সার্ভারের সাথে কথা বলবেন তবে অন্য কেউ মাঝখানে হয়ে ট্র্যাফিকটি ডিক্রিপ্ট করতে পারে। তারা শংসাপত্রটি পরিবর্তন করতে পারে না। # 2 এর মধ্যে পুরোপুরি আলাদা শংসাপত্র প্রেরণ জড়িত, এটি একটি "বিশ্বস্ত" সিএ দ্বারা জারি করা যা ক্লায়েন্টের কাছে বৈধ বলে মনে হবে। আক্রমণকারী তারপরে আপনার পক্ষ থেকে প্রক্সি অনুরোধ করতে পারে এবং সেভাবে বার্তা দেখতে পারে। উভয়ই সমঝোতায় আসে তবে # 1 আপনার নিয়ন্ত্রণে। # 2, দুর্ভাগ্যক্রমে, না।
বেসিক

17

সবার আগে আমি স্বীকৃতি প্রক্রিয়াটি সংক্ষেপে বর্ণনা করব কারণ এটি আমি বুঝতে পেরেছি, সম্ভবত আমি সেই পদক্ষেপে ভুল করছি। সুতরাং, একটি ক্লায়েন্ট একটি সংযোগ শুরু করে এবং একটি সার্ভার জনসাধারণের কী, কিছু মেটাডেটা এবং একটি বিশ্বস্ত কর্তৃপক্ষের ডিজিটাল স্বাক্ষরের সংমিশ্রণে সাড়া দেয়।

সার্ভারটি একটি X.509 শংসাপত্র শৃঙ্খলা এবং তার নিজস্ব কী দ্বারা স্বাক্ষরিত একটি ডিজিটাল স্বাক্ষর দিয়ে সাড়া দেয়।

তারপরে ক্লায়েন্ট সিদ্ধান্ত নেয় যদি সে সার্ভারে বিশ্বাস করে

সঠিক।

সর্বজনীন কী সহ কিছু এলোমেলো সেশন কী এনক্রিপ্ট করে এবং এটিকে আবার পাঠায়।

না। ক্লায়েন্ট এবং সার্ভার একটি মিউচুয়াল সেশন কী জেনারেশন প্রক্রিয়াতে জড়িত যার অধিবেশন সেশন কী নিজেই কখনই সংক্রমণিত হয় না।

এই সেশন কীটি কেবলমাত্র সার্ভারে থাকা ব্যক্তিগত কী দ্বারা ডিক্রিপ্ট করা যায়।

না

সার্ভার এটি করে

না

এবং তারপরে এইচটিটিপিএস অধিবেশন শুরু হয়।

TLS / SSL এর অধিবেশন শুরু হয়, কিন্তু সেখানে আরও বেশ কয়েকটি ধাপ অগ্রণী।

সুতরাং, আমি যদি উপরে সঠিক হয়ে থাকি তবে প্রশ্নটি হয় যে এই জাতীয় দৃশ্যে কীভাবে মধ্যযুগের মধ্যম আক্রমণটি ঘটতে পারে?

সার্ভার হিসাবে মাস্ক্রেড করে এবং এসএসএল এন্ডপয়েন্ট হিসাবে অভিনয় করে। ক্লায়েন্টকে কোনও অনুমোদনের পদক্ষেপ বাদ দিতে হবে। দুঃখের বিষয়, বেশিরভাগ এইচটিটিপিএস সেশনের একমাত্র অনুমোদনের পদক্ষেপটি একটি হোস্টনাম চেক।

আমি বোঝাতে চাইছি যে কেউ যদি সার্ভারকে (যেমন www.server.com) প্রতিক্রিয়াটিকে জনসাধারণের কী দিয়ে বাধা দেয় এবং তারপরে কোনও উপায়ে আমাকে ভাবতে দেয় যে সে www.server.com, তবুও সে আমার সেশন কীটি ডিক্রিপ্ট করতে সক্ষম হবে না ব্যক্তিগত কী ছাড়া।

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

মিউচুয়াল অথেন্টিকেশন সম্পর্কে কথা বলতে গেলে, ক্লায়েন্টের পরিচয় সম্পর্কে সার্ভারের আত্মবিশ্বাসের বিষয়টি কি সব? আমি বলতে চাইছি যে ক্লায়েন্টটি ইতিমধ্যে নিশ্চিত হতে পারে যে সে সঠিক সার্ভারের সাথে যোগাযোগ করছে, তবে এখন সার্ভারটি খুঁজে পেতে চায় যে ক্লায়েন্ট কে, তাই না?

সঠিক।

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

না

পারস্পরিক প্রমাণীকরণের সাথে তুলনা করার মতো এই পদ্ধতির ডাউনসাইডগুলি কী কী (কেবলমাত্র সুরক্ষা বিষয়গুলি গুরুত্বপূর্ণ, বাস্তবায়নের জটিলতা নয়)?

এটি কেবলমাত্র ব্যবহারকারীর নাম / পাসওয়ার্ডের মতোই সুরক্ষিত, যা কোনও ব্যক্তিগত কী-এর চেয়ে ফাঁস হওয়া অনেক সহজ।


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

4
@ ভাদিমচেকরি প্রাক-মাস্টার গোপনটি সেশন কী নয়। এটি উভয় প্রান্তে স্বাধীনভাবে সেশন কী উত্পন্ন করতে ব্যবহৃত একাধিক উপাত্তগুলির মধ্যে একটি one প্রক্রিয়াটি আরএফসি 2246
মারকুইস

4
@ ক্রিস আপনি অনেক কম দুর্বল, তবে আইপি অ্যাড্রেস স্পোফিং সম্ভব। শংসাপত্রটিতে পিয়ার পরিচয় যাচাইয়ের বিকল্প নেই।
লার্নের মারকুইস

4
+1 এটি বেশিরভাগ অংশের জন্য বেশ ভাল উত্তর। তবে কিছু পয়েন্টে এক-শব্দ প্রতিক্রিয়া সহ ব্যাখ্যাটির অভাব রয়েছে। আপনি যদি মূল বক্তব্যগুলিতে প্রসারিত এবং / অথবা বিস্তৃত বিবরণগুলি ব্যাখ্যা করতে চান তবে আপনি এটি একটি চূড়ান্ত উত্তর দিতে পারেন (যেমন, "না" এর পরিবর্তে আপনি আসলে কী ঘটে তা সংক্ষেপে উল্লেখ করতে পারেন )) এটি সত্যিই কয়েকটি বিষয় পরিষ্কার করবে। ধন্যবাদ
ভয়েস

4
@ tjt263 প্রথম 'না' আসলে কী ঘটেছিল তার ব্যাখ্যা সরবরাহ করে। পরবর্তী দুটি 'না' একই ভুল ধারণাটিকে বোঝায় যা প্রথম 'না' উত্পাদন করেছিল এবং একই ব্যাখ্যা রয়েছে। পরবর্তী এবং চূড়ান্ত 'না' বলতে 'আমি ভুল' বোঝায় এবং এটি ওপি থেকে উদ্ধৃত তথ্যগুলিকে বোঝায়। অতএব আপনি এখানে যা অনুপস্থিত মনে করেন তা গ্রহণ করা কঠিন।
মারকুইস

17

ক্লায়েন্ট এবং সার্ভারের মাঝামাঝি যে কোনও ব্যক্তি https এ মাঝারি আক্রমণে একজনকে মঞ্চস্থ করতে পারে। আপনি যদি এটি অসম্ভব বা বিরল বলে মনে করেন তবে বিবেচনা করুন যে এমন বাণিজ্যিক পণ্য রয়েছে যা নিয়মিতভাবে ডিক্রিপ্ট হয়, স্ক্যান করে এবং পুনরায় এনক্রিপ্ট করে ইন্টারনেট গেটওয়ে জুড়ে সমস্ত এসএসএল ট্র্যাফিক করে consider। তারা ক্লায়েন্টকে "রিয়েল" এসএসএল সার্ট থেকে অনুলিপি করা বিবরণ সহ ফ্লাই অন-ফ্লাইয়ে তৈরি করা একটি এসএসএল সার্টিটি পাঠিয়ে কাজ করে তবে একটি ভিন্ন শংসাপত্র শৃঙ্খলে স্বাক্ষরিত হয়। যদি এই চেইনটি ব্রাউজারের কোনও বিশ্বস্ত সিএ এর সাথে বন্ধ হয়ে যায়, তবে এই এমআইটিএম ব্যবহারকারীর কাছে অদৃশ্য হবে। এই পণ্যগুলি প্রাথমিকভাবে সংস্থাগুলির কাছে "সুরক্ষিত" (পুলিশ) কর্পোরেট নেটওয়ার্কগুলিতে বিক্রি হয় এবং ব্যবহারকারীদের জ্ঞান এবং সম্মতিতে ব্যবহার করা উচিত। প্রযুক্তিগতভাবে যদিও, আইএসপি বা অন্য কোনও নেটওয়ার্ক ক্যারিয়ার দ্বারা তাদের ব্যবহার বন্ধ করে দেওয়ার কিছুই নেই। (এনএসএর কমপক্ষে একটি বিশ্বাসযোগ্য রুট সিএ স্বাক্ষর কী রয়েছে ধরে নেওয়া নিরাপদ হবে )।

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

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


তবে এর অর্থ এই এমআইটিএম সরঞ্জামগুলি (যেটি ট্র্যাফিকটিকে ডিক্রিপ্ট করে / স্ক্যান করে এবং পুনরায় এনক্রিপ্ট করে) এর কোনও বিশ্বস্ত সিএর অ্যাক্সেস থাকা দরকার? (সার্ভার শংসাপত্র "নকল" করতে)। বলি এটি ঘটে। তারপরে কেউ এটিকে আঘাত করে, তথ্যটি সর্বজনীন হয়, এবং প্রেসে কোনও কেলেঙ্কারি হবে এবং সিএ শংসাপত্রটি সমস্ত ব্রাউজার থেকে ঠিক সরানো হবে? আমি বলতে চাই, আদর্শ ...
jazzcat

4
না না. গেটওয়েতে "এসএসএল পরিদর্শন" ফ্লাইতে শংসাপত্রগুলি তৈরি এবং স্বাক্ষর করতে হবে তবে এটি করার জন্য কোনও রুট সার্টের দরকার নেই। এটিতে কিছু অন্তর্বর্তী সার্ট রয়েছে, এতে একটি চেইন রয়েছে। আপনার ব্রাউজারের দ্বারা চেইনের মূলটি বিশ্বাসযোগ্য কিনা তা নির্ধারণ করে যে আপনি কোনও শংসাপত্রের ত্রুটি দেখতে পাবেন কিনা। কর্মক্ষেত্রে, আমাদেরকে দুর্গের মূল শংসাপত্র ইনস্টল করতে বলা হয়েছিল যাতে আমাদের ব্রাউজারগুলি শংসাপত্রের ত্রুটি না দেয়। তবে যদি ইতিমধ্যে বিশ্বস্ত শংসাপত্র দিয়ে চেইনটি সমাপ্ত হয়, তবে এটি স্বচ্ছ।
bbsimonbb

কাজের একজন সহকর্মী এই কর্পোরেট নেটওয়ার্ক এমআইটিএম কৌশলগুলি এসএসএলকে বাধ্য করার জন্য Google এর পক্ষে কেন একটি খারাপ ধারণা - তার আসলে কী সঠিকতা হতে পারে?
এমসিক্সটাইন

4
দুঃখিত আমি প্রশ্নটি বুঝতে পারি না!
bbsimonbb

2
  1. সঠিক
  2. এত সঠিক নয়। এই ধরণের আক্রমণে ইটারিয়েডিয়েট সার্ভার আপনার অনুরোধ পেয়ে যায় এবং আপনার পক্ষ থেকে এটিকে গন্তব্যে প্রেরণ করে। এবং তারপরে ফলাফল দিয়ে আপনাকে সাড়া দিন। প্রকৃতপক্ষে এটি ম্যান-ইন-মিডল সার্ভার যা আপনার সাথে সুরক্ষিত সংযোগ তৈরি করে প্রকৃত সার্ভারটি নয় যা আপনি তৈরি করতে চান। এজন্য আপনার অবশ্যই সর্বদা শংসাপত্রটি বৈধ এবং বিশ্বাসযোগ্য তা পরীক্ষা করা উচিত।
  3. সঠিক হতে পারে
  4. আপনি যদি নিশ্চিত হন যে সুরক্ষিত সংযোগটি বিশ্বাসযোগ্য তবে এটি ব্যবহারকারীর নাম / পাসওয়ার্ড প্রেরণ করা নিরাপদ।

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

4
এটি খুব বিরল ঘটে যে মধ্যবর্তী সার্ভারটি বৈধ শংসাপত্র প্রেরণ করে, গত বছর যদি আমি ভালভাবে মনে করি তবে এটি কমোডো সিএর সাথে হ্যাপেন। তবে সাধারণত যদি এটি বিশ্বস্ত সংযোগ হয় তবে এটি সম্পূর্ণ সুরক্ষিত।
বায়নাক্স

1

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.