Det finns en stationär klient A som ansluter till webbplatsen W i en https-anslutning
A --> W På något sätt mellan A och W, där är en proxy G.
A --> G --> W HTTPS bygger på offentlig / privat nyckelkryptering . Detta betyder i grunden att det finns ett nyckelpar: Den offentliga nyckeln används för kryptering och den hemliga privata nyckeln krävs för dekryptering.
Ett certifikat är i grunden en offentlig nyckel med en etikett som identifierar ägaren.
Så när din webbläsare ansluter till en HTTPS-server svarar servern med sitt certifikat. Webbläsaren kontrollerar om certifikatet är giltigt :
Om något av dessa villkor inte uppfylls informeras användaren om problemet.
Efter verifieringen visas webbläsare extraherar den offentliga nyckeln och använder den för att kryptera viss information innan den skickas till servern. Servern kan dekryptera den eftersom servern har den matchande privata nyckeln .
I detta kommer G att kunna få certifikatet som A tidigare fick från W?
Ja, certifikatet är den offentliga nyckeln med etiketten. Webbservern skickar den till alla som ansluter till den.
Om G kan få certifikatet, betyder det att G kommer att kunna dekryptera data?
Nej Certifikatet innehåller webbserverns offentliga nyckel . Den skadliga proxyen har inte den matchande privata nyckeln. Så om proxyen vidarebefordrar det verkliga certifikatet till klienten kan det inte dekryptera information som klienten skickar till webbservern.
Proxyservern kan försöka förfalska certifikatet och tillhandahålla sin egen offentliga nyckel istället. Detta kommer emellertid att förstöra certifieringsmyndigheternas underskrift . Webbläsaren varnar för det ogiltiga certifikatet.
Om datorns administratör samarbetar är det möjligt för en proxyserver att sniffa https-anslutningar. Detta används i vissa företag för att söka efter virus och för att genomdriva riktlinjer för acceptabel användning.
En lokal certifieringsmyndighet är inställd och administratören säger till din webbläsare att den här
Åh och naturligtvis tenderar användaren att klicka bort säkerhetsvarningarna.
Förutsatt att användare inte klickar igenom certifieringsvarningar (och förutsatt att du kör en omodifierad klient) är svaret: Nej, proxyn kan inte dekryptera data .
För en detaljerad förklaring av hur HTTPS förhindrar en man-i-mitten från att dekryptera din trafik, se alla standardresurser på SSL / TLS, t.ex.
PS Certifikatet är offentliga uppgifter. Den innehåller serverns offentliga nyckel och domännamn, som inte är hemliga. Att följa certifikatet hjälper inte angriparen att dekryptera data. (Ja, ombudet kan följa certifikatet, men detta är ofarligt.)
Från Philipp C. Heckels tekniska blogg med några lätta redigeringar:
Medan man attackerar okrypterad HTTP-trafik kan man göra utan att behöva hantera X.509-certifikat och certifikatutfärdare (CA), SSL-krypterade HTTPS-anslutningar krypterar varje begäran och svar mellan klient och server från slut till slut. Och eftersom den överförda informationen är krypterad med en delad hemlighet, kan en mellanman (eller en proxy) inte dechiffrera de utbytta datapaketen. När klienten öppnar en SSL / TLS-anslutning till den säkra webbservern, verifierar den serverns identitet genom att kontrollera två villkor: Först kontrollerar den om dess certifikat har signerats av en CA som är känd för klienten. Och för det andra ser det till att serverns vanliga namn (CN, även: värdnamn) matchar det som den ansluter till. Om båda villkoren är sanna antar klienten att anslutningen är säker.
För att kunna sniffa in i anslutningen kan proxyservern fungera som certifikatutfärdare, dock inte mycket pålitlig: istället för att utfärda certifikat till faktiska personer eller organisationer genererar proxy dynamiskt certifikat till vilket värdnamn som behövs för en anslutning. Om exempelvis en klient vill ansluta till https://www.facebook.com genererar proxy ett certifikat för “www.facebook.com” och signerar det med sin egen CA. Förutsatt att klienten litar på denna CA är båda ovannämnda villkoren sanna (betrodda CA, samma CN) - vilket innebär att klienten anser att proxyservern faktiskt är ”www.facebook.com”. Figuren nedan visar begäran / svarsflödet för detta scenario. Denna mekanism kallas transparent HTTPS-proxying.
För att denna attack ska fungera, finns det några villkor som måste uppfyllas:
- Proxyserver som standardgateway (HTTP och HTTPS) : För både HTTP- och HTTPS-proxyserver måste proxyservern naturligtvis kunna fånga upp IP-paketen - vilket betyder att den måste vara någonstans längs väg för paketvägen. Det enklaste sättet att uppnå detta är att ändra standardgatewayen i klientenheten till proxyserveradressen.
- Trusted Proxy CA (endast HTTPS) : För att HTTPS-proxy ska fungera måste klienten känna till (och lita på!) proxy-CA, dvs CA-nyckelfilen måste läggas till i klientens förtroendebutik.
Om du är intresserad av att transparent sniffa vanliga SSL-uttag kan du prova
SSLsplit, en transparent TLS / SSL-man-i-mitten-proxy. Det finns många sätt att attackera SSL, men du behöver inte falska SSL-certifikat, en oseriös certifieringsmyndighet (CA) eller variationer på säkerhetsexpert Moxie Marlinspikes man-in-the-middle SSL-attacker. Varför gå till alla problem när du bara kan köpa en SSL-avlyssnings-proxy, till exempel Blue Coat Systems ProxySG eller deras nyligen förvärvade Netronome SSL-apparat för att göra jobbet åt dig?
Från Steven J. Vaughan-Nichols på ZDNet (utdrag):
Blue Coat, det största namnet i SSL-avlyssningsbranschen, är långt ifrån den enda erbjuder SSL-avlyssning och bryter i en låda. Fram till nyligen skulle Microsoft till exempel sälja ett program, Forefront Threat Management Gateway 2010, som också skulle kunna göra jobbet åt dig. Med ett SSL-avlyssningsproxyprogram eller en enhet på plats är det här som verkligen händer:
Om ditt företag har ställt in proxy korrekt vet du inte att något är avstängt eftersom de har ordnat att proxyns interna SSL-certifikat registreras på din maskin som ett giltigt certifikat. Om inte får du ett popup-felmeddelande som, om du klickar på för att fortsätta, accepterar det "falska" digitala certifikatet. I båda fallen får du en säker anslutning till proxyen, den får en säker anslutning till utsidan - och allt som skickas via proxyen kan läsas i klartext. Oj.
Beroende på konfigurationen för det nätverk som du är i kan det vara möjligt för administratörer att se innehållet i HTTPS-anslutningar (och eventuellt VPN).
Det är uppenbarligen möjligt att fånga upp trafik i nätverket, men det vanliga problemet är att de inte kan utfärda giltiga certifikat för alla webbplatser som du besöker, så du skulle se många certifikatvarningar varje gång du går in på en HTTPS-webbplats om de försöker dekryptera trafiken för att titta på den.
Om du använder en maskin från företaget kan de installera en ny certifikatmyndighet och sedan använda den för att skapa SSL-certifikat för webbplatser som du besöker, så det skulle inte visas som ett problem.
Med VPN-sidan av saker kan det vara mer komplicerat om VPN inte använder SSL, men samma teori gäller. Om du går åt Internet från en maskin som ägs av någon annan i ett nätverk som de styr, kan de troligen få åtkomst till allt innehåll du anger.
Om du vill undvika den här typen av problem skulle jag använda en enhet som du äger / kontrollerar för att komma åt Internet, på det sättet bör du bli varnad om någon SSL-avlyssning inträffar.
Höger, företagsnätverksadministratörer implementerar en man-i-mitten-attack mot TLS-klienten med sin egen CA så att de kan se vad som lämnar deras nätverk. De kommer förmodligen att ha en enhet som skapar ett certifikat i farten som är giltigt för gmail.com när du besöker gmail.com. Anledningen till att de gör det här är inte för att spela Dr. Evil, det är så att de kan skydda sig mot att affärshemligheter släpps ut ur sin byggnad över sin internetanslutning. Allvarligt, gör inte din privata bankverksamhet på en arbetsdator.
Om du använder en programvaruprodukt som inte använder systemcertifikatlagret (säg en OpenVPN-instans), då kan de inte fånga upp och avkoda din trafik eftersom du inte litar på deras CA. Du kan uppnå samma resultat med exempelvis en bärbar Firefox-app. Och i de flesta webbläsare kan du kontrollera informationen om din säkra anslutning och se vem CA är, för att vara säker på vem som lyssnar eller inte.
Proxyen kan blockera https och endast tillåta http från webbläsaren. Då kan den initiera sin egen https-anslutning för att skicka förfrågningarna till servern.
De flesta användare kommer inte att märka det.
HSTS ska stoppa detta men det används inte i stor utsträckning.
SSL-avslutning eller SSL-proxyprodukter som Bluecoat måste finnas i ditt nätverk och med tanke på kostnaden, installationsprocedurerna och den normala säkerhetspolicy som alla organisationer har som installerar dessa produkter - hoten från en skadlig angripare som använder en kommersiell SSL termineringsprodukt är nästan noll. OTOH - en betrodd insider med tillgång till NOC (nätverksoperationscenter) kan faktiskt övervaka SSL-avslutad trafik och avslöja känslig information.
Detta är ett vanligt problem (motiverat eller inte) för företag som implementerar DLP-system .
HAR SÄTT ALLT ATT - det finns en annan attackvektor som är vanlig i hemmabankutrymmet som inte kräver en nätverksproxy och är piggback / shim-attacker i webbläsaren - eftersom DOM har åtkomst för att rensa texttrafik innan den träffar SSL-röret - detta är en bekväm attackvektor och installeras ofta via ett webbläsartillägg. Det finns en utmärkt Stackexchange-artikel om shims - Kan en shim (aka polyfill) installeras i IE, FF eller Chrome utan användarkännedom, och kan den läsa lösenord som användaren angett på en inloggningssida?