HTTP سے HTTPS تک

مواد:

• تعارف
• جاوا میں ویب ایپلیکیشن
• HTTPS کے لیے تقاضے
• کی مینیجر
• سرٹیفکیٹ کا انتظام
• نیچے کی لکیر

تعارف

جدید دنیا میں، آپ ویب ایپلیکیشنز کے بغیر نہیں رہ سکتے۔ اور ہم ایک چھوٹے سے تجربے کے ساتھ شروع کریں گے۔ بچپن میں، مجھے یاد ہے کہ کس طرح تمام اسٹالز نے "دلائل اور حقائق" نامی اخبار فروخت کیا تھا۔ میں نے انہیں اس لیے یاد کیا کہ بچپن سے میرے ذاتی خیال کے مطابق یہ اخبارات ہمیشہ عجیب لگتے تھے۔ اور میں نے فیصلہ کیا کہ کیا ہمیں ان کی ویب سائٹ پر جانا چاہیے: اگر ہم گوگل کروم ہیلپ پر جاتے ہیں، تو ہم پڑھیں گے کہ یہ سائٹ محفوظ کنکشن استعمال نہیں کرتی ہے اور آپ جو معلومات سائٹ کے ساتھ تبادلہ کرتے ہیں وہ فریق ثالث کے لیے قابل رسائی ہو سکتی ہے۔ آئیے کچھ دوسری خبریں دیکھیں، مثال کے طور پر سینٹ پیٹرزبرگ کی خبریں فونٹینکا سے، ایک الیکٹرانک میڈیا: جیسا کہ آپ دیکھ سکتے ہیں، Fontanka ویب سائٹ کو ان ڈیٹا کی بنیاد پر کوئی حفاظتی مسئلہ نہیں ہے۔ یہ پتہ چلتا ہے کہ ویب وسائل محفوظ ہو سکتے ہیں یا نہیں۔ ہم یہ بھی دیکھتے ہیں کہ غیر محفوظ وسائل تک رسائی HTTP پروٹوکول کے ذریعے ہوتی ہے۔ اور اگر وسائل محفوظ ہیں، تو ڈیٹا کا تبادلہ HTTPS پروٹوکول کا استعمال کرتے ہوئے کیا جاتا ہے، جہاں آخر میں S کا مطلب ہے "محفوظ"۔ HTTPS پروٹوکول کو rfc2818 تفصیلات میں بیان کیا گیا ہے: " HTTP اوور TLS "۔ آئیے اپنی ویب ایپلیکیشن بنانے کی کوشش کریں اور خود دیکھیں کہ یہ کیسے کام کرتی ہے۔ اور راستے میں ہم شرائط کو سمجھیں گے۔

جاوا میں ویب ایپلیکیشن

لہذا، ہمیں جاوا میں ایک بہت ہی آسان ویب ایپلیکیشن بنانے کی ضرورت ہے۔ سب سے پہلے، ہمیں خود جاوا ایپلیکیشن کی ضرورت ہے۔ ایسا کرنے کے لیے، ہم گریڈل پروجیکٹ کے خودکار تعمیراتی نظام کا استعمال کریں گے۔ یہ ہمیں دستی طور پر ضروری ڈائرکٹری ڈھانچہ بنانے کی اجازت نہیں دے گا + گریڈل ہمارے لیے پروجیکٹ کے لیے ضروری تمام لائبریریوں کا انتظام کرے گا اور اس بات کو یقینی بنائے گا کہ کوڈ پر عمل کرتے وقت وہ دستیاب ہوں۔ آپ ایک مختصر جائزہ میں گریڈل کے بارے میں مزید پڑھ سکتے ہیں: " گریڈل کا مختصر تعارف "۔ آئیے Gradle Init پلگ ان کا استعمال کریں اور کمانڈ چلائیں:

gradle init --type java-application

اس کے بعد، آئیے بلڈ اسکرپٹ کو کھولتے ہیں build.gradle، جس میں بتایا گیا ہے کہ ہمارا پروجیکٹ کن لائبریریوں پر مشتمل ہے، جو گریڈل ہمیں فراہم کرے گا۔ آئیے وہاں ویب سرور پر انحصار شامل کریں جس پر ہم تجربہ کریں گے:

