এসএসএল এবং টিএলএসে পার্থক্যের কার্যকরী প্রভাব


31

আমি জানি যে টিএলএস মূলত এসএসএলের একটি নতুন সংস্করণ, এবং এটি সাধারণত অনিরাপদ থেকে সুরক্ষিত (সাধারণত একটি STARTTLS কমান্ডের মাধ্যমে) কোনও সংযোগ স্থানান্তরকে সমর্থন করে।

আমি যা বুঝতে পারি না তা হ'ল আইটি প্রফেশনালের কাছে টিএলএস কেন গুরুত্বপূর্ণ এবং কেন আমি এই পছন্দটিকে অন্যটির থেকে বেছে নেব। টিএলএস কি আসলেই একটি নতুন সংস্করণ, এবং যদি তা হয় তবে এটি একটি সামঞ্জস্যপূর্ণ প্রোটোকল?

আইটি পেশাদার হিসাবে: আমি কখন ব্যবহার করব? আমি কখন ব্যবহার করব না?

উত্তর:


44

সংক্ষিপ্ত উত্তর:

এসএসএল হ'ল টিএলএসের পূর্বসূরী। এসএসএল ছিল নেটস্কেপ যোগাযোগ দ্বারা নির্মিত একটি মালিকানাধীন প্রোটোকল, পরে আইইটিএফ-এর মধ্যে প্রমিতকরণ করা হয় এবং নাম পরিবর্তন করে টিএলএস করা হয়। সংক্ষেপে, সংস্করণগুলি এই ক্রমে যায়: SSLv2, SSLv3, TLSv1.0, TLSv1.1 এবং TLSv1.2।

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

উভয় মোডগুলি ব্যবহার করে সমতুল্য হওয়া উচিত, তবে ক্লায়েন্টটি এসএসএল / টিএলএসকে এক বা অন্য কোনও উপায়ে প্রত্যাশা করার জন্য কনফিগার করা হয়েছে, যাতে কোনও সাধারণ-পাঠ্য সংযোগে ডাউনগ্রেড না হয়।

দীর্ঘ উত্তর:

এসএসএল বনাম টিএলএস

আমি যতদূর জানি, এসএসএলভি 1 কখনও ল্যাবগুলি ছেড়ে যায় না। SSLv2 এবং SSLv3 নেটস্কেপ দ্বারা উন্নত প্রোটোকল ছিল। SSLv2 কিছু সময়ের জন্য নিরাপত্তাহীন বলে বিবেচিত হয়েছে, যেহেতু এটি হ্রাসের ঝুঁকির ঝুঁকিপূর্ণ। SSLv3 অভ্যন্তরীণভাবে (3,0)এর সংস্করণ নম্বর হিসাবে ব্যবহার করে ( ClientHelloবার্তার মধ্যে)।

টিএলএস হ'ল আইইটিএফ-র মধ্যে আরও বেশি উন্মুক্ত প্রোটোকল হিসাবে মানীকরণের ফলাফল। (আমি মনে করি আমি কোথাও পড়েছি, সম্ভবত ই। রেসকোর্লা বইয়ে, নামটি এমনভাবে বেছে নেওয়া হয়েছিল যাতে কোনও অংশীদারি কোনও পক্ষকে সমর্থন না করার জন্য এটির প্রতি অংশীদারি সমানভাবে অসন্তুষ্ট হন: মানদণ্ডে এটি বেশ সাধারণ অভ্যাস) বডি।) কীভাবে রূপান্তরটি হয়েছিল তাতে আগ্রহীরা এসএসএল-টক লিস্টের এফএকিউ পড়তে পারেন ; এই দস্তাবেজের একাধিক অনুলিপি রয়েছে তবে বেশিরভাগ লিঙ্কগুলি (থেকে netscape.com) পুরানো।

টিএলএস খুব অনুরূপ বার্তা ব্যবহার করে (প্রোটোকলকে অসম্পূর্ণ করতে যথেষ্ট আলাদা, যদিও এটি একটি সাধারণ সংস্করণে আলোচনা করা সম্ভব )। TLS 1.0 এর , 1.1 এবং 1.2 ClientHello বার্তাগুলি ব্যবহার (3,1), (3,2), (3,3)সংস্করণ সংখ্যা, যা পরিষ্কারভাবে SSL এর থেকে ধারাবাহিকতা দেখায় ইঙ্গিত।

