এটি কি https এ পুনর্নির্দেশ করা খারাপ?

Question

আমি আমার সার্ভারে একটি এসএসএল শংসাপত্র ইনস্টল করেছি।

এটি তখন পোর্ট 80 এ আমার ডোমেনে সমস্ত ট্র্যাফিকের জন্য এটিকে 443 পোর্টে পুনর্নির্দেশের জন্য পুনর্নির্দেশ সেটআপ করে।

অন্য কথায়, আমার সমস্ত http://example.comট্র্যাফিক এখন https://example.comপৃষ্ঠার উপযুক্ত সংস্করণে পুনঃনির্দেশিত হয়েছে ।

পুনর্নির্দেশটি আমার অ্যাপাচি ভার্চুয়াল হোস্ট ফাইলগুলিতে এরকম কিছু দিয়ে করা হয় ...

RewriteEngine on
ReWriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R,L] 

আমার প্রশ্ন হ'ল এসএসএল ব্যবহারে কোনও ত্রুটি আছে কি?

যেহেতু এটি 301 পুনর্নির্দেশ নয়, তাই আমি কি স্যুইচ করে ইঞ্জিনগুলিতে লিঙ্ক জুস / র‌্যাঙ্কিং হারাব https?

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

---

আপডেট করা বিষয়

আশ্চর্যজনকভাবে বিং এখন আমার সাইট থেকে এই স্ক্রিনশটটি তৈরি করে যে এটি যে কোনও জায়গায় HTTPS ব্যবহার করছে ...

Comments

[ডব্লিউটিএফ -। আমি উত্তর যোগ করতে পারবেন না (মনে হয় যদিও আমি যথেষ্ট প্রতিনিধির আছে)] আমার উত্তর (কিছু অংশ) হবে যে কখনও কখনও এটি খারাপ । এইচটিটিপিতে জিইটি-তে একটি কুকি বা এপিআই কী পাস করার কথা বিবেচনা করুন। যদি আপনার সাইটটি এইচটিটিপি অনুরোধগুলিকে এইচটিটিপিএস অনুরোধগুলিতে পুনঃনির্দেশ করে, তবে এই কলগুলি কাজ করবে তবে COOKIE বা API কী স্পষ্ট - উন্মুক্ত হয়ে প্রেরণ করা হবে। কিছু এপিআই এইচটিটিপি বন্ধ করে দেয়, আরও শক্তিশালী পদ্ধতির - কোনও এইচটিটিপি মোটেও এমন নয় যাতে আপনি এইচটিটিপিএস ব্যবহার না করা পর্যন্ত এটি কাজ করতে পারবেন না। উদাহরণ: "সকল API অনুরোধে HTTPS দ্বারা উপর তৈরি করা আবশ্যক প্লেইন HTTP- র মাধ্যমে কলের ব্যর্থ হবে।" এর থেকে stripe.com/docs/api?lang=php#authentication

— codingoutloud

@ কোডিংআউটলৌড - বিকল্পটি হ'ল এইচটিটিপিএস-তে কোনও কিছুই এইচটিটিপিএস ছাড়াই পুরো জিনিসটি ঘটে। এটা আরও ভাল কিভাবে?

— মার্ক হেন্ডারসন

@BenCrowell, যে কারণে এর ক্যাপটিভ পোর্টাল একটি মত একটি ভয়াবহ অনেক দেখায় sslstrip-style পুনর্নির্দেশ হামলা (তারা উভয় ম্যান-ইন--মধ্য অনুরোধ hijacks) যাতে HSTS -aware ব্রাউজার তাদের উভয় অবরুদ্ধ করবে।

— জেফ্রি হ্যান্টিন

সচেতন থাকুন যে https ব্যবহারের অর্থ হ'ল আপনার অন্তর্ভুক্ত করা সমস্ত কিছুও https হওয়া উচিত বা এটি লোড নাও হতে পারে - উদাহরণস্বরূপ লোড জ্যাকুইরি src="://example.com/jquery.js"- অভাবটি লক্ষ্য করুন httpবা httpsতাই ব্রাউজার উপযুক্তটিকে লোড করে। এপিআই (https- র মাধ্যমে লোড করা) HTTP লিঙ্কগুলি সঠিকভাবে লোড করার জন্য আমার কিছু এমবেডড অ্যামাজন স্টাফ আনার চেষ্টা করার একটি স্বপ্ন ছিল - যার অর্থ https লিঙ্কগুলিকে টগল করার জন্য অনাবন্ধিত প্যারামিটার না পাওয়া পর্যন্ত তারা সঠিকভাবে কাজ করে না

