SSL Pinning: সারমর্ম, পদ্ধতি ও MITM আক্রমণ থেকে সুরক্ষা

SSL Pinning কী?

SSL Pinning একটি নিরাপত্তা পদ্ধতি যেখানে একটি মোবাইল বা ওয়েব অ্যাপ্লিকেশন একটি বিশ্বস্ত সার্ভার সার্টিফিকেট বা পাবলিক কী মনে রাখে এবং যেসব সংযোগের সার্টিফিকেট সংরক্ষিতটির সাথে মেলে না সেগুলো প্রত্যাখ্যান করে। স্ট্যান্ডার্ড HTTPS স্কিমে, ক্লায়েন্ট রুট CA পর্যন্ত বিশ্বাস শৃঙ্খলের মাধ্যমে সার্টিফিকেট যাচাই করে — যেকোনো CA যেকোনো ডোমেইনের জন্য সার্টিফিকেট স্বাক্ষর করতে পারে। SSL Pinning এই দুর্বলতা দূর করে: শত শত CA-তে বিশ্বাস করার পরিবর্তে, অ্যাপ্লিকেশন শুধুমাত্র একটি নির্দিষ্ট সার্টিফিকেটে বিশ্বাস করে।

স্ট্যান্ডার্ড যাচাইয়ের সমস্যা হল যে শত শত রুট CA-র যেকোনোটি আপনার ডোমেইনের জন্য একটি বৈধ সার্টিফিকেট ইস্যু করতে পারে — দুর্ঘটনাবশত বা জোর করে। একজন আক্রমণকারী যে নিজস্ব রুট সার্টিফিকেটসহ কর্পোরেট প্রক্সিতে অ্যাক্সেস পায়, ব্রাউজার সতর্কতা ছাড়াই একটি MITM আক্রমণ চালাতে পারে। SSL Pinning এই দুর্বলতা বন্ধ করে: এমনকি যদি কোনো CA জাল সার্টিফিকেট ইস্যু করে, অ্যাপ্লিকেশন তা প্রত্যাখ্যান করবে কারণ ফিঙ্গারপ্রিন্ট রেকর্ডকৃতটির সাথে মেলে না।

মোবাইল অ্যাপ্লিকেশনে SSL Pinning বিশেষভাবে গুরুত্বপূর্ণ কারণ ডিভাইসগুলি প্রায়ই অসুরক্ষিত নেটওয়ার্কে কাজ করে — পাবলিক Wi-Fi, ট্র্যাফিক পরিদর্শনসহ কর্পোরেট প্রক্সি, সংক্রমিত অ্যাক্সেস পয়েন্ট। Verizon Mobile Security Index (2025) অনুসারে, মোবাইল অ্যাপ্লিকেশনে 60%-এর বেশি ডেটা লঙ্ঘন ট্রান্সপোর্ট স্তরে ট্র্যাফিক আটকানোর সাথে সম্পর্কিত।

মোবাইল ডেভেলপমেন্টে SSL Pinning কেন প্রয়োজন

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

SSL Pinning কীভাবে কাজ করে?

SSL Pinning প্রক্রিয়াটি তিনটি ধাপ নিয়ে গঠিত: ফিঙ্গারপ্রিন্ট ক্যাপচার, সংযোগে যাচাই এবং ত্রুটি ব্যবস্থাপনা। ডেভেলপমেন্টের সময়, ইঞ্জিনিয়ার সার্ভার সার্টিফিকেটের SHA-256 ফিঙ্গারপ্রিন্ট পায় (openssl x509 -fingerprint -sha256) এবং এটি অ্যাপ্লিকেশন কোড বা কনফিগারেশন ফাইলে এম্বেড করে। প্রতিটি HTTPS অনুরোধে, অ্যাপ্লিকেশন প্রাপ্ত সার্টিফিকেটের ফিঙ্গারপ্রিন্ট গণনা করে এবং সংরক্ষিতটির সাথে তুলনা করে — মান মেল না হলে, সংযোগ বন্ধ করে দেওয়া হয়।

