STARTTLS টিএলএস / এসএসএল এর চেয়ে কম নিরাপদ?


45

থান্ডারবার্ডে (এবং আমি অন্যান্য অনেক ক্লায়েন্টকে ধরেও নিয়েছি) আমার কাছে "এসএসএল / টিএলএস" এবং "STARTTLS" এর মধ্যে নির্বাচন করার বিকল্প রয়েছে।

আমি যতদূর বুঝতে পেরেছি, "STARTTLS" এর অর্থ সরল কথায় "যদি উভয় প্রান্তই TLS সমর্থন করে তবে এনক্রিপ্ট করুন, অন্যথায় স্থানান্তরটি এনক্রিপ্ট করবেন না" । এবং "এসএসএল / টিএলএস" এর অর্থ সরল কথায় "সর্বদা এনক্রিপ্ট করুন বা কিছুতেই সংযুক্ত থাকবেন না"এটা কি সঠিক?

বা অন্য কথায়:

STARTTLS এসএসএল / টিএলএসের চেয়ে কম সুরক্ষিত কারণ এটি আমাকে না জানিয়ে প্লেটেক্সটে ফ্যালব্যাক করতে পারে?

উত্তর:


46

এসএমটিপি ( আরএফসি 3207 ) এর জন্য STARTTLS আরএফসির উপর ভিত্তি করে উত্তরটি হ'ল:

STARTTLS টিএলএসের চেয়ে কম সুরক্ষিত।

নিজে কথা বলার পরিবর্তে, আমি আরএফসিকে নিজের পক্ষে কথা বলার অনুমতি দেব, বোল্ডটিতে চারটি প্রাসঙ্গিক বিট হাইলাইট করে :

সার্ভার থেকে "250 STARTTLS" প্রতিক্রিয়া মোছার মাধ্যমে একটি ম্যান-ইন-দ্য মিডল আক্রমণ শুরু করা যেতে পারে। এটি ক্লায়েন্টকে টিএলএস সেশন শুরু করার চেষ্টা না করার কারণ হতে পারে। আরেকটি ম্যান-ইন-দ্য মিডল আক্রমণ হ'ল সার্ভারকে তার STARTTLS সক্ষমতার ঘোষণা দেওয়ার অনুমতি দেওয়া হয়েছে, তবে ক্লায়েন্টের টিএলএস এবং সার্ভারের প্রতিক্রিয়া শুরু করার অনুরোধটি পরিবর্তন করা। এই ধরনের আক্রমণ থেকে রক্ষা করার জন্য ক্লায়েন্ট এবং সার্ভার উভয়ই বার্তাগুলি সফলভাবে স্থানান্তরিত করার আগে নির্বাচিত হোস্টগুলির জন্য একটি উপযুক্ত সাইফার স্যুইটের সফল টিএলএস আলোচনার জন্য কনফিগার করতে সক্ষম হতে হবে। সম্ভব হলে টিএলএস ব্যবহারের অতিরিক্ত বিকল্পও সরবরাহ করা উচিত। একটি বাস্তবায়ন মে টিএলএস কোনও প্রদত্ত পীরের সাথে যোগাযোগ করতে এবং পরবর্তী সেশনে যদি এটি ব্যবহার না করা হয় তবে একটি সতর্কতা তৈরি করতে ব্যবহৃত হয়েছিল তা রেকর্ড করার ক্ষমতা সরবরাহ করুন।

যদি টিএলএস আলোচনায় ব্যর্থ হয় বা ক্লায়েন্ট যদি 454 টি প্রতিক্রিয়া পায় তবে ক্লায়েন্টকে পরবর্তী সিদ্ধান্ত নেওয়ার সিদ্ধান্ত নিতে হবে। এখানে তিনটি প্রধান পছন্দ রয়েছে: বাকি এসএমটিপি সেশনটির সাথে এগিয়ে যান , [...]

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


5
আপনার বক্তব্য অবশ্যই বৈধ, তবে এসএমটিপিএস সম্পর্কিত কোনও আরএফসি বা অফিসিয়াল স্পেসিফিকেশনের অভাবে (যেমন এসএমটিপি + "অন্তর্নিহিত এসএসএল / টিএলএস" যেখানে এসএসএল / টিএলএস প্রথমে প্রতিষ্ঠিত হয়েছে), এসএমটিপি / এসএমটিপিএস ক্লায়েন্টরাও সরল সংযোগে ফিরে যাওয়ার সিদ্ধান্ত নিতে পারে যদি তারা 465 পোর্টে কোনও এসএসএল / টিএলএস সংযোগ শুরু করতে পরিচালনা করতে না পারে That's তবে এটি এখনও নিখুঁতভাবে প্রয়োগের পছন্দ।
ব্রুনো