— বেসিক

জেসন; আপনার আপডেটটি একটি নতুন প্রশ্ন হওয়া উচিত, সম্ভবত ওয়েবমাস্টারগুলিতে এটি আপনার মূল প্রশ্নের সাথে সম্পর্কিত নয় (প্রযুক্তিগতভাবে)। তবে সম্ভবত আপনার স্টাইলের শীটগুলি কোনও সুরক্ষিত ডোমেন থেকে আসছে are

— মার্ক হেন্ডারসন

Answer 1

[R]তার নিজের উপর পতাকা একটি হল 302ফেরৎ ( Moved Temporarily)। যদি আপনি সত্যিই আপনার সাইটের এইচটিটিপিএস সংস্করণ ব্যবহার করতে চান (ইঙ্গিত: আপনি করেন) তবে আপনার [R=301]স্থায়ী পুনঃনির্দেশের জন্য ব্যবহার করা উচিত :

RewriteEngine on
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R=301,L] 

একটি 301আপনার সমস্ত গুগল-ফু এবং কঠোর উপার্জনযুক্ত পেজরঙ্কগুলি অক্ষত রাখে । mod_rewriteসক্ষমিত আছে তা নিশ্চিত করুন :

a2enmod rewrite

আপনার সঠিক প্রশ্নের উত্তর দিতে:

এটি কি https এ পুনর্নির্দেশ করা খারাপ?

কোনভাবেই না. এটা খুব ভালো.

Comments

তথ্যের জন্য ধন্যবাদ, আমার বস আমাকে তার সাইটের নির্দিষ্ট পৃষ্ঠাগুলিতে কেবল https চালানোর কারণটি বলছেন, এটি এটি প্রতিটি পৃষ্ঠায় চালানোর জন্য আরও অনেক সার্ভার সংস্থান ব্যবহার করে। আপনি কি সে সম্পর্কে কিছু জানেন বা যদি এটি সত্য হয়?

— জেসনডাভিস

@ জাসনডাভিস কেবলমাত্র যদি আপনি এটিটি অনুকূল করতে কয়েক মিনিট ব্যয় করেন না ।

— মাইকেল হ্যাম্পটন

"এটি প্রতিটি পৃষ্ঠায় এটি চালনার জন্য আরও অনেক বেশি সার্ভার সংস্থান ব্যবহার করে।" আধুনিক সিপিইউতে এনক্রিপশন ত্বরণ বৈশিষ্ট্য রয়েছে যা এসএসএলকে প্রায় মুক্ত করে তোলে। ওভারহেড সম্পর্কে চিন্তা করবেন না।

— অ্যাডাম ডেভিস

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

— 200_সাক্সেস

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

— জন হান্না

Answer 2

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

1. অভ্যন্তরীণ লিঙ্কগুলির জন্য পুরো সাইটটি যাচাই করুন এবং নিশ্চিত করুন যে আপনি লিঙ্কগুলিতে নিজের ডোমেনের নাম নির্দিষ্ট করে দিলে তারা সবাই এইচটিটিপিএস ব্যবহার করছে, যাতে আপনি নিজের নিজস্ব পুনর্নির্দেশগুলি ঘটাচ্ছেন না।
2. <meta property="og:url"আপনার ডোমেনের https সংস্করণটি ব্যবহার করে আপডেট করুন ।
3. আপনি যদি <base href=আবার ব্যবহার করেন এইচটিটিপিএস ব্যবহার করতে।
4. সম্ভব হলে এসপিডিওয়াই প্রোটোকল ইনস্টল করুন
5. অনুরোধের সংখ্যা হ্রাস করতে যেখানে সম্ভব সেখানে সিএসএস ইমেজ স্প্রিট ব্যবহার করা নিশ্চিত করুন।
6. Https স্থিতি নির্দেশ করতে আপনার সাইটম্যাপগুলি আপডেট করুন, তাই সময়ের সাথে সাথে মাকড়সা এই পরিবর্তনটি শিখবে।
7. এইচটিটিপিএস পছন্দ করতে গুগল ওয়েবমাস্টার সরঞ্জামগুলির মতো অনুসন্ধান ইঞ্জিনের পছন্দগুলি পরিবর্তন করুন
8. যেখানে সম্ভব এইচটিটিপিএস সিডিএন সার্ভারগুলিতে কোনও স্ট্যাকটিক মিডিয়া অফ-লোড।