প্রথম ধাপ — বিল্ড সময়ে পিনিং: ডেভেলপার আগেই সার্ভার সার্টিফিকেট জানে এবং তাদের হ্যাশ এম্বেড করে। দ্বিতীয় ধাপ — প্রথম সংযোগে পিনিং (প্রথম ব্যবহারে বিশ্বাস, TOFU): অ্যাপ্লিকেশন প্রথম অনুরোধে সার্টিফিকেট মনে রাখে এবং পরবর্তী সব অনুরোধ যাচাই করতে এটি ব্যবহার করে। TOFU গতিশীল পরিবেশের জন্য সুবিধাজনক কিন্তু প্রথম আক্রমণে দুর্বল — যদি প্রথম সংযোগ ইতিমধ্যেই আটকানো হয়, জাল সার্টিফিকেট বিশ্বস্ত হিসেবে গৃহীত হবে।

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

# SHA-256 সার্টিফিকেট ফিঙ্গারপ্রিন্ট প্রাপ্তি
openssl s_client -connect example.com:443 </dev/null 2>/dev/null | \
  openssl x509 -pubkey -noout | \
  openssl pkey -pubin -outform der | \
  openssl dgst -sha256 -binary | \
  base64

SSL Pinning-এর প্রকার

পিনিং বাস্তবায়নের দুটি প্রধান পদ্ধতি আছে: সম্পূর্ণ সার্টিফিকেটের সাথে বাঁধন (certificate pinning) এবং পাবলিক কী-এর সাথে বাঁধন (public key pinning)। প্রতিটি পদ্ধতির নিজস্ব শক্তি এবং সীমাবদ্ধতা আছে যা নিরাপত্তা ও রক্ষণাবেক্ষণকে প্রভাবিত করে।

Certificate Pinning

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

Public Key Pinning

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

iOS-এ SSL Pinning

Apple প্ল্যাটফর্মে, SSL Pinning URLSession ডেলিগেটের মাধ্যমে বাস্তবায়িত হয়। ডেভেলপার URLSessionDelegate প্রোটোকল বাস্তবায়নকারী একটি ক্লাস তৈরি করে এবং didReceive challenge মেথড ওভাররাইড করে, যেখানে সে সংরক্ষিত ফিঙ্গারপ্রিন্টের বিরুদ্ধে ম্যানুয়ালি সার্ভার সার্টিফিকেট যাচাই করে। একটি বিকল্প পদ্ধতি হল Alamofire ব্যবহার করা ServerTrustManager-এর সাথে, যা কনফিগারেশন সহজ করে।

class SSLPinningDelegate: NSObject, URLSessionDelegate {
    let pinnedHash = "sha256/Wi24BE7j5qLk0iLvPq6ePEsVRqZ1yW0F6wLg="

    func urlSession(_ session: URLSession,
        didReceive challenge: URLAuthenticationChallenge,
        completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) {

        guard let serverTrust = challenge.protectionSpace.serverTrust
            else { return completionHandler(.cancelAuthenticationChallenge, nil) }

        if validate(serverTrust, pinnedHash) {
            completionHandler(.useCredential, URLCredential(trust: serverTrust))
        } else {
            completionHandler(.cancelAuthenticationChallenge, nil)
        }
    }
}

উদাহরণে, ডেলিগেট URLSession থেকে একটি প্রমাণীকরণ অনুরোধ পায়, challenge থেকে serverTrust বের করে এবং সার্টিফিকেটের SHA-256 ফিঙ্গারপ্রিন্ট সংরক্ষিতটির সাথে তুলনা করে। ফিঙ্গারপ্রিন্ট মিললে — সংযোগ চলতে থাকে, অন্যথায় challenge প্রত্যাখ্যান করা হয়। প্রোডাকশনের জন্য, একাধিক ব্যাকআপ পিন যাচাই এবং মনিটরিংয়ের জন্য ত্রুটি লগিং যুক্ত করা উচিত।

iOS-এ Network Security Config

iOS 14 থেকে শুরু করে, Apple Info.plist-এর মাধ্যমে Certificate Pinning-এর জন্য অন্তর্নির্মিত সমর্থন যুক্ত করেছে। ডেভেলপার NSAppTransportSecurity কী-তে NSPinnedDomains উপ-অভিধানের সাথে বিশ্বস্ত সার্টিফিকেট নির্দিষ্ট করে। এই পদ্ধতিতে কোড লেখার প্রয়োজন নেই কিন্তু কম নমনীয় — পিন গতিশীলভাবে পরিবর্তন করা বা যাচাই ত্রুটি লগ করা অসম্ভব।

Android-এ SSL Pinning