dependencies {
    // Web server
    implementation 'io.undertow:undertow-core:2.0.20.Final'
     // Use JUnit test framework
     testImplementation 'junit:junit:4.12'
}

کسی ویب ایپلیکیشن کے کام کرنے کے لیے، ہمیں یقینی طور پر ایک ویب سرور کی ضرورت ہے جہاں ہماری ایپلیکیشن ہوسٹ کی جائے گی۔ ویب سرورز کی بہت بڑی قسمیں ہیں، لیکن اہم ہیں: ٹامکیٹ، جیٹی، انڈرٹو۔ اس بار ہم Undertow کا انتخاب کریں گے۔ یہ سمجھنے کے لیے کہ ہم اپنے اس ویب سرور کے ساتھ کیسے کام کر سکتے ہیں، آئیے انڈر ٹو کی آفیشل ویب سائٹ پر جائیں اور دستاویزات کے سیکشن پر جائیں ۔ آپ اور میں نے Undertow Core پر انحصار کو جوڑ دیا ہے، لہذا ہم اسی Core کے بارے میں سیکشن میں دلچسپی رکھتے ہیں ، یعنی کور، ویب سرور کی بنیاد۔ Undertow کے لیے Builder API کا استعمال کرنا سب سے آسان طریقہ ہے:

public static void main(String[] args) {
	Undertow server = Undertow.builder()
            .addHttpListener(8080, "localhost")
            .setHandler(new HttpHandler() {
                @Override
                public void handleRequest(final HttpServerExchange exchange) throws Exception {
                    exchange.getResponseHeaders().put(Headers.CONTENT_TYPE, "text/plain");
                    exchange.getResponseSender().send("Hello World");
                }
            }).build();
    server.start();
}

اگر ہم کوڈ پر عمل کرتے ہیں، تو ہم درج ذیل ویب وسائل پر جا سکتے ہیں: یہ آسانی سے کام کرتا ہے۔ Undertow Builder API کا شکریہ، ہم لوکل ہوسٹ اور پورٹ 8080 میں ایک HTTP سننے والے کو شامل کرتے ہیں۔ یہ سننے والا ویب براؤزر سے درخواستیں وصول کرتا ہے اور جواب میں "Hello World" سٹرنگ واپس کرتا ہے۔ زبردست ویب ایپلیکیشن۔ لیکن جیسا کہ ہم دیکھتے ہیں، ہم HTTP پروٹوکول استعمال کرتے ہیں، یعنی اس قسم کے ڈیٹا کا تبادلہ محفوظ نہیں ہے۔ آئیے یہ معلوم کریں کہ HTTPS پروٹوکول کا استعمال کرتے ہوئے تبادلے کیسے کیے جاتے ہیں۔

HTTPS کے لیے تقاضے

