23 Mai 2015

Wie verschlüsselung gegen Massenüberwachung auch Massen tauglich werden kann

Versuche den Überwachungswahn politisch in den Griff zu bekommen muss man als zumindest kurzfristig als gescheitert betrachten. Es mag sein, das irgendwann mal die eine oder andere Verfassungsinstitution hier und da mehr oder weniger laut auf den Tisch haut, aber das wird wenig Bringen, weil das ja dann immer nur ein Land betrifft. In Amerika wollen die Abgeordneten zum Beispiel zur Zeit der NSA klar machen, das sie die Amerikaner unbeobachtet lassen soll. Das hilft uns also erst mal überhaupt nicht. Wie sich aktuell im NSA Untersuchungsausschuss zeigt, kriecht unsere Regierung der US-Administrion ja so weit in den Arsch, das sie durch Zahnlücken winken kann. Das ist alles höchst unerfreulich, und Besserung ist nicht in Sicht.

Leider sind die Regierungen aber auch ein enormes Hindernis bei der Beseitigung des Übels. Da Regierungen ihre Ansichten immer mal wieder mit wie auch immer gestalteter durchzusetzen geruhen, sind Sie natürlich auch der Meinung das der Bürger nicht freien Handel im Ausland mit solchen Technologien treiben dürfe, weil das potentiellen Gegnern von nutze sein kann. Ein völlig neues Verfahren das sich gegen die Regierungskriminalität im Bereich Datenschutz richtet läuft also immer Gefahr mit einer Handelsbeschränkung belegt zu werden, so das es für die globale Comunity nicht mehr sinnvoll nutzbar ist.

Es gab von großen E-Mail Providern die Initiative, die E-Mails nur noch mit einer Transportverschlüsselung zu übertragen. Ich weiß aber aus eigener Anschauung das alleine diese an sich Simple Änderung einen enormen Aufwand an Support nach sich gezogen hat.

Wie kann man besehende Verfahren Massen tauglich machen und welche sind das?

Wenn es nur um das Passive belauschen geht, gibt es mit dem Diffi-Hellman-Schlüsseltausch bereits das Ideale Verfahren. Wenn man dieses in den TCP/IP Stack im Wege einer TCP/IP Option einbaut, dann wären alle auf einfaches Lauschen beruhenden Aktionen mit einem Schlag hinfällig. Warum ist diesem Verfahren dann so ein Schattendasein auferlegt? Das liegt daran, das die Wissenschaft der Kryptografie als Grundaufgabe hat eine ganz konkrete Nachricht sicher von Alice zu Bob zu transportieren. Kann sich die böse Mallory aber in die Verbindung einklinken, dann ist das Verfahren hinfällig:

Bildquelle Wikipedia
Während man bei der Übertragung einer dezidierten Nachricht immer fürchtet, das genau diese Nachricht in falsche Hände gerät, will man bei der Verhinderung der Massenüberwachung ja nur Verhindern, das ein systematisches Screening heimlich möglich ist. Jetzt wird gelauscht. Funk aufgezeichnet, Lichtleiter mit halb durchlässigen Spiegeln angezapft. Das ist sehr einfach und braucht nur sehr wenig oder gar keine Energie. Ganz anderes sieht das bei einem Man in the Middle Angriff aus. Nehmen wir an, eine 100GByte Glasfaser trägt TCP Ströme vom in Durchschnitt 1 Megabit. Dann wären von einem Angreifer 100.000 Kanäle zu entschlüsseln und neu zu verschlüsseln. Dafür bedarf es nicht unerheblich Rechenleistung am Ort des Eingriffs oder aber das Signal muss weitläufig umgeleitet werden, was sich aber wiederum in der Pingzeit niederschlägt. Bei einer Funkanwendung würde das aussenden der veränderten Signale auf jeden Fall unangenehm auffallen, weil sich die Übertragungskapazität halbiert.