Android-এ SSL Pinning বাস্তবায়নের তিনটি প্রধান উপায় আছে: OkHttp লাইব্রেরির CertificatePinner-এর মাধ্যমে, XML-এ Network Security Config-এর মাধ্যমে, এবং HttpsURLConnection-এ কাস্টম যাচাইয়ের মাধ্যমে। OkHttp সবচেয়ে জনপ্রিয় এবং সুপারিশকৃত পদ্ধতি, যা Retrofit ও অন্যান্য HTTP ক্লায়েন্টে ব্যবহৃত হয়।

val certificatePinner = CertificatePinner.Builder()
    .add("api.example.com",
        "sha256/Wi24BE7j5qLk0iLvPq6ePEsVRqZ1yW0F6wLg=")
    .add("api.example.com",
        "sha256/FiPq6ePEsVRqZ1yW0F6wLgWi24BE7j5qLk0iL=")  // ব্যাকআপ পিন
    .build()

val client = OkHttpClient.Builder()
    .certificatePinner(certificatePinner)
    .build()

OkHttp কনফিগারেশনে, ডেভেলপার ডোমেইন এবং এক বা একাধিক SHA-256 ফিঙ্গারপ্রিন্ট নির্দিষ্ট করে। প্রথম ফিঙ্গারপ্রিন্টে, OkHttp সার্ভার সার্টিফিকেট নির্দিষ্ট পিনের সাথে তুলনা করে। কোনো মিল না থাকলে, ক্লায়েন্ট SSLPeerUnverifiedException নিক্ষেপ করে। ব্যাকআপ পিন বাধ্যতামূলক — এটি ছাড়া, সার্টিফিকেট পরিবর্তনের সময় API অনুরোধ অবিলম্বে ব্যর্থ হতে শুরু করবে।

Android-এ Network Security Configuration

Android API 24 থেকে শুরু করে XML কনফিগারেশনের মাধ্যমে ঘোষণামূলক Certificate Pinning সমর্থন করে। ফাইল res/xml/network_security_config.xml-এ ডোমেইন এবং তাদের ফিঙ্গারপ্রিন্টের তালিকা থাকে। এই পদ্ধতি স্থির কনফিগারেশনের জন্য সুবিধাজনক কিন্তু অনিয়মের লগিং-সহ TOFU বা কাস্টম যাচাই লজিক বাস্তবায়নের অনুমতি দেয় না।

<!-- res/xml/network_security_config.xml -->
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-12-31">
            <pin digest="SHA-256">
                Wi24BE7j5qLk0iLvPq6ePEsVRqZ1yW0F6wLg=</pin>
            <pin digest="SHA-256">
                FiPq6ePEsVRqZ1yW0F6wLgWi24BE7j5qLk0iL=</pin>
        </pin-set>
    </domain-config>
</network-security-config>

SSL Pinning-এর সুবিধা ও অসুবিধা

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

প্রধান অসুবিধা হল সার্টিফিকেট রোটেশনের জটিলতা। কোনো সার্টিফিকেট মেয়াদোত্তীর্ণ বা বাতিল হলে, অ্যাপ্লিকেশন আপডেট ছাড়া ব্যবহারকারীরা সংযোগ হারায়। এটি ব্যাকআপ পিন এবং ক্রমিক আপডেট পদ্ধতির মাধ্যমে সমাধান করা হয়: নতুন অ্যাপ্লিকেশন পুরনো এবং নতুন উভয় সার্টিফিকেট জানে এবং ব্যবহারকারীদের সম্পূর্ণ আপডেটের পর, পুরনো পিন কোড থেকে সরানো হয়। কমপক্ষে ২টি ব্যাকআপ পিন অন্তর্ভুক্ত করার সুপারিশ করা হয় — একটি বর্তমান সার্টিফিকেটের জন্য, একটি ভবিষ্যতের জন্য।

আরেকটি আপস হল পিনিং অক্ষম না করে ট্র্যাফিক ডিবাগিং (Charles Proxy, Burp Suite)-এর জন্য পাবলিক প্রক্সি ব্যবহার করতে না পারা। এটি ডেভেলপমেন্টের সময় নেটওয়ার্ক অনুরোধের ডিবাগিং জটিল করে তোলে। সমাধান হল শর্তসাপেক্ষ কম্পাইলেশন: ডিবাগ বিল্ডে পিনিং অক্ষম, রিলিজে সক্রিয়। OWASP সুইচ করার জন্য BuildConfig.DEBUG ফ্ল্যাগ ব্যবহারের সুপারিশ করে।