HTTPS کو فعال کرنے کا طریقہ سمجھنے کے لیے، آئیے HTTPS تفصیلات پر واپس آتے ہیں: " RFC-2818: HTTP اوور TLS "۔ تفصیلات کے مطابق، HTTPS پروٹوکول میں موجود ڈیٹا کو کرپٹوگرافک پروٹوکول SSL یا TLS پر منتقل کیا جاتا ہے۔ لوگ اکثر SSL اور TLS کے تصور سے گمراہ ہوتے ہیں۔ درحقیقت، SSL نے اپنے ورژن تیار کیے ہیں اور تبدیل کیے ہیں۔ بعد میں، TLS SSL پروٹوکول کی ترقی کا اگلا مرحلہ بن گیا۔ یعنی، TLS محض SSL کا ایک نیا ورژن ہے۔ تفصیلات اس طرح کہتی ہیں: "SSL، اور اس کا جانشین TLS"۔ لہذا، ہم نے سیکھا کہ SSL/TLS کرپٹوگرافک پروٹوکول موجود ہیں۔ SSL Secure Sockets Layer کا مخفف ہے اور "محفوظ ساکٹ لیئر" کے طور پر ترجمہ کرتا ہے۔ انگریزی سے ترجمہ کردہ ساکٹ ایک کنیکٹر ہے۔ نیٹ ورک پر ڈیٹا ٹرانسمیشن میں حصہ لینے والے نیٹ ورک پر ایک دوسرے کے ساتھ بات چیت کرنے کے لیے ساکٹ کو پروگرامنگ انٹرفیس (یعنی ایک API) کے طور پر استعمال کرتے ہیں۔ براؤزر کلائنٹ کے طور پر کام کرتا ہے اور کلائنٹ ساکٹ استعمال کرتا ہے، اور سرور جو درخواست وصول کرتا ہے اور جواب جاری کرتا ہے وہ سرور ساکٹ استعمال کرتا ہے۔ اور ان ساکٹ کے درمیان ڈیٹا کا تبادلہ ہوتا ہے۔ اسی لیے پروٹوکول کو اصل میں SSL کہا جاتا تھا۔ لیکن وقت گزرتا گیا اور پروٹوکول تیار ہوتا گیا۔ اور ایک موقع پر، SSL پروٹوکول TLS پروٹوکول بن گیا۔ TLS ٹرانسپورٹ لیئر سیکیورٹی کے لیے مختصر ہے۔ TLS پروٹوکول، بدلے میں، SSL پروٹوکول تفصیلات ورژن 3.0 پر مبنی ہے۔ TLS پروٹوکول علیحدہ مضامین اور جائزوں کا موضوع ہے، اس لیے میں صرف ان مواد کی نشاندہی کروں گا جو مجھے دلچسپ لگے:

• TLS اور SSL: کم از کم درکار
• TLS/SSL تکنیکی حوالہ
• TLS کیا ہے؟
• کلیدیں، سائفرز، پیغامات: TLS کیسے کام کرتا ہے۔

مختصراً، HTTPS کی بنیاد اس کے ڈیجیٹل سرٹیفکیٹ کا استعمال کرتے ہوئے TLS ہینڈ شیک اور "سرور آئیڈینٹیٹی" چیک (یعنی سرور کی شناخت) ہے۔ یہ ضروری ہے کہ. آئیے اسے یاد رکھیں، کیونکہ... ہم بعد میں اس حقیقت کی طرف لوٹیں گے۔ لہذا، پہلے ہم سرور کو یہ بتانے کے لیے HttpListener استعمال کرتے تھے کہ HTTP پروٹوکول پر کیسے کام کیا جائے۔ اگر اوپر کی مثال میں ہم نے HTTP پر کام کرنے کے لیے ایک HttpListener شامل کیا ہے، تو HTTPS پر کام کرنے کے لیے ہمیں ایک HttpsListener شامل کرنے کی ضرورت ہے: لیکن اسے شامل کرنے کے لیے ہمیں SSLContext کی ضرورت ہے۔ دلچسپ بات یہ ہے کہ، SSLContext Undertow کی کلاس نہیں ہے، لیکن javax.net.ssl.SSLContext. SSLContext کلاس نام نہاد " جاوا سیکیور ساکٹ ایکسٹینشن " (JSSE) کا حصہ ہے - انٹرنیٹ کنکشن کی حفاظت کو یقینی بنانے کے لیے ایک جاوا ایکسٹینشن۔ اس توسیع کو " جاوا سیکیور ساکٹ ایکسٹینشن (JSSE) حوالہ گائیڈ " میں بیان کیا گیا ہے ۔ جیسا کہ آپ دستاویزات کے تعارفی حصے سے دیکھ سکتے ہیں، JSSE SSL اور TLS پروٹوکول کا ایک فریم ورک اور Java نفاذ فراہم کرتا ہے۔ ہم SSLCcontext کیسے حاصل کرتے ہیں؟ JavaDoc SSLContext کھولیں اور getInstance طریقہ تلاش کریں ۔ جیسا کہ آپ دیکھ سکتے ہیں، SSLCcontext حاصل کرنے کے لیے ہمیں "Secure Socket Protocol" کا نام بتانا ہوگا۔ پیرامیٹرز کی تفصیل بتاتی ہے کہ یہ نام " جاوا کریپٹوگرافی آرکیٹیکچر سٹینڈرڈ الگورتھم نام دستاویزی " میں مل سکتے ہیں۔ لہذا، آئیے ہدایات پر عمل کریں اور دستاویزات پر جائیں۔ اور ہم دیکھتے ہیں کہ ہم SSL اور TLS کے درمیان انتخاب کر سکتے ہیں: اب ہم سمجھتے ہیں کہ ہمیں SSLCcontext کو مندرجہ ذیل بنانے کی ضرورت ہے:

public SSLContext getSSLContext() {
	// 1. Получаем контекст, в рамках которого будем работать по TLS протоколу
	SSLContext context = null;
	try {
		context = SSLContext.getInstance("TLS");
	} catch (NoSuchAlgorithmException e) {
		throw new IllegalStateException(e);
	}
	return context;
}

ایک نیا سیاق و سباق بنانے کے بعد، ہمیں یاد ہے کہ SSLContext کو " جاوا سیکیور ساکٹ ایکسٹینشن (JSSE) حوالہ گائیڈ " میں بیان کیا گیا تھا۔ ہم پڑھتے اور دیکھتے ہیں کہ "ایک نئے بنائے گئے SSLCcontext کو init طریقہ کو کال کرکے شروع کیا جانا چاہئے"۔ یعنی سیاق و سباق پیدا کرنا کافی نہیں ہے۔ اسے شروع کرنے کی ضرورت ہے۔ اور یہ منطقی ہے، کیونکہ سیکورٹی کے بارے میں، ہم نے آپ کو صرف یہ بتایا کہ ہم TLS پروٹوکول استعمال کرنا چاہتے ہیں۔ SSLCcontext کو شروع کرنے کے لیے ہمیں تین چیزیں فراہم کرنے کی ضرورت ہے: KeyManager، TrustManager، SecureRandom۔

کی مینیجر

کی مینجر ایک کلیدی مینیجر ہے۔ وہ اس بات کا ذمہ دار ہے کہ ہم سے رابطہ کرنے والے کو کیا "توثیق کی سند" فراہم کرے۔ اسناد کا ترجمہ شناخت کے طور پر کیا جا سکتا ہے۔ شناخت کی ضرورت ہے تاکہ کلائنٹ کو یقین ہو کہ سرور وہی ہے جس کا وہ دعویٰ کرتا ہے اور اس پر بھروسہ کیا جا سکتا ہے۔ شناخت کے طور پر کیا استعمال کیا جائے گا؟ جیسا کہ ہمیں یاد ہے، سرور کی شناخت کی تصدیق سرور کے ڈیجیٹل سرٹیفکیٹ سے ہوتی ہے۔ اس عمل کی نمائندگی اس طرح کی جا سکتی ہے: مزید برآں، " JSSE حوالہ گائیڈ: SSL کیسے کام کرتا ہے " کہتا ہے کہ SSL "غیر متناسب خفیہ نگاری" استعمال کرتا ہے، جس کا مطلب ہے کہ ہمیں کلیدی جوڑے کی ضرورت ہے: ایک عوامی کلید اور ایک نجی کلید۔ چونکہ ہم کرپٹوگرافی کے بارے میں بات کر رہے ہیں، "جاوا کرپٹوگرافی آرکیٹیکچر" (JCA) کام میں آتا ہے۔ اوریکل اس فن تعمیر پر ایک بہترین دستاویز فراہم کرتا ہے: " جاوا کرپٹوگرافی آرکیٹیکچر (JCA) حوالہ گائیڈ "۔ اس کے علاوہ، آپ JavaRush پر JCA کا ایک مختصر جائزہ پڑھ سکتے ہیں: " Java Cryptography Architecture: First واقفیت ۔" لہذا، KeyManager کو شروع کرنے کے لیے، ہمیں ایک KeyStore کی ضرورت ہے، جو ہمارے سرور کا سرٹیفکیٹ محفوظ کرے گا۔ کلید اور سرٹیفکیٹ اسٹور بنانے کا سب سے عام طریقہ کی ٹول یوٹیلیٹی ہے، جو JDK کے ساتھ شامل ہے۔ ایک مثال JSSE دستاویزات میں دیکھی جا سکتی ہے: " JSSE کے ساتھ استعمال کرنے کے لیے ایک کیسٹور بنانا "۔ لہذا، ہمیں کلیدی اسٹور بنانے اور وہاں سرٹیفکیٹ لکھنے کے لیے کی ٹول یوٹیلیٹی استعمال کرنے کی ضرورت ہے۔ دلچسپ بات یہ ہے کہ کلیدی نسل کو پہلے -genkey کا استعمال کرتے ہوئے مخصوص کیا گیا تھا، لیکن اب اسے -genkeypair استعمال کرنے کی سفارش کی جاتی ہے۔ ہمیں مندرجہ ذیل چیزوں کی وضاحت کرنے کی ضرورت ہوگی:

• عرف : عرف یا صرف وہ نام جس کے تحت اندراج کیسٹور میں محفوظ کیا جائے گا۔
keyalg : کلیدی خفیہ کاری الگورتھم۔ آئیے RSA الگورتھم کا انتخاب کریں، جو ہمارے مقصد کے لیے بنیادی طور پر ایک معیاری حل ہے۔
• keysize : کلیدی سائز (بٹس میں)۔ کم از کم تجویز کردہ سائز 2048 ہے، کیونکہ... ایک چھوٹا سائز پہلے ہی ٹوٹ چکا ہے۔ آپ یہاں مزید پڑھ سکتے ہیں: " 2048 بٹ میں ایس ایس ایل سرٹیفکیٹ "۔
• dname : ممتاز نام، ممتاز نام۔

یہ سمجھنا ضروری ہے کہ درخواست کردہ وسیلہ (مثال کے طور پر، https://localhost) کا موازنہ اس سے کیا جائے گا۔ اسے "سبجیکٹ سی این میچنگ" کہا جاتا ہے۔

• میعاد : ان دنوں کی مدت جس کے دوران تیار کردہ سرٹیفکیٹ درست ہے، یعنی درست
• ext : سرٹیفکیٹ ایکسٹینشن " نامزد ایکسٹینشنز " میں بیان کی گئی ہے۔

خود دستخط شدہ سرٹیفکیٹس کے لیے (یعنی آزادانہ طور پر بنائے گئے سرٹیفکیٹس کے لیے)، آپ کو درج ذیل ایکسٹینشنز کی وضاحت کرنی ہوگی:

• -ext san:critical=dns:localhost,ip:127.0.0.1 > SubjectAlternativeName کے ذریعے موضوع کی مماثلت انجام دینے کے لیے
• -ext bc=ca:false > یہ بتانے کے لیے کہ یہ سرٹیفکیٹ دوسرے سرٹیفکیٹ پر دستخط کرنے کے لیے استعمال نہیں ہوتا ہے۔

آئیے کمانڈ چلائیں (ونڈوز OS کے لیے مثال):

keytool -genkeypair -alias ssl -keyalg RSA -keysize 2048 -dname "CN=localhost,OU=IT,O=Javarush,L=SaintPetersburg,C=RU,email=contact@email.com" -validity 90 -keystore C:/keystore.jks -storepass passw0rd -keypass passw0rd -ext san:critical=dns:localhost,ip:127.0.0.1 -ext bc=ca:false

کیونکہ فائل بن جائے گی، یقینی بنائیں کہ آپ کے پاس فائل بنانے کے تمام حقوق ہیں۔ اس کے علاوہ، آپ کو ممکنہ طور پر اس طرح کے مشورے نظر آئیں گے: یہاں ہمیں بتایا گیا ہے کہ JKS ایک ملکیتی شکل ہے۔ ملکیتی کا مطلب ہے کہ یہ مصنفین کی نجی ملکیت ہے اور صرف جاوا میں استعمال کے لیے ہے۔ فریق ثالث کی افادیت کے ساتھ کام کرتے وقت، تنازعہ پیدا ہو سکتا ہے، جس کی وجہ سے ہمیں متنبہ کیا جاتا ہے۔ اس کے علاوہ، ہمیں غلطی موصول ہو سکتی ہے: The destination pkcs12 keystore has different storepass and keypass. یہ خرابی اس لیے پیش آتی ہے کیونکہ کیسٹور میں اندراج کے لیے اور خود کی اسٹور کے پاس ورڈ مختلف ہیں۔ جیسا کہ کلیدی ٹول دستاویزات کہتی ہیں ، "مثال کے طور پر، زیادہ تر فریق ثالث ٹولز کو PKCS #12 کی اسٹور میں ایک جیسا ہونے کے لیے اسٹور پاس اور کی پاس کی ضرورت ہوتی ہے۔" ہم خود کلید کی وضاحت کر سکتے ہیں (مثال کے طور پر، -destkeypass entrypassw)۔ لیکن بہتر ہے کہ تقاضوں کی خلاف ورزی نہ کریں اور ایک ہی پاس ورڈ سیٹ کریں۔ لہذا درآمد اس طرح نظر آسکتی ہے:

keytool -importkeystore -srckeystore C:/keystore.jks -destkeystore C:/keystore.jks -deststoretype pkcs12

کامیابی کی مثال: سرٹیفکیٹ کو فائل میں ایکسپورٹ کرنے کے لیے، آپ چلا سکتے ہیں:

keytool -export -alias ssl -storepass passw0rd -file C:/server.cer -keystore C:/keystore.jks

مزید برآں، ہم کیسٹور کے مواد کو اس طرح حاصل کر سکتے ہیں:

keytool -list -v -keystore C:/keystore.jks -storepass passw0rd

بہت اچھا، اب ہمارے پاس ایک کی اسٹور ہے جس میں سرٹیفکیٹ موجود ہے۔ اب آپ اسے کوڈ سے حاصل کر سکتے ہیں:

public KeyStore getKeyStore() {
	// Согласно https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#KeyStore
	try(FileInputStream fis = new FileInputStream("C:/keystore.jks")){
		KeyStore keyStore = KeyStore.getInstance("pkcs12");
		keyStore.load(fis, "passw0rd".toCharArray());
		return keyStore;
	} catch (IOException ioe) {
		throw new IllegalStateException(ioe);
	} catch (KeyStoreException | NoSuchAlgorithmException | CertificateException e) {
		throw new IllegalStateException(e);
	}
}

اگر کوئی کی اسٹور ہے، تو ہم کی مینجر کو شروع کر سکتے ہیں:

public KeyManager[] getKeyManagers(KeyStore keyStore) {
	String keyManagerAlgo = KeyManagerFactory.getDefaultAlgorithm();
	KeyManagerFactory keyManagerFactory = null;
	try {
		keyManagerFactory = KeyManagerFactory.getInstance(keyManagerAlgo);
		keyManagerFactory.init(keyStore, "passw0rd".toCharArray());
		return keyManagerFactory.getKeyManagers();
	} catch (NoSuchAlgorithmException e) {
		throw new IllegalStateException(e);
	} catch (UnrecoverableKeyException | KeyStoreException e) {
		throw new IllegalStateException(e);
	}
}

ہمارا پہلا مقصد حاصل ہو گیا ہے۔ یہ معلوم کرنا باقی ہے کہ TrustManager کیا ہے۔ ٹرسٹ مینجر کو JSSE دستاویزات میں سیکشن " The TrustManager Interface " میں بیان کیا گیا ہے۔ یہ KeyManager سے بہت ملتا جلتا ہے، لیکن اس کا مقصد یہ جانچنا ہے کہ آیا کنکشن کی درخواست کرنے والے شخص پر بھروسہ کیا جا سکتا ہے۔ اسے دو ٹوک الفاظ میں کہنے کے لیے، یہ ریورس میں KeyManager ہے =) ہمیں TrustManager کی ضرورت نہیں ہے، لہذا ہم null پاس کر دیں گے۔ اس کے بعد ایک ڈیفالٹ TrustManager بنایا جائے گا جو ہمارے سرور پر آخری صارف کی درخواستوں کی تصدیق نہیں کرتا ہے۔ دستاویزات اس طرح کہتی ہیں: "پہلے سے طے شدہ نفاذ کا استعمال کیا جائے گا"۔ SecureRandom کے ساتھ بھی ایسا ہی۔ اگر ہم null کی وضاحت کرتے ہیں، تو پہلے سے طے شدہ نفاذ کا استعمال کیا جائے گا۔ آئیے صرف یاد رکھیں کہ SecureRandom ایک JCA کلاس ہے اور JCA دستاویزات میں " The SecureRandom Class " کے حصے میں بیان کیا گیا ہے۔ مجموعی طور پر، اوپر بیان کردہ تمام طریقوں کو مدنظر رکھتے ہوئے تیاری اس طرح نظر آسکتی ہے:

public static void main(String[] args) {
	// 1. Подготавливаем приложение к работе по HTTPS
	App app = new App();
	SSLContext sslContext = app.getSSLContext();
	KeyStore keyStore = app.getKeyStore();
	KeyManager[] keyManagers = app.getKeyManagers(keyStore);
	try {
		sslContext.init(keyManagers, null, null);
	} catch (KeyManagementException e) {
		throw new IllegalStateException(e);
	}

جو کچھ باقی ہے وہ سرور کو شروع کرنا ہے:

// 2. Поднимаем server
 	int httpsPort = 443;
	Undertow server = Undertow.builder()
            .addHttpsListener(httpsPort, "localhost", sslContext)
            .setHandler(new HttpHandler() {
                @Override
                public void handleRequest(final HttpServerExchange exchange) throws Exception {
                    exchange.getResponseHeaders().put(Headers.CONTENT_TYPE, "text/plain");
                    exchange.getResponseSender().send("Hello World");
                }
            }).build();
	server.start();
}

اس بار ہمارا سرور درج ذیل پتے پر دستیاب ہوگا۔ https://localhost:443 تاہم، ہمیں پھر بھی ایک غلطی موصول ہوگی کہ اس وسائل پر بھروسہ نہیں کیا جاسکتا: آئیے معلوم کریں کہ سرٹیفکیٹ میں کیا خرابی ہے اور اس کے بارے میں کیا کرنا ہے۔