Verschlüsselte Daten lassen sich nicht mehr Komprimieren. Aus diesem Grunde sollte ein solches Verfahren in jedem Fall die Daten vor dem verschlüsseln adaptiv Komprimieren. Wenn man die Daten für den Schlüsseltausch auch durch den Kompressor laufen lässt, dann hängt der Datenstrom vom Schlüssel ab und der Man in the Middle Angreifer Mallory alles entpacken und neu komprimieren. Dazu würden bei 1 Megabyte Kompressinsbuffer für unser obiges Beispiel 200 GByte RAM gebraucht, so das auch nicht mal eben auf ein Stromsparendere ASIC zurückgegriffen werden kann.

Allein diese Maßnahme würde meines Erachtens der NSA schwer auf den Magen schlagen. Wie viele Softwarepakete müsste man Ändern? Wenn man die Kerne der Open Source Linux, FreeBSD, Opensolaris und Darvin im Mainstream ändert, dann wären annähernd alle Server damit ausgerüstet, die Apple Produkte die auf Darvin aufsetzen, Alle Produkte die auf Linux aufsetzen insbesondere alle Android Smartphones und auch Router. Das Mobile Internet wäre damit sehr weitgehend geschützt. Beim stationären Internet wären die ganzen Windows Arbeitsplätze ungeschützt ... nur ob sich Microsoft das auf Dauer wird leisten können, hier nichts zu unternehmen und nicht mitzuziehen?

Installationsaufwand für die Verschlüsselung

Was wäre bei der Installation zu beachten? Nichts! der neue Kernel könnte als Sicherheitsupdate eingespielt werden. Einzig und allein die Rechenleistung für eine Anwendung würde steigen. Da dieses aber ebenfalls vom Beitriebsystem verwaltet wird, wüsste es auch in welchen ausnahmen eine Abschaltung unbedingt nötig ist. Dieses Wartungsfreie einfügen in die Produktion meine ich, wenn ich von Massen tauglicher Verschlüsselung spreche.

Kann man Massen Iterceptions erkennen?

Aber es geht noch besser. Da es für diese Verfahren keinen breit verwendeten Code gibt mein Vorschlag: Die Verwendung von TLS. TLS dekt soweit bekannt fast alle Problem ab. Auch Snowden hat keine hinweise geliefert, das alle TLS Verfahren von der NSA unterwandert sind. Zumal im TLS auch Chipher verschiedener Länder verbaut sind. (USA, Russland, Japan, Süd-Korea). TLS hat eine Schwachstelle, und das ist die das die Länge eines Datentransfers exakt nachvollzogen werden kann. Das ist dem Streben nach Effizienz geschuldet, führt aber dazu, das bei öffentlichen Content der Bezug nachvollzogen werden kann. Aber das gilt für fast alle Verfahren, und TLS hat den entscheidenden Rechtlichen Vorteil das es überall öffendlich zugänglichen Code gibt und sehr viel SSL/TLS übertragungen im Internet vorhanden sind.

Der Systemkern erzeugt beim Booten sein Selbst signiertes Zertifikat und sperrt den privaten Schlüssel per MMU möglichst gut weg, so das ja keine Anwendung irgendwie Zugriff darauf erlangt. Der Schlüssel sollte im Ram liegen, so das dieser nach dem Ausschalten oder der alle 24h stattfindenden Neuerstellung für immer Weg ist. Damit haben dann alle Chipher zumindest eine verzögerte Perfect Forward Security. Das ist wichtig, wenn man Hardwarekomponenten nutzen will. Bei eingehenden Verbindungen werden Datensätze aus IP, Ziel Port, Fingerprint des präsentierten öffentlichen Key im Logfile gespeichert. Wird die TCP Option ignoriert und es kommt eine normale Verbindung zu Stande so wird ein spezieller Fingerprint wie 00:00:00...00:00 eingetragen

