এসএমটিপি সার্ভারের জন্য SSL শংসাপত্রের কোন হোস্টের নাম থাকা উচিত?

Question

আমার 192-2.0.2.1 এ একটি সার্ভার foo.example.com আছে

এটি আমার বেশ কয়েকটি ডোমেনের ই-মেইল পাওয়ার জন্য এক্সিম চালায়।

আমার ডোমেনগুলির প্রতিটিতে একটি এমএক্স রেকর্ড রয়েছে যা mx.example.com এ দেখায়, যা 192.0.2.1 এ সমাধান হয়

যদি আমি আগত ইমেল সংযোগগুলির জন্য এক্সিম অফার টিএলএস এনক্রিপশন করতে চাই, এসএসএল শংসাপত্রে আমার কোন হোস্টের নাম রাখা উচিত?

• foo.example.com কারণ সার্ভারটি হেলোতে এটাই বলবে?
• mx.example.com কারণ এই ক্লায়েন্টদের সাথে সংযুক্ত হয়ে থাকবে হোস্টের নাম?

http://www.checktls.com পরামর্শ দেয় যে উত্তরটি সঠিক, তবে আমি একটি নির্দিষ্ট উত্তর খুঁজে পাচ্ছি না।

Comments

এইচটিটিপি + এসএসএলে আপনার একাধিক নাম ভিত্তিক ভার্চুয়াল সার্ভার পরিবেশন করতে একটি ওয়াইল্ডকার্ড শংসাপত্র (* .example.com) প্রয়োজন। আমি এসএমটিপি + এসএসএল সম্পর্কে নিশ্চিত নই তবে আমি সন্দেহ করি আপনিও অনুরূপ বাধা পেয়ে যাবেন find এইচটিটিপি দিয়ে এটির চারপাশের উপায় হ'ল প্রতিটি ভার্চুয়াল সার্ভারকে আলাদা আইপি-তে আবদ্ধ করা এবং প্রত্যেকটির জন্য একটি অনন্য শংসাপত্র ব্যবহার করা।

— ক্রিস নাভা

ব্যবহারিকভাবে বলতে গেলে, কোনও এমএক্স সার্ভারের জন্য, আপনি নিজের সাধারণ নামটি কী সেট করেছেন তা কিছুটা বিবেচ্য নয়।

— সিএনএসটি

Answer 1

এটি প্রকৃতপক্ষে কোথাও সুস্পষ্টভাবে সংজ্ঞায়িত করা হয়নি, এবং সার্ভারটি "বিশ্বস্ত" হওয়া উচিত কিনা তা ক্লায়েন্টের (যা অবশ্যই অন্য কোনও মেল সার্ভার হতে পারে) এর সাথে সংযোগ স্থাপনের উপর নির্ভর করে; সম্পর্কিত আরএফসি ( আরএফসি 2487 ) থেকে উদ্ধৃতি :

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

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

- A SMTP client would probably only want to authenticate an SMTP
  server whose server certificate has a domain name that is the
  domain name that the client thought it was connecting to.

এর মূল অর্থটি হ'ল, সার্ভার যখন প্রদত্ত শংসাপত্রটি ব্যবহার করে টিএলএস এনক্রিপশন সরবরাহ করে, তখন এটি গ্রহণ বা অস্বীকার করার সিদ্ধান্তটি পুরোপুরি অন্য অংশের উপর নির্ভর করে, যা সম্ভবত শংসাপত্রের নামটির সাথে একই সংযুক্ত থাকতে চাইবে, তবে পারে এটি মেলে না এমনকি খুব ভালভাবে গ্রহণ করুন।

তবে অপেক্ষা করুন, আরও কিছু আছে। একই আরএফসি থেকে আবার উদ্ধৃত:

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

সুতরাং, টিএলএস হ্যান্ডশেক দেওয়ার আগে সার্ভার HELO / EHLO এর প্রতিক্রিয়াতে যা বলছে তা আসলে মোটেও তেমন মনে হয় না।

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

Answer 2

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

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

Comments

হ্যাঁ, এবং এই কারণেই, কমন নামটি কী সেট করা হয়েছে বা এটি প্রথমে সেট করা আছে তা আদৌ কিছু যায় আসে না।

— সিএনএসটি

Answer 3

সার্ভার শংসাপত্র যাচাই করার কাজ এবং এটি সার্ভারের হোস্ট নামের সাথে মিলে যায় যে কোনও এসএসএল / টিএলএস ব্যবহার করে যে কোনও প্রোটোকলের জন্য খাঁটিভাবে খদ্দেরের ভূমিকা।

যেমন, শংসাপত্রের হোস্টের নামটি ক্লায়েন্টটি অ্যাক্সেস করার চেষ্টা করছে সেই নামের সাথে মিলিয়ে নেওয়া উচিত।

যখন এসএসএল / টিএলএস সংযোগটি সামনের দিকে (এসএমটিপিএস) শুরু করা হয়, সংযোগটি প্রতিষ্ঠিত হওয়ার আগে সার্ভারের HELO বার্তাটি কী বলে তা দেখার কোনও উপায় নেই, সুতরাং এটি অবশ্যই অনুরোধটি ব্যবহার করে এটি ব্যবহার করবে made

এসএসএল / টিএলএস ব্যবহার করার পরে STARTTLS, ক্লায়েন্টটি এখনও এটির সাথে কনফিগার করা সার্ভারের সাথে কথা বলতে চায়, তাই এটি এখনও যাচাই করা উচিত। ব্যর্থতা যা এমআইটিএম আক্রমণগুলি সম্ভব করে তোলে:

• সি-> এস: হ্যালো, আমি অ্যালিস, আমি ববের সাথে কথা বলতে চাই।
• এস-> সি: হাই, আমি চক, এখানে চকের জন্য আমার সার্ট রয়েছে।
• সি-> এস: ওহ হ্যাঁ, আপনার সার্টটি চকের পক্ষে সত্যই বৈধ। এগিয়ে চলুন।
• ... অবশ্যই সেখানে একটি ত্রুটি আছে, যেহেতু অ্যালিস ববের সাথে একটি সুরক্ষিত যোগাযোগ চেয়েছিল।

উভয় ক্ষেত্রেই, এটি এমএক্স ঠিকানা যা ব্যবহার করা উচিত।

হোস্ট নেম ম্যাচিংয়ের নিয়মগুলি সম্প্রতি আরএফসি 6125 এর প্রোটোকল জুড়ে জড়ো করা হয়েছে , তবে খুব কম ক্লায়েন্ট এটিকে পুরোপুরি প্রয়োগ করে (এটি সম্পূর্ণ পরিবর্তনের চেয়ে সেরা অনুশীলন আরএফসি আরও, এবং এটি এখনও বেশ সাম্প্রতিক)।

ইন তার পরিশিষ্ট , এটা SMTP এর সম্পর্কে কি অস্তিত্ব সামনে (থেকে নেওয়া সংক্ষিপ্ত বিবরণ জন্য RFC 3207 এবং জন্য RFC 4954 )। বিশেষত " ক্লায়েন্টটি কোনও অনিরাপদ রিমোট উত্স থেকে প্রাপ্ত সার্ভার হোস্টনামের কোনও ফর্ম ব্যবহার করা উচিত নয় (উদাঃ, সুরক্ষিত ডিএনএস লুকআপ) " "(যা অবশ্যই সার্ভারের ব্যানারে প্রযোজ্য)। এছাড়াও এই, SMTP এর উত্তরাধিকার বিধি বিষয় বিকল্প নাম (সংক্রান্ত HTTPS দ্বারা তুলনায় একটু বেশি কবে নাগাদ ছিল উচিত পরিবর্তে আবশ্যক ব্যবহার করা যেতে)।

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

Comments

এটি সার্টিফিকেটটি মেইল ​​ডোমেনের জন্য হলে ভাল লাগবে - তবে ডিআইএনএসইসিকে মূলত এমআইটিএম এড়াতে হবে না।

— Andreas Krey

Answer 4

আমি মনে করি যে বাস্তবে যা করা হয় তা অনুলিপি করা ভাল। আমি একটি ইয়াহু.কম ইমেল ঠিকানা চেক করেছি http://checktls.com ব্যবহার করে আশা করি, ইয়াহুতে, তারা তাদের হোস্টনাম এবং তাদের এমএক্স ডোমেনের জন্য একটি আলাদা ডোমেন ব্যবহার করেছে। সুতরাং, তাদের হোস্টনামটি একটি ইয়াহু ডট কম এবং তাদের এমএক্স ডোমেনটি ইয়াহুডনস নেট দিয়ে শেষ হয়

dig mx yahoo.com gives mta6.am0.yahoodns.net. among others

চেকটেলের ফলাফল: এসএসএল শংসাপত্র সিএন = এমএক্স ডোমেন (* .yahoodns.net)

আমি সিসকো দিয়ে একই কাজ করেছি এবং আমারও একই ফল পেয়েছে।

Answer 5

এসএসএল / টিএলএস এনক্রিপশনে ক্লায়েন্ট সর্বদা রিমোট মেশিনে "রিয়েল" / "ঘোষিত" হোস্টনামের মধ্যে চিঠিপত্র পরীক্ষা করে এবং তথ্যগুলি শংসাপত্রের মধ্যে থাকে।

সুতরাং, আপনার সম্ভবত foo.example.com সেট করা উচিত বা একটি ওয়াইল্ডকার্ড শংসাপত্র তৈরি করা উচিত ;-)

Comments

আমি এটা সঠিক মনে করি না।

— ম্যাগগ্রাভেন

আমি আমার উত্তর উন্নতি করব। আমার মেইল ​​সার্ভারে, যদি আমি উদাহরণস্বরূপ আমার হোস্ট সার্ভারের সাথে সংযোগ স্থাপন করতে চাই: mx1.dn.tld এবং অন্য একটি সার্ভার উদাহরণস্বরূপ: foo.dn.tld এখানে, আমাকে হোস্টনাম mx1 সহ একটি SSL সার্ট তৈরি করতে হবে .dn.tld। এখন, যদি আপনার কাছে কোনও মেইল ​​সার্ভার থাকে যা আপনি যেমন IMAP হিসাবে বহিরাগত মান অ্যাক্সেস ব্যবহার করে অন্যান্য পরিষেবাদি থেকে অ্যাক্সেসযোগ্য হতে চান, তবে আপনি নীচের ডিএনএস উপন্যাসটি সেট করবেন: imap.dn.tld যা কোনও আইপি বা অন্য হোস্টনাম (এমএক্স 1) এর সাথে লিঙ্ক করে। উদাহরণস্বরূপ dn.tld)। এবং তারপরে এই imap.dn.tld হোস্টনামটি ব্যবহার করে একটি এসএসএল শংসাপত্র তৈরি করুন।

— ডাঃ আমি

হ্যাঁ, তবে প্রশ্নটি আইএমএপি / পিওপি 3 অ্যাক্সেস সম্পর্কে নয়, এটি ছিল এসএমটিপি-র সাথে মেল সরবরাহ সম্পর্কে।

— ম্যাগজিওরভেন