سرٹیفکیٹ کا انتظام

لہذا، ہمارا سرور پہلے سے ہی HTTPS کے ذریعے کام کرنے کے لیے تیار ہے، لیکن کلائنٹ کو اس پر بھروسہ نہیں ہے۔ کیوں؟ آئیے ایک نظر ڈالتے ہیں: وجہ یہ ہے کہ یہ سرٹیفکیٹ خود دستخط شدہ سرٹیفکیٹ ہے۔ ایک خود دستخط شدہ SSL سرٹیفکیٹ سے مراد ایک عوامی کلید کا سرٹیفکیٹ ہوتا ہے جو اسی شخص کی طرف سے جاری اور دستخط کیا جاتا ہے جس کی وہ شناخت کرتا ہے۔ یعنی، اسے کسی بھی قابل احترام سرٹیفیکیشن اتھارٹی (CA، جسے سرٹیفکیٹ اتھارٹی بھی کہا جاتا ہے) نے جاری نہیں کیا تھا۔ سرٹیفکیٹ اتھارٹی ایک ٹرسٹی کے طور پر کام کرتی ہے اور روزمرہ کی زندگی میں نوٹری کی طرح ہے۔ وہ یقین دلاتا ہے کہ وہ جو سرٹیفکیٹ جاری کرتا ہے وہ قابل اعتماد ہے۔ ایسے CAs کے ذریعہ سرٹیفکیٹ جاری کرنے کی خدمت ادا کی جاتی ہے، اس لیے کسی کو بھی اعتماد میں کمی اور شہرت کے خطرات کی ضرورت نہیں ہے۔ پہلے سے طے شدہ طور پر، کئی سرٹیفکیٹ اتھارٹیز ہیں جو قابل بھروسہ ہیں۔ یہ فہرست قابل تدوین ہے۔ اور ہر آپریٹنگ سسٹم کے پاس سرٹیفیکیشن حکام کی فہرست کا اپنا انتظام ہے۔ مثال کے طور پر، ونڈوز میں اس فہرست کا نظم کرنا یہاں پڑھا جا سکتا ہے: " ونڈوز میں ٹرسٹڈ روٹ سرٹیفکیٹس کا نظم کریں "۔ آئیے سرٹیفکیٹ کو بھروسہ مندوں میں شامل کریں جیسا کہ ایرر میسج میں اشارہ کیا گیا ہے۔ ایسا کرنے کے لیے، پہلے سرٹیفکیٹ ڈاؤن لوڈ کریں: OS ونڈوز میں، Win+R دبائیں اور mmcکنٹرول کنسول کو کال کرنے کے لیے عمل کریں۔ اگلا، موجودہ کنسول میں "سرٹیفکیٹس" سیکشن شامل کرنے کے لیے Ctrl+M دبائیں۔ اگلا، سب سیکشن "ٹرسٹڈ روٹ سرٹیفیکیشن اتھارٹیز" میں ہم عمل کریں گے Действия / Все задачи / Импорт۔ آئیے اس فائل کو درآمد کرتے ہیں جو پہلے ڈاؤن لوڈ کی گئی تھی۔ ہو سکتا ہے براؤزر نے سرٹیفکیٹ کی ماضی کی ٹرسٹ سٹیٹ کو یاد کر لیا ہو۔ لہذا، صفحہ کھولنے سے پہلے آپ کو براؤزر کو دوبارہ شروع کرنے کی ضرورت ہے۔ مثال کے طور پر، ایڈریس بار میں گوگل کروم میں آپ کو چلانے کی ضرورت ہے chrome://restart۔ OS ونڈوز میں، آپ سرٹیفکیٹ دیکھنے کے لیے یوٹیلیٹی بھی استعمال کر سکتے ہیں certmgr.msc: اگر ہم نے سب کچھ صحیح طریقے سے کیا، تو ہم HTTPS کے ذریعے اپنے سرور پر ایک کامیاب کال دیکھیں گے۔ جیسا کہ آپ دیکھ سکتے ہیں، سرٹیفکیٹ کو اب درست سمجھا جاتا ہے، وسیلہ دستیاب ہے، اور کوئی خرابی نہیں ہے۔