যদি উপরের দিকে সম্বোধন করা হয় তবে আমি সন্দেহ করি আপনার অনেকগুলি সমস্যা হবে।

Comments

এসপিডিওয়াই একটি ভাল পরামর্শ; এমনকি অ্যাপাচি ২.এক্সে এসপিডিওয়াই সমর্থন যুক্ত করার ক্ষেত্রে একটি মডিউল উপস্থিত রয়েছে ।

— ক্যালরিওন

ব্যবহার "//yourserver.com/some-uri" পরিবর্তে " yourserver.com/some-uri " সমাধান করা সমস্যা (1) কারণ ব্রাউজার উপযুক্ত স্কিমা বাছাই হবে (http অথবা HTTPS) স্কিমা পৃষ্ঠার সাথে লোড করা হয়েছে তার উপর নির্ভর করে ।

— মাগানরা

@ মগগনআ অবশ্যই অবধি, এটি HTTP নিবন্ধ পৃষ্ঠা থেকে https লগইন পৃষ্ঠায় একটি লিঙ্ক, উদাহরণস্বরূপ।

— মোআওট

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

— স্টিফান কুল্লা

1) আমি সন্ধান করেছি এবং আমার মাইএসকিউএল ডাটাবেস HTTP- তে

— https- র

Answer 3

আমি আপনাকে https সেট আপ করেছি তারপরে আপনার এটি সাইটের যে কোনও জায়গায় ব্যবহার করা উচিত। আপনি মিশ্র বিষয়বস্তু সংক্রান্ত সমস্যার ঝুঁকি এড়াতে পারবেন এবং যদি আপনার কাছে প্রয়োজনীয় সরঞ্জামগুলি জায়গায় থাকে, তবে কেন পুরো সাইটটি সুরক্ষিত করবেন না?

HTTP থেকে https এ পুনঃনির্দেশের বিষয়ে উত্তরটি এত সহজ নয়।

পুনঃনির্দেশ আপনার ব্যবহারকারীদের পক্ষে এটি অনেক সহজ করে দেবে, তারা কেবল whateversite.com টাইপ করে এবং https এ পুনঃনির্দেশিত হয়।

কিন্তু। যদি ব্যবহারকারী কখনও কখনও কোনও অনিরাপদ নেটওয়ার্কে থাকে (বা ট্রয় হান্ট এবং তার আনারসের কাছাকাছি থাকে ) তবে কী হবে? তারপরে ব্যবহারকারীরা পুরাতন অভ্যাসের বাইরে http://whateversite.com অনুরোধ করবেন । তা হ'ল এইচ.পি. যে আপস করা যেতে পারে। পুনঃনির্দেশ https://whateversite.com.some.inf पाया . long.strange.url.hacker.org এ নির্দেশ করতে পারে । একটি সাধারণ ব্যবহারকারীর কাছে এটি বেশ আইনী মনে হবে। তবে ট্র্যাফিক আটকাতে পারে।

সুতরাং আমাদের এখানে দুটি প্রতিযোগিতামূলক প্রয়োজনীয়তা রয়েছে: ব্যবহারকারী বান্ধব হওয়া এবং সুরক্ষিত হওয়া। ভাগ্যক্রমে, এইচএসটিএস শিরোলেখ নামে একটি প্রতিকার রয়েছে । এটির সাহায্যে আপনি পুনঃনির্দেশ সক্ষম করতে পারেন। ব্রাউজারটি নিরাপদ সাইটে চলে যাবে, তবে এইচএসটিএস শিরোনামের জন্য ধন্যবাদ এটি মনে রাখে। যখন ব্যবহারকারী এই ধরণের অনিরাপদ নেটওয়ার্কে বসে whetversite.com এ টাইপ করেন, ব্রাউজারটি HTTP- র মাধ্যমে পুনঃনির্দেশের মাধ্যমে ঝাঁপ না দিয়ে সরাসরি https এ চলে যাবে। আপনি যদি খুব সংবেদনশীল ডেটা না নিয়ে থাকেন তবে আমি মনে করি এটি বেশিরভাগ সাইটের সুরক্ষা এবং ব্যবহারের মধ্যে ন্যায্য বাণিজ্য। (আমি যখন সম্প্রতি মেডিকেল রেকর্ডগুলি পরিচালনা করে এমন একটি অ্যাপ্লিকেশন সেটআপ করেছি তখন আমি কোনও পুনঃনির্দেশ ছাড়াই সমস্ত https এ গিয়েছিলাম)। দুর্ভাগ্যক্রমে ইন্টারনেট এক্সপ্লোরারের এইচএসটিএস ( উত্স) এর জন্য কোনও সমর্থন নেই), সুতরাং যদি আপনার টার্গেট শ্রোতারা বেশিরভাগই IE ব্যবহার করে থাকে এবং ডেটা সংবেদনশীল হয় তবে আপনি পুনর্নির্দেশগুলি অক্ষম করতে চাইতে পারেন।