Diese Daten werden dann turnusmäßig gesammelt und per regulärem https sicher verschlüsselt an eine Gruppen von Zentralinstanzen gesendet, welche die Daten statistisch auswerten. Interceptions zeichnen sich dadurch aus, das die Fingerprints von verschiedenen Locations aus gesehen nicht identisch sind. Werden bestimmte Verbindungen Intercepted, zum Beispiel der Port 80 durch eine anti Virus und Cache Firewall, dann kann diese Instanz ein solches Firewallcache diagnostizieren, und allgemeinverständliche Kommunikees generieren. Manchmal will man ja oder muss man auch eine Verkehrskontrolle haben. Das mag auch für ganze Nationen gelten, nur das die Regierungen sich dann in Zukunft immer dafür in der Öffentlichkeit verantworten müssen. Und ob Wegelagerer wie die Briten dann noch Kabelkapazität verkaufen können wird sich Zeigen. Die Provider die solche Strecken nutzen werden nicht umhin können, einen VPN Tunnel zu konfigurieren.

Auch wichtig wird sein, das Verfahren zeichnet sich dadurch aus, das man wichtige Werkzeuge wie den wireshark so umbauen kann, das sie auch Weiterhin mit Interception funktionieren. Das Debuggen mit konventioneller Verschlüsselung ist nervtötend, weil geringste Fehler sich so auswirken, das nichts mehr geht. Bekommt man keine vernünftige Fehlermeldung - und jeder der länger mit Computern zu tun hat weiß, wie schlecht die oft sind - dann steht man erst mal völlig auf der Leitung, wenn man sich die Kommunikation nicht mehr ansehen kann. Ich habe oft von Entscheidern in der wirtschaft hören müssen, das sie keine Kryptografischen Algorithmen haben wollten, weil Sie - leider nicht ganz zu Unrecht - Produktionsausfälle befürchten.






17 Mai 2015

Der unsachgemäße Umgang mit Fragen der Netzneutralität ...

Zur Zeit wird auf EU Ebene eine Gesetz verhandelt, in dem es darum geht, das regeln soll wie in Zukunft die Geschäftsmodelle rund um das Internet aussehen sollen. Das dabei extrem viel Mist erzählt wird, zeigt eine Video eines Piraten



Aber das ist nur die Halbe Wahrheit. Denn ich bin selber Internetanbieter. Ich betreibe eine Kleines WLAN das einen Stadtteil mit breitbandigen Internet versorgt. Erstanden ist dieses Netz im September 2001 weil ich mit die Kosten meinens Monopolübertragungsweges nicht mehr leisten konnte und wollte, und so habe ich einen Großteil der Entwicklung des Internets an vorderster Front mitbekommen.

Das Internet und seine Anwendungen waren in der Vergangenheit immer auch eine Maximal effektive Ausnutzung knapper Ressourcen hin ausgelegt. Es haben auch immer alle Mitgemacht, weil sich Anbieter und Konsumenten die Kosten für das Internet geteilt haben. Jeder bezahlte den Teil des Weges bis zum Austauschpunkt, an dem die Daten von einem Anbieter zum nächsten weitergeben werden. So hatte jeder einen Ansporn zu sorgfältigem Umgang mit den Ressourcen.

Das hat sich aber im Laufe der Jahre extrem gewandelt. Anbieter - bezogen auf das Verkehrsaufkommen - gibt es kaum noch. Das sind im Wesentlichen die Großen Konzerne wie Apple, Microsoft, Google, Facebook, ... sowie die Medienanstalten, öffentlich Rechtliche wie Private. Diese haben längst Standleitungen zu den Austauschpunkten, sind also wenn man so will ihr eigener Internetprovider. Die Leistungsfähigkeit der Glaskabel und der dazugehörigen Router ist in den letzten Jahren so explodiert, das die Kosten für sehr viel mehr Verkehr verschwindend gering sind gegenüber denen, die nötig sind die Effizienz der Dienste zu verbessern. Sehr schön lässt sich das im Videobereich belegen, bei dem eben nicht versucht wird, das Optimum an Kompression aus den Vorhandenen Codecs herauszuholen oder sogar auf neue Entwicklungen zurückzugreifen, welche mit nur einem Bruchteil der Übertragenen Daten das gleiche erreichen.