نیچے کی لکیر

لہذا ہم نے یہ معلوم کیا ہے کہ ویب سرور پر HTTPS پروٹوکول کو فعال کرنے کی اسکیم کیسی ہے اور اس کے لیے کیا ضرورت ہے۔ مجھے امید ہے کہ اس مقام پر یہ واضح ہے کہ جاوا کریپٹوگرافی آرکیٹیکچر (JCA) کے تعامل سے مدد فراہم کی گئی ہے، جو کہ کرپٹوگرافی کے لیے ذمہ دار ہے، اور Java Secure Socket Extension (JSSE)، جو جاوا کی طرف TLS کا نفاذ فراہم کرتا ہے۔ ہم نے دیکھا کہ کس طرح JDK میں شامل کی ٹول یوٹیلیٹی کو KeyStore کلید اور سرٹیفکیٹ اسٹور کے ساتھ کام کرنے کے لیے استعمال کیا جاتا ہے۔ مزید برآں، ہم نے محسوس کیا کہ HTTPS سیکورٹی کے لیے SSL/TLS پروٹوکول استعمال کرتا ہے۔ اس کو تقویت دینے کے لیے، میں آپ کو اس موضوع پر بہترین مضامین پڑھنے کا مشورہ دیتا ہوں:

• TLS اور SSL: کم از کم علم درکار ہے۔
• کلیدیں، سائفرز، پیغامات: TLS کیسے کام کرتا ہے۔
• غیر متناسب خفیہ کاری۔ یہ کیسے کام کرتا ہے؟

امید ہے کہ اس چھوٹے سے جائزے کے بعد، HTTPS قدرے شفاف ہو جائے گا۔ اور اگر آپ کو HTTPS کو فعال کرنے کی ضرورت ہے، تو آپ اپنے ایپلیکیشن سرورز اور فریم ورک کی دستاویزات سے شرائط کو آسانی سے سمجھ سکتے ہیں۔ #ویاچسلاو