এই উত্তরে প্রোটোকল পার্থক্য সম্পর্কে আরও বিশদ রয়েছে ।

আমি কখন ব্যবহার করব? আমি কখন ব্যবহার করব না?

সম্ভব হলে সর্বোচ্চ সংস্করণ ব্যবহার করুন। অনুশীলনে, পরিষেবা প্রদানকারী হিসাবে এটির জন্য আপনার ব্যবহারকারীদের এই সংস্করণগুলিকে সমর্থন করে এমন ক্লায়েন্ট থাকা দরকার। যথারীতি এটি সর্বদা ঝুঁকি-মূল্যায়ন অনুশীলন (উপযুক্ত হলে ব্যবসায়ের ক্ষেত্রে সমর্থনযুক্ত)। এটি বলা হচ্ছে, যাইহোক SSLv2 কেটে দিন।

তদ্ব্যতীত, নোট করুন যে এসএসএল / টিএলএস দ্বারা সরবরাহিত সুরক্ষাটি আপনি কোন সংস্করণটি ব্যবহার করেন না কেবল এটি সঠিক কনফিগারেশন সম্পর্কেও: টিএসএলএসভি ১.০ এর চেয়ে শক্তিশালী সিফার স্যুট সহ এসএসএলভি ৩ ব্যবহার করা অবশ্যই দুর্বল (অথবা বেনামে / নাল-এনক্রিপশন) সাইফার স্যুট। কিছু সিফার স্যুট, খুব দুর্বল হিসাবে বিবেচিত, টিএলএস-এর নতুন সংস্করণগুলি দ্বারা স্পষ্টভাবে নিষিদ্ধ করা হয়েছে। আপনি আরও বিশদ জানতে চাইলে জাভা 7 সানজেএসএসই সরবরাহকারীর টেবিলগুলি (এবং তাদের পাদটীকাগুলি) আগ্রহী হতে পারে।

কমপক্ষে টিএলএস 1.1 ব্যবহার করা ভাল হবে তবে দুর্ভাগ্যক্রমে সমস্ত ক্লায়েন্ট তাদের সমর্থন করে না (যেমন জাভা 6)। ১.১ এর নিচে কোনও সংস্করণ ব্যবহার করার সময়, অবশ্যই সেরা দুর্বলতা প্রশমিত করার পক্ষে এটি মূল্যবান ।

আমি সাধারণত এরিক রেসকোর্লা বইটি - এসএসএল এবং টিএলএস: ডিজাইনিং এবং বিল্ডিং সিকিউর সিস্টেমস, অ্যাডিসন-ওয়েসলি, 2001 আইএসবিএন 0-2016151588-3 যারা সত্যই আরও বিশদ চান তাদের কাছে সুপারিশ করতাম ।

সুস্পষ্ট এসএসএল / টিএলএস বনাম অন্তর্ভুক্ত

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

আমি মনে করি যে এই বিভ্রান্তিটি ঘটে যাওয়ার কারণটি STARTTLSমোডের কারণে । কিছু লোক মনে হয় এটি এটিকে STARTTLS= টিএলএস হিসাবে বুঝতে পেরেছে , তবে এটি এমন নয়। মূল শব্দটি STARTTLS"START", টিএলএস নয়। কেন এটি ডাকা হয়নি STARTSSLবা STARTSSLORTLSকারণ এই এক্সটেনশনগুলি আইইটিএফ-এর মধ্যে নির্দিষ্ট করা হয়েছিল, যা কেবলমাত্র তার স্পেসিফিকেশনে ব্যবহৃত নাম ব্যবহার করেছিল (ধরে নিই যে টিএলএস নামটি শেষ পর্যন্ত একমাত্র স্থায়ী হবে, আমি অনুমান করি)।

  • প্লেইন-পাঠ্য পরিষেবা হিসাবে একই পোর্টে এসএসএল: এইচটিটিপিএস প্রক্সি।