Und genau an dieser Stelle muss ... soll sinnvolles Wirtschaften für Internetprovider überhaupt noch möglich sein, dieses ein Mittel an die Hand gegeben werden, mit dem sie auf Anbieter einwirken können, eben doch Geld in die Hand zu nehmen, um die Effizienz ihrer Systeme zu Steigern. Diese Effizienz kann zum Beispiel in der Cachebarkeit der Daten liegen. Konnte ich am Anfang meiner Tätigkeit als ISP noch über 80% des Traffic aus dem Proxy Cache bestreiten, sind es heute nicht mal 20% Prozent. Das ist ganz wesentlich vier Entwicklungen geschuldet:

  1. Durch den Fortwährenden Spionageterror durch die NSA gehen immer mehr Anbieter dazu über, Software per https:// zu verteilen. Dabei nutzt das nichts, weil sich aus IP und der Menge der übertragenen Daten welche vom https nicht geschützt ist, sich schon eindeutig Festellen lässt wer welchen öffentlich zugänglichen Inhalt heruntergeladen hat. Neben dem Vermeidlich Vorteil der Verschlüsselung erspart es den Anbieter aber auch den Aufwand, die Integrität der Übertragung gesondert zu überprüfen ... verhindert aber das Caching.

    Microsoft - hier muss ich sie mal ausnahmsweise und auch noch öffentlich lobend erwähnen - hat deshalb eine Initiative gestartet für ein httpi:///, das die Integrität der Übertragung sichert aber Caching zulässt. Nur Leider ist Verschlüsselung durch in die Prozessoren eingelassene Hardware so billig geworden und so viele Kunden bei Ex Monopolanbieter, das dieses keine Resonanz gefunden hat.
  2. Durch die super idiotische Vorgabe der EU, das Benutzer vom Inhalteanbieter über das Setzen von Cookies zu Informieren sind, sind viele Anbieter denen die EU aus welchen gründen auch immer nicht Arsch vorbeigeht um die Benutzer nicht mit Blödsinnigen Juristensültz zu vergraulen dazu übergegangen, ihre Angebote so zu erstellen, das es sie im Internet unendlich oft gibt. Wo es früher http://server.domain.de/path/file.xxx gab wird der Webserver so Programmiert das er auf http://server.domain.de/besuchernummer/path/file.xxx weiterleitet, und jeder Besucher so seine eigene Kopie des Content vorgesetzt bekommt. Damit ist aber die Cachebarkeit beim Teufel, weil das ist nicht Standardisiert ist.

    Die Behandlung der Cookies ist Sache der Software. Dummerweise wenn man wie ich z.B. eine Funktion Nutzt alle Cookies am ende einer Session zu entsorgen, dann wird man bei vielen Anbieter jedes mal mit dem Jurasülz der Hausjuristen dieser Anbieter belästigt. Die Technologie jedem Besucher seine eigene Suppe zu kochen ist auch in sofern ein Problem, als das dann die Einheitlichkeit des web nicht mehr gegeben sein muss. Wer sagt denn, das sich die Inhalte nur in den Besuchernummern in den internen Links unterschieden? Das könnten zum Beispiel für IP aus Muslimischen Ländern bestimmte Dinge im Wege der Sebstzensur entsorgt werden (Alkohol, Schinken, ...) und vieles andere Mehr.
  3. Die Ideologische Ablehnung von jeder Form der Kopie die kein Geld in die Kasse bringt seitens der Content Industrie. Ausnahmslos alle bezahl Video on Demand Dienste Senden Ihr Material so, das es nirgendwo gecached wird, nicht mal im Endgerät. Jeder Schnippsel wie eine DNS Anfrage wird aus Traditionellen gründen lokal gecached ... was auch Probleme macht weil immer wieder Regierungen versuchen diese Caches wenn möglich manipulieren zu lassen ... nur die HD und 4kHD Videos sollen bei jedem Ansehen in epischer Breite durch das Netz geprügelt werden? Dazu werden dann proprietäre Protokolle verwendet, die obendrein noch verschlüsselt sind.

    Würde ein Film verschlüsselt an einer Stelle publiziert, und die Lizenznehmer alle auf diese url Bezug nehmen und nur noch ihren Schlüssel zum Entschlüsseln des Materials individuell verschlüsselt übertragen ... so wie es auf der Blu Ray Disk gemacht wird ... könnten sehr wohl die Interessen der Content Anbieter mit denen der ISP in Einklang gebracht werden. Da aber Filmbosse bei dem Wort Kopie Pickel am Gesäß bekommen, bedarf es hier eine über den §§44a UHRG hinausgehende Hilfestellung durch den Gesetzgeber.
  4. Ideal für die Verbreitung von Videos wäre, wenn es einen optimalen Videostandart gäbe. Optimaler weiße sollte der sogar so aufgebaut sein, das es für die Unterschiedlichen Qualitäten eine Basisdatei und weitere zur Stufenweise Erhöhung der Auflösung geben sollte. Praktisch würde das dann so aussehen, das bei begrenzter Kapazität Filme um so genauer Aufgelöst wird, je öfters er angesehen wird, weil sich immer mehr Stufen auf der Leiter zu höheren Auflösungen im Cache sind. Bedingt durch Pantentzickereien zwischen den Großen Anbietern sieht die Realität ganz anderes aus. Im Gegensatz zu Bildern braucht man so ziemlich für jedes Gerät eine Eigne Version des an sich gleichen Inhalts. Auch ein eklatanter Missstand!