2
টিএলএস সংযোগ স্থাপনের জন্য প্রচুর আরএফসি রয়েছে। আরএফসির সাথে সামঞ্জস্য করার বিকল্প হিসাবে "প্লেইন-পাঠ্য সংযোগের অনুমতি দিন" এর কোথাও নেই (অন্তত এটি অনেক লোকের কাছে সংবাদ হবে)। সুতরাং এসএমটিপিএসের STARTTLS এর চেয়ে বেশি সুরক্ষিত হওয়ার জন্য একটি পৃথক আরএফসি প্রয়োজন হয় না।
গ্রেগ

1
টিএলএস (আরএফসি 5246 এবং পূর্বসূরি), পিকেআই (আরএফসি 5280), নাম যাচাইকরণ (আরএফসি 6125) সম্পর্কে আরএফসি রয়েছে, তবে এসএমটিপিএসে এসএমটিএস এবং এসএসএল / টিএলএসের মধ্যে মিথস্ক্রিয়াকে আনুষ্ঠানিকভাবে AFAIK বর্ণনা করার মতো কিছুই নেই, আপনি যেমন পান তেমনভাবে নয় এইচটিটিপিএসের জন্য একটি অনুমান: আরএফসি 2818. কেউ বলতে পারে "এটি সুস্পষ্ট, প্রথমে এসএসএল / টিএলএস সংযোগ স্থাপন করুন", তবে এ সম্পর্কে সমস্ত কিছুই স্পষ্ট নয় (বিশেষত পরিচয় যাচাইয়ের দিকটি, আরএফসি 6125-এ কেবল সম্প্রতি আনুষ্ঠানিকভাবে প্রবর্তিত)।
ব্রুনো 17

23

দুটি বিকল্পের মধ্যে সুরক্ষার কোনও পার্থক্য নেই।

  • এসএসএল / টিএলএস প্রথমে একটি এসএসএল / টিএলএস সংযোগ খোলে, তারপরে এসএমটিপি লেনদেন শুরু করে। এটি অবশ্যই এমন কোনও বন্দরে ঘটেছিল যার কোনও নন-এসএসএল / টিএলএস এসএমটি সার্ভার ইতিমধ্যে চলছে না; প্রোটোকলের প্রকৃতির কারণে প্লেইন পাঠ্য এবং এনক্রিপ্ট হওয়া সংযোগ উভয়ই পরিচালনা করতে একটি একক বন্দর কনফিগার করা অসম্ভব।

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

সাধারণত, এসএসএল / টিএলএস কেবল শেষ ক্লায়েন্ট এবং সার্ভারের মধ্যেই ব্যবহৃত হয়। আন্তঃ-সার্ভার পরিবহন সুরক্ষিত করতে এমটিএর মধ্যে STARTTLS বেশি ব্যবহৃত হয়।

এই দুটি বাস্তবায়ন দেওয়া, STARTTLS অনিরাপদ হিসাবে বিবেচিত হতে পারে যদি ব্যবহারকারী বা প্রশাসক ধরে নিচ্ছে যে সংযোগটি এনক্রিপ্ট করা হয়েছে তবে এটি এনক্রিপশনের প্রয়োজনে এটি আসলে কনফিগার করা হয়নি। তবে ব্যবহৃত এনক্রিপশন হ'ল এসএসএল / টিএলএস-এর সমান এবং অতএব এই ধরণের কনফিগারেশন ত্রুটির বাইরে ম্যান-ইন-মধ্য-আক্রমণের ঝুঁকি কম নয়।


2
যদি সংযোগটি এনক্রিপ্ট করা থাকে তবে এসএসএল / টিএলএস এবং STARTTLS উভয়ই একই, হ্যাঁ। তবে আমি যা চেয়েছিলাম তা নয়। আমার অর্থ: আমি যদি STARTTLS ব্যবহার করি তবে কীভাবে আমি (ব্যবহারকারী হিসাবে) জানব যে আমার সংযোগটি সত্যই সুরক্ষিত আছে? যদি আমি এসএসএল / টিএলএস ব্যবহার করার চেষ্টা করি তবে সার্ভার সমর্থন না করলে আমি কেবলই সংযোগ করতে পারব না, তবে কমপক্ষে কিছুই সরলখরচার হিসাবে প্রেরণ করা হয়নি। তবে যদি STARTTLS প্লেইন্টেক্সটে ফিরে আসে, তবে আমার মেইলটি সরল পাঠ্যে প্রেরণ করা হয়েছে তা জেনেও আমাকে পাঠানো হবে (আমাকে সত্যিকার অর্থেই আমি নিরাপদ করছি না বলে মনে করি)।
ফু বার