আজকাল, বেশিরভাগ এইচটিটিপিএস সার্ভারগুলি টিএলএস পরিচালনা করতে পারে তবে কয়েক বছর আগে বেশিরভাগ মানুষ এইচটিটিপিএসের জন্য এসএসএলভি 3 ব্যবহার করছিল। এইচটিটিপিএস (কঠোরভাবে বলা, টিটিএসের উপরে এইচটিটিপি হিসাবে প্রমিত ) সাধারণত টিসিপি সংযোগের উপর এসএসএল / টিএলএস সংযোগ স্থাপন করে এবং তারপরে এসএসএল / টিএলএস স্তরটির মাধ্যমে HTTP বার্তা বিনিময় করে। এর মধ্যে একটি HTTP প্রক্সি ব্যবহার করার সময় এর ব্যতিক্রম রয়েছে। এই ক্ষেত্রে, ক্লায়েন্টটি HTTP প্রক্সিটির সাথে স্পষ্টভাবে সংযোগ স্থাপন করে (সাধারণত 3131 পোর্টে), তারপরে CONNECTএইচটিটিপি কমান্ড জারি করে এবং প্রতিক্রিয়া সফল হয়, এসএসএল / টিএলএস হ্যান্ডশেকটি প্রেরণ করেClientHelloবার্তা। ব্রাউজার এবং প্রক্সিগুলির মধ্যে সংযোগ সম্পর্কিত যতদূর এই একই জিনিস ঘটে (স্পষ্টত প্রক্সি এবং লক্ষ্য সার্ভারের মধ্যে নয়: এটি একই মেশিনও নয়)। এটি SSLv3 এর সাথে ঠিক কাজ করে। একটি প্রক্সি পেছনের পরিস্থিতিতে আমাদের মধ্যে অনেকে এমন সার্ভারগুলির বিরুদ্ধে ব্যবহার করবে যা কমপক্ষে টিএলএস 1.0 সমর্থন করে না।

  • প্লেইন-পাঠ্য পরিষেবা হিসাবে একই পোর্টে এসএসএল: ইমেল।

এই এক স্পষ্টভাবে নির্দিষ্টকরণের বাইরে, কিন্তু বাস্তবে, এটি প্রায়শই কাজ করে। কঠোরভাবে স্পেসিফিকেশন বললে STARTTLS কমান্ডটি ব্যবহার করার পরে টিএলএস (এসএসএল নয়) এ স্যুইচ করার বিষয়ে কথা বলা হয়। অনুশীলনে, এসএসএল প্রায়শই খুব বেশি কাজ করে (ঠিক "টিটিএস ওভার এইচটিটিপি" -র মতো টিএলএসের পরিবর্তে এসএসএল ব্যবহার করে)) আপনি নিজে চেষ্টা করে দেখতে পারেন ধরে নিই যে আপনার কাছে একটি এসএমটিপি বা আইএমএপি সার্ভার রয়েছে যা STARTTLS সমর্থন করে, থান্ডারবার্ড ব্যবহার করুন, পছন্দসমূহ, উন্নত বিকল্পসমূহ, কনফিগার সম্পাদক এবং বন্ধ করুন security.enable_tls। অনেক সার্ভার এখনও সংযোগ গ্রহণ করবে, কেবলমাত্র তাদের বাস্তবায়নগুলি SSL / TLS স্তরটি কোনও এসএসএল / টিএলএস লাইব্রেরিতে প্রেরণ করে যা সাধারণত এটির জন্য না কনফিগার করা থাকলে, একইভাবে এসএসএল এবং টিএলএস পরিচালনা করতে সক্ষম হবে। ওপেনল্যাডএপএফএএইচএ যেমনটি দেয়, "TLSv1 এর সাথে ব্যবহারের জন্য প্রক্রিয়াটি তৈরি করা হলেও, বেশিরভাগ বাস্তবায়ন প্রয়োজনে SSLv3 (এবং SSLv2) এ ফ্যালব্যাক করবে। "। আপনি যদি নিশ্চিত না হন তবে ওয়্যারশার্কের মতো কোনও সরঞ্জাম দিয়ে পরীক্ষা করুন।

  • স্বতন্ত্র বন্দরে টিএলএস

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

