Ce blochează în continuare certificate pinning

Pe iOS, decriptarea depinde de instalarea profilului Busymate și de încrederea completă acordată în Configurări — după aceea, fiecare aplicație de pe telefon are încredere în certificatul prezentat de aplicație, cu excepția celor care fac pinning. Pe Android există două depozite: cel al utilizatorului, pe care de la Android 7.0 îl respectă doar aplicațiile care acceptă explicit, și cel al sistemului, pe care îl respectă orice aplicație, dar în care poate scrie doar un dispozitiv cu root. Proxy-ul de desktop folosește încrederea pe care mașina sau browserul client o are în autoritatea sa generată.

Pinning-ul stă deasupra tuturor celor trei. O aplicație care face pinning respinge certificatul substitut din orice depozit ar veni, așa că mutarea unui certificat într-un depozit mai puternic nu ajută niciodată împotriva unui host cu pinning. Ajută doar împotriva aplicațiilor care refuzau depozitul utilizatorului.

Un host pe care nu l-ai listat pentru decriptare arată un lacăt închis doar cu numele hostului și un contor de cereri — asta e intenționat, nu pinning. Un host cu pinning arată altfel: este în lista ta, decriptarea a fost încercată, iar conexiunea a eșuat sau aplicația a reîncercat și a renunțat. Filtrul de inspecție al feedului din dashboard are trei setări — doar decriptate, doar criptate și doar cu SSL pinning — iar ultima izolează exact acele rânduri.

Celălalt semn este comportamental: aplicația nu mai funcționează pentru acel host din clipa în care este decriptat și funcționează din nou din clipa în care scoți hostul din listă. Dacă ambele sunt adevărate, ai găsit o conexiune cu pinning.

Aplicația iOS capturează la nivel de sistem, pe Wi-Fi și rețea celulară, și decriptează hosturile pe care le listezi. În fața unei aplicații cu pinning înregistrează în continuare fiecare conexiune — hostul, timpii, numărul și dimensiunea cererilor, modul de conexiune în vigoare — dar nu poate produce antetele sau corpul, și nu există niciun comutator care să schimbe asta. Activarea MITM All Hosts decriptează fiecare host fără pinning; pentru unul cu pinning nu face nimic în afară de a-l strica.

Mișcarea practică este să scoți hostul cu pinning din listă ca aplicația să continue să funcționeze, să păstrezi restul hosturilor aplicației în listă și să citești ce dezvăluie endpoint-urile fără pinning. Multe aplicații fixează doar hostul de autentificare sau de plată și lasă restul deschis.

Pe un telefon Android fără root, certificatul generat de aplicație stă în depozitul utilizatorului, așa că se decriptează doar propriile build-uri de debug și alți clienți care au acceptat; orice altă aplicație este înregistrată ca metadate. Pe un dispozitiv cu root, certificatul poate fi instalat în depozitul de sistem, iar HTTPS devine decriptabil la nivel de sistem — cu excepția pinning-ului per aplicație. Ferma de telefoane își rulează dispozitivele Android la acel nivel cu root exact din acest motiv.

Așadar root-ul transformă o clasă de aplicații opace în unele lizibile — cele care doar ignorau depozitul utilizatorului — și lasă clasa cu pinning neatinsă. Busymate nu pretinde niciodată decriptare la nivel de sistem pe un dispozitiv fără root și nu pretinde niciodată că pinning-ul este învins pe unul cu root.

Proxy-ul de desktop are aceeași relație cu pinning-ul ca aplicațiile de telefon: un client cu pinning refuză certificatul generat și conexiunea eșuează. Are, de asemenea, o listă scurtă de hosturi pe care nu le interceptează niciodată, indiferent ce spun setările tale SSL proxy — PKI-ul și endpoint-urile de revocare ale Apple, responderele de stare a certificatelor folosite de lanțul Apple și propriul backend Busymate — pentru că interceptarea lor ar strica dispozitivul sau conexiunea live a dashboardului. Ele trec ca tuneluri brute, iar asta este intenționat, nu o configurare greșită.

Există o cale de captură în care pinning-ul este irelevant. Conectorul din linia de comandă lansează o instanță Chrome și îi citește traficul prin DevTools Protocol, pe partea de browser a TLS. Conexiunea criptată dintre Chrome și server nu este atinsă niciodată — nu există certificat substitut de respins, nimic de instalat și nimic pe care pinning-ul să-l detecteze. Fluxurile de autentificare la furnizori ale căror certificate fixate un proxy nu le poate deschide sunt înregistrate cap-coadă, cu redirecționări și tokenuri incluse.

Compromisul este sfera de acoperire: acoperă ce rulează în acel Chrome, nu o aplicație nativă. Dacă fluxul care te interesează are o versiune web, aceasta este calea care îl vede în întregime.

Metadatele nu înseamnă nimic? Ba da. Vezi în continuare când aplicația vorbește cu hostul cu pinning, cât de des, cât de mari sunt schimburile și cât durează, și le poți corela cu apelurile decriptate din jur. Regulile de blocare se potrivesc în continuare la nivel de host pe un host criptat — calea este invizibilă, dar poți face aplicația să se comporte ca și cum acel endpoint ar fi inaccesibil, ceea ce adesea este exact modul de eșec pe care voiai să-l testezi. Pauzele lasă hostul să ocolească proxy-ul complet, ca aplicația să continue să funcționeze în timp ce inspectezi tot restul.

Și fiecare acțiune pe care ai făcut-o este în jurnalul de audit, așa că o sesiune de cercetare lasă o urmă a ceea ce a fost decriptat, ce a fost blocat și ce a fost lăsat în pace.