დაბლოკეთ ღია ტექსტი Android აპებში VPN-ზე დაყრდნობის გარეშე

ორ სრულიად განსხვავებულ რამეს ეძახიან Android-ზე ღია ტექსტის დაბლოკვას. ერთი აპის შიგნით არსებული პოლიტიკაა, რომელიც საკუთარ ქსელურ დასტას უბრძანებს უარყოს ჩვეულებრივი HTTP. მეორე მოწყობილობის დონის მოწყობაა, რომელიც ცდილობს ტელეფონზე ყველაფერი ერთად დაიცვას, ჩვეულებრივ ტრაფიკის VPN-ით გატარებით. ისინი სხვადასხვა პრობლემას ხსნიან და მეორე პირველს ვერ გამოასწორებს: გვირაბი იცავს ტელეფონსა და გასასვლელს შორის მონაკვეთს, ხოლო HTTP-ზე მოლაპარაკე აპი კვლავ HTTP-ზე საუბრობს იმასთან, რაც ამ გასასვლელის მიღმაა.

ორი პრობლემა ერთი სახელის ქვეშ

პირველი პრობლემა დატვირთვაა: აპი ინახავს მომხმარებლის მონაცემებს ან ტოკენებს მოთხოვნაში, რომელიც თავიდან ბოლომდე არ არის დაშიფრული, ამიტომ ყველა ნაბიჯი, რომელსაც შეუძლია მისი ნახვა, შეუძლია წაკითხვაც. მეორე გზაა: აპი შეიძლება სრულიად სწორი იყოს და მაინც გინდოდეთ, რომ ადგილობრივმა Wi-Fi ოპერატორმა არაფერი გაიგოს იმაზე, თუ სად უკავშირდება. VPN მეორეს ეხება და მხოლოდ მეორეს.

ეს განსხვავება განსაზღვრავს, ვის ეკუთვნის გასწორება. დატვირთვა ეკუთვნის მას, ვინც აპს აწვდის, რადგან მხოლოდ ეს კოდი წყვეტს, რომელი URL იძახება და მოწმდება თუ არა სერტიფიკატი. გზა ეკუთვნის მოწყობილობას ან ქსელს, რადგან საქმე იმაშია, სად მიდიან პაკეტები და არა რას შეიცავენ.

პირველი გზა: აპი, რომელსაც თქვენ აკონტროლებთ

თუ აპს თქვენ აწვდით, გასწორება ტრანსპორტის გადაწყვეტილებაა და პოლიტიკა, რომელიც მას აღასრულებს. ყოველი ბოლო წერტილი HTTPS-ზე გადაიყვანეთ, ჰოსტის სახელისა და სერტიფიკატის ვალიდაცია ჩართული დატოვეთ და წაშალეთ ჩვეულებრივ HTTP-ზე დაბრუნების გზა, ნაცვლად იმისა, რომ ის ერთი კონფიგურაციის დროშის მანძილზე დატოვოთ. გადამისამართება აქ არ გვეხმარება: 301-ის მიმღები HTTP მოთხოვნა უკვე ღიად გაგზავნა სათაურები და სხეული, ამიტომ მომხმარებლის მონაცემები არასოდეს უნდა მოგზაურობდნენ იმ ვარაუდით, რომ გადამისამართება დაიცავს მათ.

Android 7.0-დან Network Security Configuration გამოხატავს პოლიტიკას. ქვემოთ მოცემული ფაილი უმცირესი სასარგებლო ვერსიაა: ის ყველგან უარყოფს ღია ტექსტს, თუ დომენის სპეციფიკური გამონაკლისი სხვა რამეს არ ამბობს.

<network-security-config>
    <base-config cleartextTrafficPermitted="false" />
</network-security-config>

მიუთითეთ ეს რესურსი მანიფესტიდან, შემდეგ კი გავრცელებამდე წაიკითხეთ უკვე არსებული გამონაკლისები. ძველმა გამართვის დომენმა ან გადახდის პროვაიდერის SDK ჩანაწერმა შეიძლება ჩუმად ხელახლა დაუშვას ღია ტექსტი იმ ჰოსტისთვის, რომლის დაცვასაც ცდილობდით.

ვერსიის ორი დეტალი ღირს ცოდნად. API 28 ან უფრო ახალზე მიმართული აპები უკვე ნაგულისხმევად უარყოფენ ღია ტექსტს, ამიტომ ჯერ კიდევ ჩვეულებრივ HTTP-ზე მოლაპარაკე აპი ან ძველ API დონეს ისახავს მიზნად, ან სადღაც გამონაკლისი აქვს. და როცა ქსელური უსაფრთხოების კონფიგურაცია არსებობს, ძველი android:usesCleartextTraffic მანიფესტის ატრიბუტი აღარ წყვეტს ამ საკითხს, ამიტომ ზოგჯერ ჩანს, რომ ამ დროშის შეცვლა არაფერს აკეთებს.

მეორე გზა: აპი, რომელსაც თქვენ არ აკონტროლებთ

დაყენებული მესამე მხარის აპისთვის ვერ გადაწერთ მის უსაფრთხოების კონფიგურაციას მომხმარებლის პარამეტრით. რეალისტური ვარიანტებია თავად პროდუქტის უსაფრთხო კავშირის კონტროლი, უკვე TLS-ს იყენებს მხარდაჭერილი ალტერნატივა, ან მართული მოწყობილობის პოლიტიკა, რომელიც ზღუდავს, თუ რისი გაშვება შეუძლია მოწყობილობას. ეს სხვადასხვა ვალდებულებაა და მხოლოდ მესამე ვრცელდება მოწყობილობების პარკზე.