Ein weiteres Wesentliches Problem der Netzneutralität ist die Verträglichkeit der Anwendungen. Auch hier gibt es Leute, die nichts von Netzneutralität halten und versuchen mit allerlei Tricks sich einen Vorteil zu verschaffen. Wird kein weiteres Management wie das statistical Fair queing getroffen, so ist die Einfachste alle Masnamen, in einem Programm einfach 100 TCP/IP Parallel zu öffnen. Dann bekommt an in einem Nadelöhr eben auch 100 Anteile anstatt nur einen. Noch sehr viel effektiver ist es, einen speziellen modifizierten TCP/IP Stack zu benutzen, der mittels zusätzlicher Forward Error Correction einzelne Pakete ohne sie erneut Anzufordern Rekonstruieren kann. Da dieser mit Paket Verlust leben kann, kann er die anderen Rausdrücken. Als Beispiel für eine gelungene Vordrängelimplementierung kann die Downloadplattform Steam betrachtet werden. Ein Netz in dem ein Download mit Steam läuft, ist für die anderen Nutzer tot.

Folglich muss ein Provider der wie ich auf Einheitlichen Verbindungen beruht, den Zugang einzelner Benutzer zu den Ressourcen künstlich sehr weit verringern, damit an jeder Verzweigung kein "Kanal voll mit Steamdaten" auftreten kann. Schade, denn wenn das Netz zum Beispiel Nachts leer ist könnte ein Benutzer auch mit allen Ressourcen beglückt werden. Das setzt aber im Interesse der anderen Nutzer aus, das Ego-Anwendungen wie Steam auf ein Sozial verträgliches Maß gedrosselt werden können.

