iOS VPN პროფილი: passwordReference და არა პაროლი

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

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

პროფილი ინახავს სახელურს და არა საიდუმლოს

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

ამ მითითებას აშენებთ გასაღებების რგოლისთვის მისი მოთხოვნით, რაც განსხვავებული მოთხოვნაა მონაცემების მოთხოვნისგან:

let query: [String: Any] = [
  kSecClass as String: kSecClassGenericPassword,
  kSecAttrService as String: "vpn-credentials",
  kSecAttrAccount as String: "user",
  kSecReturnPersistentRef as String: true,
  kSecMatchLimit as String: kSecMatchLimitOne
]

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

რატომ პასუხობს API -50-ით

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

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

იგივე შეუთავსებლობა ხსნის პროფილს, რომელიც უჩივლელად ინახება და შემდეგ ვერ უკავშირდება: შენახული არის blob და არა სახელური, და დემონს გადასაჭრელი არაფერი აქვს.

კარგად ინახება, კავშირის დროს ვარდება

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

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

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

ხელმისაწვდომობა წყვეტს, იმუშავებს თუ არა გადატვირთვა

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

უფრო მკაცრი კლასის არჩევა მაცდურია და სწორედ ეს ამტვრევს on-demand პროფილს დაბლოკილ ტელეფონზე.

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

როტაცია ის ადგილია, სადაც შენახული პროფილები ლპება

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

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