2014-07-02 23:04 GMT+02:00 Martin Millnert martin@millnert.se:
Ikväll postades ett öppet brev till Netcleans VD på hemsidan: https://www.dfri.se/oppet-brev-till-christian-berg-vd-netclean/
Tycker det här utdraget är intressant:
Det påstås att NetClean kan radera information på andras servrar. Detta är vare sig korrekt eller tekniskt möjligt att göra med NetCleans lösningar. Det har även funnits påståenden om att NetClean kan blockera enskilda tweets på Twitter, något som inte heller är tekniskt möjligt (se mer information under Bakgrundsfakta nedan).
Vet inte vem som påstått att de kan radera information från andras servrar. Blockera enskilda inlägg på olika sociala nätverk kan jag dock tänka mig går att genomföra.
Bakgrundsfakta:
Om SSL (Secure Sockets Layer) trafik Webbtrafik till bland annat Twitter, Google och Facebook är krypterad med SSL/TLS (Transport Layer Security). Det gör att all trafik till och från sidan är krypterad och för att kunna blockera enskilda sidor eller tweets så måste trafiken dekrypteras. Detta är möjligt att göra inom organisationer, men för att kunna blockera dessa sidor selektivt, till exempel blockera enskilda tweets inom ett land, måste man utnyttja en CA (Certificate Authority = utfärdare av certifikat). Sådana finns listade i de större webbläsarna som t ex Chrome, Internet Explorer eller Firefox för att klara av dekryptering av trafiken. Turkiet kontrollerar förvisso flera sådana utfärdare, men ett missbruk skulle leda till att dessa CA-utfärdare skulle tas bort från webbläsarna och blockering skulle sluta fungera. Det är därför praktiskt omöjligt att blockera trafik till SSL sidor.
Det är alltså fullt möjligt i Netcleans ögon, så länge browsers har dessa CA:s som Turkiet kontrollerar. Hur ofta tas en CA bort från browsers?
Finns alternativ? Kan man tänka sig att implementera någon form av certificate pinning[1] på bredare front?
-joelpurra.com
[1] https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning [1] https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning#No_Relati...