সুতরাং আপনি যদি IE ব্যবহারকারীদের টার্গেট না করে থাকেন তবে এগিয়ে যান এবং পুনর্নির্দেশটি ব্যবহার করুন তবে এইচএসটিএস শিরোনামটিও সক্ষম করুন।

Comments

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

— Velox

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

— কোডিংআউটলৌড

@ কোডিংআউটলৌড এটি আমার বক্তব্য এইচটিটিপিএসের মাধ্যমে এগুলি এনক্রিপ্ট করা হয়েছে তবে HTTP পৃষ্ঠায় প্রাথমিক অনুরোধে তারা ছিল না।

— Velox

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

— ব্রিল্যান্ড

@ ব্রিলিয়ান্ড ফেয়ার পয়েন্ট, তবে সুরক্ষার একটি দুর্বল পয়েন্ট পুরো বিষয়টিকে দুর্বল করে দিয়েছে। সর্বদা বিবেচ্য মূল্যবান।

— Velox

Answer 4

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

<VirtualHost 10.2.3.40:80>
  ServerAdmin [e-mail]
  ServerName secure.example.com
  RedirectMatch 301 (.*) https://secure.example.com$1
</VirtualHost>

# Insert 10.2.3.40:443 virtual host here :)

301স্থিতি কোড একটি ইঙ্গিত স্থায়ী পুনর্নির্দেশ, সক্ষম ক্লায়েন্ট নির্দেশ (যেমন বুকমার্ক আপডেট করবেন) ভবিষ্যৎ সংযোগের নিরাপদ URL ব্যবহার করতে।

আপনি যদি কেবল টিএলএস / এসএসএল এর মাধ্যমে সাইট পরিবেশন করছেন, আমি আপনার সুরক্ষিত ভার্চুয়াল হোস্টে এইচটিটিপি স্ট্রাইক ট্রান্সপোর্ট সিকিউরিটি (এইচএসটিএস) সক্ষম করার জন্য আরও একটি নির্দেশের সুপারিশ করব :

<IfModule mod_headers.c>
  Header set Strict-Transport-Security "max-age=1234; includeSubdomains"
</IfModule>

এই শিরোনাম সক্ষম ক্লায়েন্টদের (তাদের বেশিরভাগ এই দিনগুলিতে, আমি বিশ্বাস করি) নির্দেশ দেয় যে তাদের কেবলমাত্রsecure.example.com পরবর্তী 1234সেকেন্ডের জন্য প্রদত্ত ডোমেন ( এই ক্ষেত্রে) দিয়ে এইচটিটিপিএস ব্যবহার করা উচিত । ; includeSubdomainsঅংশ ঐচ্ছিক এবং ইঙ্গিত করে যে নির্দেশ বর্তমান ডোমেনে না ই নেই, কিন্তু (যেমন অধীনে যে কোন alpha.secure.example.com)। নোট করুন যে এইচএসটিএস শিরোনামটি কেবল ব্রাউজারগুলির দ্বারা গ্রহণ করা হয় যখন কোনও এসএসএল / টিএলএস সংযোগের জন্য দেওয়া হয়!

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

Comments

আমার যোগ করা উচিত, হেডার পাঠানো Strict-Transport-Security: max-age=0কোনও পূর্ববর্তী নির্দেশকে অস্বীকার করবে; সর্বদা হিসাবে, এটি অবশ্যই এইচটিটিপিএস এর মাধ্যমে প্রেরণ করতে হবে, তবে আপনি যদি ডোমেনে HTTP ব্যবহার করারও সিদ্ধান্ত নেন তবে জিনিসগুলি বাতিল করার এটি একটি সহজ উপায়।

— ক্যালরিয়ন

Answer 5

কি দারুন ! এইচটিটিপিএসকে এইচটিটিপিএসে পুনর্নির্দেশ করা খুব ভাল জিনিস এবং আমি এর জন্য কোনও ত্রুটি দেখতে পাচ্ছি না।