Noch ein paar Worte zu dem Arzt der eine Fern-Op macht. Da wird man hoffentlich Mietleitungen verwenden. Aber ich hatte einen Arzt als Kunden, der Radiologe ist. Der hatte Bereitschaftsdienste, die er per Remote Desktop Anwendung gemacht hat. Diese Anwendung reagiert ziemlich schlecht auf Überlastungen im Netz. Für ihn war es in die der Beurteilung wichtig, einen Ebene des CT durch den Körper bewegen zu könne. Da aber kein video Runtergeladen wurde sondern dieses nur per Remote Desktop gemacht wurde, ging das nur bei relativ leerem Netz. Es kam also vor, das er wegen großem Datenverkehrsaufkommen in die Klinik fahren musste, und das kann unter extrem unglücklichen Umständen Tatsächlich zum Tod eines Patienten führen. Er ist dann auch - sobald das möglich war - vermutlich zu LTE at Home umgestiegen, die einen Vorrangtransport machen können. Und jeden Arzt der Bereitschaftsdienst hat mit einer Standleitung auszustatten, das können sich die Kliniken nicht Leisten. Netzneutralität erfordert auch eine gewisse Disziplin bei der Erstellung von Software, so das diese mit Kapazitätsengpässen adäquat umgeht.

Es wäre sehr wünschenswert, wenn administrative Maßnahmen dazu führen würden, das Content wieder mehr Cachebar ist. Mit Satelliten kann man einen sehr schnellen Zugang zum Internet herstellen, der auch jeden Winkel abdeckt. Aber das setzt voraus, das großer und beliebter Content per Multicast an Tochter Proxy verteil wird. So funktioniert sky Video on Demand. Ansonsten muss das Kontingent streng rationiert werden. Wer sein X-GB verballert hat, kriecht den Rest des Monats. Und Videoanwendungen die wenn möglich Full oder 4K HD senden, saugen so ein Kontingent binnen Minuten Leer. Da ist manch einer froh um ein automatisches Management, das solche Anwendungen zur Sparsamkeit anhält. Im LTE Steigen die maximalen Datenraten sehr viel schneller an als es die Gesamtübertragungskapazität in der Funkzelle tut. Sollen diese Netze nicht hoffnungslos verstopfen, muss es auch zu einer Verbreitung von häufig nachgefragten Content in die Caches der Geräte kommen. Dafür eignen sich ... das beweist dbv-t jeden Tag, die terrestrischen TV-Frequenzen besonderes gut.

Zum Schluss möchte ich noch auch die Cloud Backup und Sync Services eingehen. Android zum Beispiel: Backup zu Google, Sync über Google. Überall ist automatisch NSA und FISA mit drin. Hier muss eine Gesetzliche Reglung her, die es dem Kunden ermöglicht lokales Equipment zu nutzen. Sei es eine FTP-NAS in der einen Wohnung (z.B. Friz-Box) oder sei es ein lokaler Speicher mit Profi Raid beim lokalen ISP-Knoten. Je näher der Speicher am Kunden dran ist, desto besser, werden doch bei einem Recover binnen kurzer Zeit Tausende Giga Byte an Traffic gebraucht.

Nachtrag 22.05: Unfassbar wie mache Inhalte Anbieter mit den Ressourcen eines Netzwerks Umgehen. Blizzard.com hat die Unverschämtheit, im ms Sekundentakt neue Verbindungen auf zumachen um dann grosse Dateien in ungefähr KB großen Happen zu holen. So kann man jeden Proxyserver zu lasten aller anderen Nutzer blockieren.

Ich habe auch schon Transfers auf Port 179 - das ist der des BGP mit dem das Internet gesteuert wird - gesehen. Netneutralität kann es nicht ohnne strege Regulierung für Downloadprogramme geben, denn ohne müsse ISP solche Penner bremsen können.