6
আমি জানি না কেন এই উত্তরটি সঠিক হিসাবে বেছে নেওয়া হয়েছিল। এটা ভুল. ক্রিস্টোফার যেমন উল্লেখ করেছেন, STARTTLS টিএলএসের চেয়ে কম সুরক্ষিত কারণ এটি ক্লায়েন্টদের সুরক্ষার একটি মিথ্যা ধারণা দেয়।
গ্রেগ

4
@ গ্রেগ প্রোটোকলটিতে কোন ভুল নেই। ত্রুটিটি এমন ক্লায়েন্ট যা আরএফসি অনুসরণ করে না এবং সংযোগ এনক্রিপ্ট না করা অবস্থায় ব্যবহারকারীকে সতর্ক করে না।
দীর্ঘায়ু

1
@ লম্বনেক তাই ... সম্ভবত এটি একটি শব্দার্থবিজ্ঞানের জিনিস, তবে ক্লায়েন্টরা টিএলএস প্রোটোকলটি "অনুসরণ করতে পারে না" এবং একটি ইমেল সময়কাল ধরে নিয়ে যেতে পারে না। সুতরাং এটি একটি অর্থপূর্ণ পার্থক্য।
গ্রেগ

2
@ ব্রুনো "ক্লায়েন্টকে খারাপভাবে প্রয়োগ করা হলে এটি কেবলমাত্র কম সুরক্ষিত" <= আপনি কেবল আমার পক্ষে আমার বক্তব্য রাখছেন। ক্রিয়াকলাপ সংযোগ স্থাপনের সময় যদি ক্লায়েন্ট সংযোগটি নিরাপত্তাহীন করতে কিছু করতে পারে তবে STARTTLS সুস্পষ্ট টিএলএসের চেয়ে কম সুরক্ষিত (যেখানে এটি সম্ভব নয়)।
গ্রেগ

8

বিশেষত ইমেলের জন্য, জানুয়ারিতে 2018 সালে আরএফসি 8314 প্রকাশিত হয়েছিল, যা স্পষ্টভাবে সুপারিশ করে যে "ইমপ্লিকেট টিএলএস" IMAP, POP3 এবং এসএমটিপি জমা দেওয়ার জন্য STARTTLS প্রক্রিয়াটির অগ্রাধিকার হিসাবে ব্যবহার করা উচিত।

সংক্ষেপে, এই মেমোটি এখন সুপারিশ করে যে:

  • টিএলএস সংস্করণ 1.2 বা এর বেশি MUAs এবং মেল সাবমিশন সার্ভারের মধ্যে এবং MUA এবং মেল অ্যাক্সেস সার্ভারের মধ্যে সমস্ত ট্র্যাফিকের জন্য ব্যবহৃত হতে পারে।
  • এমইউএ এবং মেল পরিষেবা সরবরাহকারী (এমএসপি) (ক) মেল অ্যাক্সেস এবং মেল জমা দেওয়ার জন্য ক্লিয়ারটেক্সট প্রোটোকল ব্যবহারকে নিরুৎসাহিত করে এবং (খ) এই উদ্দেশ্যে ক্লিয়ারটেক্সট প্রোটোকল ব্যবহার যত তাড়াতাড়ি সম্ভব অনুশীলন করা যায়।
  • "ক্লিয়ারটেক্সট" বন্দরের সাথে সংযোগ স্থাপনের এবং STARTTLS কমান্ড বা অনুরূপ কমান্ড ব্যবহার করে টিএলএসের সাথে আলোচনার অগ্রাধিকার হিসাবে মেল সাবমিশন সার্ভার এবং মেল অ্যাক্সেস সার্ভারের সংযোগগুলি "অন্তর্নিহিত টিএলএস" (নীচে সংজ্ঞায়িত হিসাবে) ব্যবহার করে করা উচিত

(সামনে জোর দাও)


4

উত্তরটি "নিরাপদ" দ্বারা আপনি কী বোঝাতে চান তার উপর কিছুটা ডিগ্রি নির্ভর করে।

প্রথমত, আপনার সারাংশটি এসএসএল / টিএলএস এবং STARTTLS এর মধ্যে পার্থক্যটি বেশ ক্যাপচার করে না।

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

যদি ক্লায়েন্টটি টিএলএসের প্রয়োজনের জন্য কনফিগার করা থাকে তবে দুটি পন্থা কম-বেশি সমানভাবে নিরাপদ। তবে এটি নিরাপদ করার জন্য STARTTLS কীভাবে ব্যবহার করা উচিত সে সম্পর্কে কয়েকটি সূক্ষ্মতা রয়েছে এবং STARTTLS বাস্তবায়নের জন্য এই বিবরণগুলি সঠিকভাবে পাওয়া বেশ খানিকটা কঠিন।

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

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

