Ett problem som The New New internet pekar på i samband med en forskningsrapport är välkänt sedan SSL kom:
"By analyzing the size and other attributes of the exchanges between a user and the search engine, researchers were able to determine what type of sensitive data was present. Then, using man-in-the-middle attacks, they were able to acquire the information even when it was encrypted using WPA, SSL of Wi-Fi Protected Access."
Från: Hackers Can Intercept Sensitive Data over Search Engines (2010-03-24)
Artikeln finns att läsa här:
Side-Channel Leaks in Web Applications: a Reality Today, a Challenge Tomorrow (PDF)
Den är viktig därför att den tydliggör ett antal realiserade problem.
Riskerna med trafikanalys mot SSL i anti-censur-lösningar
SSL (TSL) är inte säkert mot trafikanalys. Sajter du besöker, tidpunkter för besöken, storleken på trafik och vissa parametrar läcker information. I de flesta fall saknar det betydelse och det gäller alla idag vanliga tillämpningar t.ex. för bankärenden (även om andra också välkända problem finns).
Om vi tunnlar trafik över SSL med syfte att kringgå censur är detta självklart ett av flera grupper av begränsningar i SSL som måste hanteras ovanpå protokollet. Betrakta här först lösningen jag pekade på igår men som på inget sätt är ny:
En möjlig anti-censur lösning i Google
Att enkelt eliminera riskerna
Problemet hanteras med att inte se SSL hopgyttrat med webbprotokollen. Precis som namnet indikerar - Transport Layer Security (TLS) - är det ett säkerhetsprotokoll för transport. Det säger egentligen föga om vilken information vi lägger ner på det och tillåt mig att citera RFC
"The TLS Record Protocol is used for encapsulation of various higherlevel protocols. One such encapsulated protocol, the TLS Handshake Protocol, allows the server and client to authenticate each other and to negotiate an encryption algorithm and cryptographic keys before the application protocol transmits or receives its first byte of data."
[...]
"One advantage of TLS is that it is application protocol independent. Higher-level protocols can layer on top of the TLS protocol transparently. The TLS standard, however, does not specify how protocols add security with TLS; the decisions on how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left to the judgment of the designers and implementors of protocols that run on top of TLS."
Från: RFC 5246 (ietf.org)
Nödvändigt här är att definiera ett enkelt mellanliggande protokoll och säkerhetslager som tillräckligt väl hanterar explicita problem som trafikanalys kan orsaka:
1. Eliminera möjligheten att se vilka webbplatser du besöker. Det sker via mediatorn som erbjuder tjänsten.
2. Reducera komponenter i webbtrafiken som är för stora för att den inte ska skilja ut sig för mediatorn annars normal trafik.
3. På det kan man lägga in stokatisk förändring av storlek för ytterligare maskering.
4. På samma sätt som att tre är en möjlighet är det viktigare att kommunikationen inte är standardiserad eller igenkännbar i trafikmönster.
Tre och fyra innebär ingen som helst svårighet att hantera därför att det kräver ingen signifikant eller ens mätbar ökning av bandbredd eller kapacitet det förbrukar i antal servrar. Vidare är det heller ingen svårighet att implementera säkert och välkända metoder finns sedan många år tillämpade robust i mjukvara. Några komponenter i begränsat urval värda att peka ut varande viktiga:
1. Reducera redundans övergripande i protokollet ovanför SSL (inklusive ev. problem rörande tidsanalys men det är mycket mindre problematiskt och behöver sannolikt ej beröras givet antal servrar och mängden total webbtrafik som naturligt skapar slumpmässiga mönster mer tydliga än aktuellt för implementationen). Det även utanför att bilder och vissa andra komponenter kan vara nödvändiga att skära bort. I princip behöver trafiken "styckena" (vad du normalt laddar ner när du besöker en sida) styckas upp i ett fåtal block som var för sig rudimentärt komprimeras.
2. Givet 1. transformera blocken mot vad som är normalt för trafikkanalen. Det kan och inkludera att lägga till meningslös redundans stokastiskt och slumpmässigt.
Det är verkligen ingen svårighet alls att eliminera risken för trafikanalys när man tunnlar över SSL även om den faktiska tunnlingen behöver döljas.
Relaterat
För grundläggande rörande trafikanalys menar jag att man först och bäst återvänder till arbetet Shannons tidiga arbeten. Först hans grundläggande arbete rörande information (d.v.s. här applicerat rörande reduktion av redundans liksom stokastiska komponenter):
A Mathematical Theory of Communication by Claude E. Shannon
Vidare därefter:
Communication Theory of Secrecy Systems (PDF)
Ett otal senare artiklar finns av andra från senare år också läsbara och till exempel:
Foto:
Kommentera