ქსელური წესები უფრო სუსტი შემცვლელებია, ვიდრე ჩანს. მხოლოდ 443 პორტის დაშვება არ აღასრულებს ავთენტიფიცირებულ TLS-ს, რადგან ბევრი ღია ტექსტის პროტოკოლი შეიძლება ამ პორტზე გადავიდეს, ხოლო 80 პორტის დაბლოკვა არ ფარავს ღია ტექსტს სხვა პორტებზე. ბრაუზერის მხოლოდ-HTTPS რეჟიმიც შემოიფარგლება ამ ბრაუზერით და არა იმავე ტელეფონზე არსებული ცალკე ფოსტის ან ჩატის აპით.

ინტერცეპციის სერტიფიკატის დაყენება იმისთვის, რომ ტრაფიკი დაშიფრული ჩანდეს, ნდობის ცვლილებაა და არა გასწორება. ის აპის სერვერის ავთენტიფიკაციას თქვენით ცვლის და აპი, რომელიც თავიდანვე არ ამოწმებდა სერტიფიკატებს, ამით არ სწორდება; თქვენ მხოლოდ გადაადგილეთ, თუ ვის შეუძლია ნაკადის წაკითხვა.

სად ეხმარება VPN და სად არა

გვირაბი სწორი იარაღია, როცა მოთხოვნაა, რომ ადგილობრივმა ქსელმა არაფერი იცოდეს კავშირის შესახებ, ან რომ აპმა მიაღწიოს კერძო სერვისს, სადაც სხვაგვარად ვერ მიაღწევს. ის არასწორი იარაღია HTTP კლიენტს აიძულოს HTTPS-ზე ილაპარაკოს, რადგან მოთხოვნა გვირაბიდან გამოდის ზუსტად ისე, როგორც შევიდა.

Android ამატებს პრაქტიკულ შეზღუდვას: პლატფორმა ერთდროულად მხოლოდ ერთ VPN სერვისს უშვებს. ამ ადგილის დამჭერი ლოკალური ფილტრაციის აპი კონკურენციას უწევს იმ დისტანციურ გვირაბს, რომელიც ნამდვილად გჭირდებათ, და მათ შორის გადართვა მოწყობილობის დონის ოპერაციაა და არა აპის. სწორედ ეს ერთი ადგილია კარგი მიზეზი, რომ დატვირთვის პოლიტიკა აპში დატოვოთ, გვირაბი კი გზისთვის შეინახოთ.

ერთადერთი შემთხვევა, როცა ორივე ემთხვევა, თქვენივე მართული კერძო სერვერია. იქ გვირაბს შეუძლია გზა კერძო გახადოს, თუმცა პროტოკოლი ჯერ კიდევ ღია ტექსტია, რაც ამცირებს ექსპოზიციას, მაგრამ არ ცვლის, რა არის დატვირთვა. მოეპყარით ამას როგორც რისკის შემცირებას და არა მონაცემების დაშიფვრას.

რა უნდა შეამოწმოთ სანამ დაბლოკილს უწოდებთ

დაიწყეთ იმ ნაგულისხმევით, რომელიც ხალხს აკვირვებს: API 28 ან უფრო ახალზე მიმართული აპი უკვე უნდა უარყოფდეს ღია ტექსტს, ამიტომ სამიზნე დონე შეამოწმეთ სანამ ნაგულისხმევის დუბლირებად კონფიგურაციას დაამატებთ. შემდეგ მიზანმიმართულად შეამოწმეთ წარუმატებლობის შემთხვევა: ჩვეულებრივ HTTP ჰოსტზე მოთხოვნა უნდა ჩავარდეს და არა ჩუმად წარმატდეს სარეზერვო გზით.

adb shell dumpsys package com.example.app | grep -E 'targetSdk|versionName'
adb logcat | grep -i cleartext

წარმატების შემთხვევისთვის დაადასტურეთ, რომ HTTPS გამოძახება ამოწმებს ნამდვილ სერტიფიკატების ჯაჭვს და რომ არასანდო სერტიფიკატის მქონე პროქსი უარყოფილია და არა შეწყნარებული. ხელის ჩამორთმევა, რომელიც ნებისმიერ სერტიფიკატთან წარმატდება, ტრანსპორტის უსაფრთხოებაზე არაფერს ამტკიცებს.

მესამე მხარის აპისთვის ჩამოწერეთ ის ზღვარი, რომელიც ნამდვილად შეგიძლიათ აღასრულოთ, იქნება ეს მართული მოწყობილობის პოლიტიკა, ქსელური წესი თუ არაფერი, და თქვით ეს მიღების კრიტერიუმებში. Android-ის უსაფრთხოების კონფიგურაციის გზამკვლევი ჩამოთვლის პლატფორმის ნაგულისხმევებს და იმას, თუ რომელი კომპონენტები იცავენ პოლიტიკას, და სწორედ ეს ნაწილი წყვეტს, აკეთებს თუ არა თქვენი კონფიგურაცია საერთოდ რაიმეს.