ব্রাউজারে শংসাপত্র সম্পর্কে অ ব্যবহারকারীদের-বান্ধব সতর্কতা এড়াতে আপনার ক্লায়েন্টদের সঠিক সিএ রয়েছে তা নিশ্চিত করুন।

তদতিরিক্ত, এইচটিটিপিএসে আপনাকে পুনর্নির্দেশের জন্য অ্যাপাচি সেটআপ করার উপায়টি ঠিক আছে seems

Answer 6

এটি কি https এ পুনর্নির্দেশ করা খারাপ?

না কোনভাবেই না. আসলে, এটি করা ভাল জিনিস!

পুনঃনির্দেশগুলিতে:

পুনর্লিখনগুলি পুরোপুরি বাদ দিয়ে এটি আরও দক্ষ হতে পারে । অনুরূপ পরিস্থিতিতে আমার কনফিগারেশন এখানে ...

<VirtualHost *:80>
  ServerName domainname.com

  <IfModule mod_alias.c>
    Redirect permanent / https://domainname.com/
  </IfModule>
</VirtualHost>

Answer 7

এইচটিটিপিএস ঠিক হুবহু নয়। অবশ্যই, সাধারণত HTTPS জোর করা ভাল জিনিস। এটি সাধারণ অপরাধীদের আপনার ব্যবহারকারীদের খারাপ কিছু করতে বাধা দেয়।

তবে দয়া করে এসএসএল সিফারস সেটিংয়ের মতো আপনাকে এসএসএল সেটিংস পরীক্ষা করে দেখুন। আরসি 4 ক্রিপ্টো, এসএসএলভি 2 এবং এসএসএলভি 3 প্রোটোকলের মতো জিনিসগুলি অক্ষম করুন। এছাড়াও, আপনার সিস্টেমে ক্রিপ্টো-সিস্টেম লিবারিগুলি টিএলএস 1.2 সমর্থন করে কিনা (আপনার কাছে যা জিনিসটি চান তা হ'ল) ​​এটিও আপনার অনুসন্ধান করা উচিত)

এসএসএল চালু করুন, এটি একটি ভাল জিনিস।

Comments

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

— গিলস

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

— ম্যাডহ্যাটার

Answer 8

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

Comments

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

— হ্যাঙ্কান লিন্ডকভিস্ট

Answer 9

এখানে ব্রডস্ট্রোকের কয়েকটি বিস্তৃত সমস্যা রয়েছে:

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

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

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

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

Comments

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

— হাকান লিন্ডকভিস্ট

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

— ক্রেগ

.. এবং অবশ্যই আমি এইচএসটিএস ব্যবহারের সাথে আন্তরিকভাবে সম্মতি জানাই।

— ক্রেগ

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

— হ্যাঙ্কান লিন্ডকভিস্ট

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

— ক্রেগ

Answer 10

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

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

Answer 11

এইচটিটিপিএস-এর মাধ্যমে এইচটিটিপিএস-এ ফিরে আসা একমাত্র প্রযুক্তিগত অঙ্কনটি হ'ল সরল এইচটিটিপি-র চেয়ে এইচটিটিপিএস অনুরোধগুলি প্রক্রিয়াকরণ করা গণনাগতভাবে আরও ব্যয়বহুল is

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

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

Comments

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

— ক্রেগ 10

Answer 12

এটি https এ পুনঃনির্দেশ করা খুব ভাল তবে আপনি এটি পুনর্নির্দেশকে কীভাবে সংগঠিত করছেন তার উপরও এটি পড়েছি।

সিকিউরিটি.স্ট্যাকেক্সেঞ্জ ডটকমের উত্তরে দেওয়া পরামর্শ অনুসারে আগত HTTP অনুরোধগুলি আপনার https সংযোগে পুনর্নির্দেশের জন্য একটি উত্সর্গীকৃত ভার্চুয়াল সার্ভার তৈরি করা খুব স্মার্ট মনে হচ্ছে এবং কিছু অতিরিক্ত সুরক্ষা হুমকি বন্ধ করবে। অ্যাপাচে একটি কনফিগারেশন দেখতে এরকম কিছু দেখতে পাবে:

# Virtual host for rerouting
<VirtualHost *:80>
    ServerName www.example.com
    Redirect permanent / https://www.example.com/
</VirtualHost>

# Virtual host for secure hosting on https
<VirtualHost *:443>
    ServerName www.example.com
    SSLEngine on
    Header set Strict-Transport-Security "max-age=8640000;includeSubdomains"

    ...site settings...

</VirtualHost>