Kva side av inspeksjonsproxyen avviste sertifikatet?

Klienten stolar på den godkjende inspeksjonsproxyen. Førespurnaden feilar likevel på grunn av ein sertifikatfeil. Begge tilhøva kan vere sanne: den proxyen har ein annan TLS-relasjon å verifisere.

client -- TLS to approved intermediary -- proxy -- TLS to website -- destination

Ved avlytting avsluttar mellomleddet TLS-en til klienten og lagar si eiga tilkopling vidare. Klienten kan godta sertifikatet som blir lagt fram på hans side, medan proxyen avviser sertifikatet han får frå nettstaden.

Les feilen til verifiseraren

Avgjer kva prosess som rapporterte den mislukka kjeda eller vertsnamnet. Ei feilside generert av proxyen kan nå klienten med suksess over ei gyldig tilkopling. Å endre CA-fila til klienten igjen oppdaterer ikkje oppstraums tillitskonfigurasjon hos proxyen.

Mitmproxy dokumenterer til dømes separate oppstraums tillitsval, mellom anna ssl_verify_upstream_trusted_ca. Den rette administratoren kan setje opp godkjend tillit for oppstraumstenesta og samstundes halde på verifiseringa. Eit anna proxyprodukt treng sitt tilsvarande grensesnitt.

Kontroller òg det faktiske målnaamnet og kjeda. Ei privat teneste utan mellomliggjande sertifikat, eit utlapt sertifikat og ein ukjend privat utferdar krev ulike reparasjonar. Eit tiltenkt unntak for éi privat teneste bør ikkje stille bli ein global aksept av kvart sertifikat.

Ein vanleg CONNECT-tunnel er annleis

Ein ugjennomsiktig videresendingstunnel deler ikkje TLS-en til målet på denne måten. Applikasjonen forhandlar og verifiserer vanlegvis sjølv den ende-til-ende TLS-økta. Slå først fast om avlyttinga faktisk er ein del av ruta, i staden for å bruke innstillingar for inspeksjonsproxy på kvar mellommann.

Registrer dei to verifiseringsresultata kvar for seg. «Sertifikatet til proxyen er stole på» svarar på spørsmålet på klientsida; det stadfestar ikkje kva proxyen såg då han kopla oppstraums.