অন্যদিকে, আপনি যদি এমন কোনও পরিষেবার সাথে সংযোগ স্থাপন করছেন যা আপনি জানেন না যে এটি টিএলএস সমর্থন করে কিনা, STARTTLS সামান্য ভাল হতে পারে।

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

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


1

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

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


সুতরাং, STARTTLS সক্ষম একটি সার্ভারও সর্বদা এসএসএল / টিএলএস সক্ষম হবে, তাই না? সুতরাং প্রথমে এসএসএল / টিএলএস চেষ্টা করে দেখতে ভাল হয় যে এটি কাজ করে কিনা?
ফু বার

2
@ ফুবার নং, কেউ বোঝায় না যে অন্যটি উপলব্ধ। বাস্তবে, এগুলি সম্পূর্ণ আলাদা প্রমাণীকরণ ডোমেনগুলির সাথে কনফিগার করা যেতে পারে।
দীর্ঘায়ু

3
STARTTLS MitM এর পক্ষে ঝুঁকিপূর্ণ নয় যদি আপনি শংসাপত্রগুলি বৈধতা না দেন বা দুর্বলগুলি ব্যবহার করেন না। শংসাপত্রটি এখনও বরাবরের মতো ঠিক একইভাবে উপস্থাপিত হয় এবং ক্লায়েন্টের প্রয়োজন হতে পারে যে টিএলএস আপগ্রেড চালিয়ে যাওয়ার আগে সফল হয়। এটি লক্ষণীয় যে এটি এসএসএল / টিএলএস এর ঠিক একই অবস্থা।
ফ্যালকন মোমোট

1
কেন লোকেরা আপনাকে নিম্নচাপ দিচ্ছে তা জানেন না, এটি সঠিক উত্তর, STARTTLS টিএলএসের চেয়ে কম সুরক্ষিত, এবং এটি সুরক্ষার একটি মিথ্যা ধারণা দেয়। আইএসপিগুলি কেবল এটি খাড়া করতে পারে: arstechnica.com/tech-policy/2014/11/…
গ্রেগ

1
প্রোটোকল নিজেই যতদূর যায়, STARTTLS টিএলএসের চেয়ে কম সুরক্ষিত কারণ এটি ব্যবহারকারীকে সতর্ক না করে স্পষ্টভাবে প্লে
গ্রেগ

1

@ গ্রেগ এর সাথে সম্মত হন। এই আক্রমণগুলি সম্ভব। তবে এমটিএগুলি "সুবিধাবাদী টিএলএস" নয়, "বাধ্যতামূলক টিএলএস" ব্যবহারের জন্য (এমটিএর উপর নির্ভর করে) কনফিগার করা যেতে পারে। এর অর্থ কী তা হল যে ইমেল লেনদেনের জন্য টিএলএস এবং কেবলমাত্র টিএলএস ব্যবহৃত হয় (এটি STARTTLS অন্তর্ভুক্ত)। যদি দূরবর্তী এমটিএ STARTTLS সমর্থন না করে তবে ইমেলটি বাউন্স হয়ে যায়।


0

না, এটা হয় না কম নিরাপদ যখন আপনার আবেদন হ্যান্ডলগুলি এটি সঠিকভাবে।

টিএলএস হ্যান্ডেল করার জন্য ফোরওয়ে রয়েছে এবং অনেকগুলি প্রোগ্রাম আপনাকে চয়ন করতে দেয়:

  • টিএলএস নেই
  • উত্সর্গীকৃত বন্দরে টিএলএস (কেবলমাত্র টিএলএস চেষ্টা করে)
  • যদি পাওয়া যায় তবে টিএলএস ব্যবহার করুন (চেষ্টা করে starttls, ব্যর্থ হলে এনক্রিপ্ট করা সংযোগ ব্যবহার করে)
  • সর্বদা টিএলএস ব্যবহার করুন ( starttlsএটি কার্যকর না হলে ব্যবহার এবং ব্যর্থ হয়)

ডেডিকেটেড পোর্টে টিএলএসের সুবিধা হ'ল আপনি নিশ্চিত হতে পারেন যে আপনি যখন এমন কোনও প্রোগ্রাম ব্যবহার করেন যখন আপনি এখনও জানেন না বা এটির প্রথম-উইজার্ডে ত্রুটি পরিচালনা করার জন্য বিশদ সেটিংস প্রকাশ করে না তখন আপনি কোনও ফলব্যাক নেই।

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

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