1432229171.458     55 172.16.20.165 TCP_MISS/206 1127 GET http://llnw.blizzard.com/tpr/d3/patch/88/f6/88f62cb4d073b55d0393ee1213d11a06 - FIRST_UP_PARENT/127.0.0.1 application/octet-stream
1432229172.252     18 172.16.20.165 TCP_MISS/206 1129 GET http://llnw.blizzard.com/tpr/d3/patch/88/f6/88f62cb4d073b55d0393ee1213d11a06 - FIRST_UP_PARENT/127.0.0.1 application/octet-stream
1432229172.253     18 172.16.20.165 TCP_MISS/206 1285 GET http://llnw.blizzard.com/tpr/d3/patch/88/f6/88f62cb4d073b55d0393ee1213d11a06 - FIRST_UP_PARENT/127.0.0.1 application/octet-stream
1432229172.303     51 172.16.20.165 TCP_MISS/206 1285 GET http://llnw.blizzard.com/tpr/d3/patch/88/f6/88f62cb4d073b55d0393ee1213d11a06 - FIRST_UP_PARENT/127.0.0.1 application/octet-stream
1432229172.308     55 172.16.20.165 TCP_MISS/206 1129 GET http://llnw.blizzard.com/tpr/d3/patch/88/f6/88f62cb4d073b55d0393ee1213d11a06 - FIRST_UP_PARENT/127.0.0.1 application/octet-stream
1432229172.353     49 172.16.20.165 TCP_MISS/206 1285 GET http://llnw.blizzard.com/tpr/d3/patch/88/f6/88f62cb4d073b55d0393ee1213d11a06 - FIRST_UP_PARENT/127.0.0.1 application/octet-stream
1432229172.486     12 172.16.20.165 TCP_MISS/206 1315 GET http://llnw.blizzard.com/tpr/d3/patch/88/f6/88f62cb4d073b55d0393ee1213d11a06 - FIRST_UP_PARENT/127.0.0.1 application/octet-stream
1432229172.492     15 172.16.20.165 TCP_MISS/206 4544 GET http://llnw.blizzard.com/tpr/d3/patch/88/f6/88f62cb4d073b55d0393ee1213d11a06 - FIRST_UP_PARENT/127.0.0.1 application/octet-stream
1432229172.543     50 172.16.20.165 TCP_MISS/206 1145 GET http://llnw.blizzard.com/tpr/d3/patch/88/f6/88f62cb4d073b55d0393ee1213d11a06 - FIRST_UP_PARENT/127.0.0.1 application/octet-stream
1432229173.283     16 172.16.20.165 TCP_MISS/206 1287 GET http://llnw.blizzard.com/tpr/d3/patch/88/f6/88f62cb4d073b55d0393ee1213d11a06 - FIRST_UP_PARENT/127.0.0.1 application/octet-stream
1432229173.290     23 172.16.20.165 TCP_MISS/206 1800 GET http://llnw.blizzard.com/tpr/d3/patch/88/f6/88f62cb4d073b55d0393ee1213d11a06 - FIRST_UP_PARENT/127.0.0.1 application/octet-stream
1432229173.347     63 172.16.20.165 TCP_MISS/206 3836 GET http://llnw.blizzard.com/tpr/d3/patch/88/f6/88f62cb4d073b55d0393ee1213d11a06 - FIRST_UP_PARENT/127.0.0.1 application/octet-stream
1432229173.347     57 172.16.20.165 TCP_MISS/206 3097 GET http://llnw.blizzard.com/tpr/d3/patch/88/f6/88f62cb4d073b55d0393ee1213d11a06 - FIRST_UP_PARENT/127.0.0.1 application/octet-stream
1432229173.397     49 172.16.20.165 TCP_MISS/206 1131 GET http://llnw.blizzard.com/tpr/d3/patch/88/f6/88f62cb4d073b55d0393ee1213d11a06 - FIRST_UP_PARENT/127.0.0.1 application/octet-stream
1432229173.645     14 172.16.20.165 TCP_MISS/206 7159 GET http://llnw.blizzard.com/tpr/d3/patch/88/f6/88f62cb4d073b55d0393ee1213d11a06 - FIRST_UP_PARENT/127.0.0.1 application/octet-stream
1432229173.650     13 172.16.20.165 TCP_MISS/206 4524 GET http://llnw.blizzard.com/tpr/d3/patch/88/f6/88f62cb4d073b55d0393ee1213d11a06 - FIRST_UP_PARENT/127.0.0.1 application/octet-stream