আমি কখন ব্যবহার করব? আমি কখন ব্যবহার করব না?

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

সুস্পষ্ট এবং অন্তর্নিহিত এসএসএল / টিএলএসের মধ্যে প্রধান পার্থক্যটি হবে কনফিগারেশন সেটিংসের স্পষ্টতা।

উদাহরণস্বরূপ, এলডিএপি-র জন্য, ক্লায়েন্ট যদি অ্যাপাচি এইচটিপিডি সার্ভার হয় ( mod_ldap- এর ডকুমেন্টেশনটি এসএসএল এবং টিএলএস-এর মধ্যে পার্থক্যকে ভুলভাবে ব্যাখ্যা করে) তবে আপনি একটি ldaps://ইউআরএল (যেমন AuthLDAPURL ldaps://127.0.0.1/dc=example,dc=com?uid?one) ব্যবহার করে অন্তর্নিহিত এসএসএল / টিএলএস ব্যবহার করতে পারেন বা স্পষ্টত SSL / ব্যবহার করতে পারেন একটি অতিরিক্ত প্যারামিটার ব্যবহার করে টিএলএস (যেমন AuthLDAPURL ldap://127.0.0.1/dc=example,dc=com?uid?one TLS)।

সেখানে সম্ভবত সাধারণত সামান্য ক্ষুদ্রতর ঝুঁকি ভাষী যখন URL স্কিম নিরাপত্তা প্রোটোকল উল্লেখ (হয় https, ldaps, ...) যখন SSL / TLS সক্ষম করতে একটি অতিরিক্ত সেটিং কনফিগার করতে ক্লায়েন্ট আশা করার পরিবর্তে, কারণ তারা ভুলে যেতে পারে। এটা তর্কযোগ্য। অন্যটির তুলনায় অন্যটির প্রয়োগের সঠিকতার ক্ষেত্রেও সমস্যা থাকতে পারে (উদাহরণস্বরূপ, আমি মনে করি জাভা এলডিএপি ক্লায়েন্ট হোস্ট নাম যাচাইকরণ ব্যবহার করার সময় ldaps://, কখন এটি করা উচিত নয়, যখন এটি ldap://+ স্টার্টটিএলএস সমর্থন করে) সমর্থন করে না ।

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

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

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


3
শুধুমাত্র একটি বিস্তৃত উত্তর নয়, উত্স সহ সঠিক একটি পোস্ট করার জন্য আপনাকে ধন্যবাদ। আমার কাছ থেকে +1

13

টিএলএস হ'ল এসএসএল-এর চেয়ে একটি নতুন প্রোটোকল (তবে এএফআইএকি, এটি এসএসএল ভি 3 এর সাথে সামঞ্জস্যপূর্ণ)। সাধারণত, আপনার দুশ্চিন্তা করার দরকারের মধ্যে কেবল একটি পার্থক্য রয়েছে:

একটি এসএসএল প্রোটোকল সাধারণত একটি পৃথক বন্দর থাকে - উদাহরণস্বরূপ, HTTP এর জন্য 80 এবং HTTPS (HTTP / SSL) এর জন্য 443। আপনি যখন এসএসএল পোর্টের সাথে সংযোগ করেন তখন পুরো সেশনটি এনক্রিপ্ট করা হয়।

টিএলএস এসএসএল থেকে নতুন, এবং এটির জন্য পৃথক বন্দর প্রয়োজন হয় না - পরিবর্তে এটি ক্লায়েন্টের সাথে আলোচনার প্রয়োজন হয় .. উদাহরণস্বরূপ, আপনি পোর্ট 143 এ আইএমএপ চালাতে পারেন, এবং যদি মেল সার্ভার এবং ক্লায়েন্ট উভয়ই টিএলএস সমর্থন করে, ক্লায়েন্ট একটি STARTTLSকমান্ড প্রেরণ করবে এবং কেবলমাত্র এনক্রিপশন সক্ষম করবে। এসএসএল-কম অ্যাপ্লিকেশনগুলির সাথে সামঞ্জস্য রেখে এইভাবে আপনার আলাদা আলাদা এসএসএল-পোর্টের প্রয়োজন হবে না।

সংক্ষিপ্তসার:
এসএসএল : কিছুটা বড়। প্লেইন এবং এনক্রিপ্ট করা সংযোগের জন্য পৃথক পৃথক বন্দর। এসএসএল পোর্টের সমস্ত ট্র্যাফিক সর্বদা এনক্রিপ্ট করা থাকে।
টিএলএস : উভয় সরল এবং এনক্রিপ্ট হওয়া সংযোগের জন্য একক বন্দর। ক্লায়েন্ট একটি STARTTLSআদেশ জারি করার পরে এনক্রিপশন সক্ষম করা হয় ।


তবে আমার কখন ব্যবহার করা উচিত?
র্যান্ডেল

3
STARTTLSকিছু প্রোটোকল ব্যবহার করে একই সংযোগে টিএলএসে স্যুইচ করতে সক্ষম করে তোলে তা এইচএসএল এবং টিএলএসের মধ্যে পার্থক্য নয়। প্রযুক্তিগতভাবে আপনি একইভাবে এসএসএলভি 3 এ যেতে পারেন।
ব্রুনো

9
দুর্ভাগ্যক্রমে এই উত্তরটি ভুল। আবার, TLS এর বনাম SSL এর হয় না : এক বন্দর পৃথক পোর্ট বনাম সম্পর্কে security.stackexchange.com/q/5126/2435
ব্রুনো

1
ত্রুটিপূর্ণ. -1 ভোট
টাটাস

10

টিএলএস হ'ল এসএসএলের একটি নতুন সংস্করণ। আপনার কাছে বিকল্প থাকলে টিএলএস ব্যবহার করুন। আরও, যথারীতি উইকিপিডিয়ায়


1
আমার কাছে বিকল্প আছে কেন টিএলএস ব্যবহার করবেন?
র্যান্ডেল 18

8

এই ইন্ডিয়ানা বিশ্ববিদ্যালয় নলেজ বেস নিবন্ধ থেকে:

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

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

দুটি প্রোটোকলের মধ্যে পার্থক্যগুলি খুব সামান্য এবং খুব প্রযুক্তিগত, তবে সেগুলি পৃথক মান। টিএলএস আরও শক্তিশালী এনক্রিপশন অ্যালগরিদম ব্যবহার করে এবং বিভিন্ন পোর্টে কাজ করার ক্ষমতা রাখে। অতিরিক্তভাবে, টিএলএস সংস্করণ 1.0 এসএসএল সংস্করণ 3.0 এর সাথে আন্তঃব্যবস্থাপনা করে না।


2
এখান থেকে: kb.iu.edu/data/anjv.html
jjnguy

4

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


ওপি ইতিমধ্যে জানিয়েছে যে টিএলএস এসএসএল এর একটি নতুন সংস্করণ। আপনার পোস্টের বাকি একটি মন্তব্য। কোনও উত্তর নয়।
ব্যবহারকারী 207421

@ এজেপি: আপনি কি উত্তরটি> তিন বছরের পুরানো লক্ষ্য করেছেন?
ব্যবহারকারী 9517 GoFundMonica

(আমি আশ্চর্য হই যে এমনকি কোনও mod -মোডা অন্য ব্যবহারকারীর প্রশ্নের সম্পাদনা করতে পারে "আমি জানি ..." যা মূল ব্যবহারকারীর জন্য প্রযোজ্য নয়)
WRAR

1
@ ইজেপিকে, ডাব্লুআরআরআর থেকে নিরপেক্ষ হতে, এই প্রশ্নের সম্পাদনা দীর্ঘ বিতর্কের বিষয় হয়েছে ( এখানে এবং এখানে দেখুন )। অবশ্যই, ইতিহাসের দিকে নজর না দিয়ে এর কোনওটিই সঙ্গে সঙ্গে দৃশ্যমান নয়। (দ্রষ্টব্য যে এই সম্পাদনাটি একটি মোড দ্বারা তৈরি করা হয়েছিল ...)
ব্রুনো
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.