Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

Unterschiede zwischen SSL und TLS_1_

VIEWS: 18 PAGES: 17

									Name:           Kolja Engelmann                                                                                       Berlin, 24.02.2010
Matr. Nr. :     708383                                                                                                    Seite 1 von 17




Aufgabe 1
Es sei folgendes IP- Paket gegeben:

45 00     05 78 00 01 1f bd ff 06 15 6e c0 a8 00 01
c0 a8     00 02 08 00 07 f8 00 00 00 02 00 00 00 01
50 10     75 30 2a c4 00 00 00 00 00 00 00 00 00 00
...
00 00     00 00 00 00 00 00 00 00 00 00 00 00 00 00

Gesamtanzahl Bytes: 1400

Dekodieren Sie das Paket!
45 00     05 78 00 01 1f bd ff 06 15 6e c0 a8 00 01
c0 a8     00 02 08 00 07 f8 00 00 00 02 00 00 00 01
50 10     75 30 2a c4 00 00 00 00 00 00 00 00 00 00
...
00 00     00 00 00 00 00 00 00 00 00 00 00 00 00 00

„45“ ist die Zahl mit der das zu dekodierende IP- Paket anfängt, was binär gesehen
„0100 0101“ entspricht. Folglich wurde für das IP- Paket IPv4 verwendet. Für die weitere
Dekodierung verwenden wir eine Skizze die Aufschluss über den Aufbau eines IPv4-
Pakets gibt.
                                                                          16bit




                                                                                                                             32bit
                                         8bit




              IP Version         HLEN                  Service Type                       Länge des gesamten Pakets


                                      Identification                              Flags             Fragment Offset


                           TTL                           Protocol                             Header Checksum


                                                                        Source IP


                                                                      Destination IP


                                                         Options                                                Padding


                                                                           Data


                                                                           ...
Die „45“ besagt zusätzlich, dass der Header eine Standardlänge von 20 Byte hat, was
gleichzeitig auch die minimale Kopflänge ist. Diese Länge wird erzeugt indem die 4 Bit in
eine Dualzahl umgeformt und anschließend mit 32 multipliziert werden. Das ermittelte
Ergebnis wird nun noch durch 8 dividiert und man erhält 20 Byte (5*32/8 = 20).

Die sich anschließenden Ziffern „00“ bestimmt den „IP Type of Service“. Was sie genau
ausdrücken findet man im RFC0791.

         Bits         0-2         :    Precedence.
         Bit          3           :    0 = Normal Delay,        1 = Low Delay.
         Bit          4           :    0 = Normal Throughput, 1 = High Throughput.
         Bit          5           :    0 = Normal Relibility,   1 = High Relibility.
         Bits         6-7         :    Reserved for Future Use.

   0    1     2     3      4     5     6     7
+-----+-----+-----+-----+-----+-----+-----+-----+
|                 |     |     |     |     |     |


                                                                          -1-
Name:         Kolja Engelmann                                              Berlin, 24.02.2010
Matr. Nr. :   708383                                                           Seite 2 von 17




|    Precedence   | D | T | R | 0 | 0           |
|                 |     |     |     |     |     |
+-----+-----+-----+-----+-----+-----+-----+-----+

Precedence:

Network Control
      110    - Internetwork Control
      101    - CRITIC / ECP
      100    - Flash Override
      011    - Flash
      010    - Immediate
      001    - Priority
      000    - Routine

Dies besagt also „Precedence“ => „Routine“, „D; T; R“ => „normal“ und die reservierten
Felder bleiben frei, also gleich null.
Mit der Ziffernfolge „05 78“ wird die Gesamtlänge des Pakets mit 1400 Byte identifiziert.
Bei den folgenden Ziffernpaaren „00 01“ ist der Paketzähler gleich 0x0001 (dezimal: 1)
und kennzeichnen somit das erste Paket.
„1F BD“ beinhaltet Informationen im Bezug auf Flags (ersten drei Bits) sowie über das IP
Fragment Offset.
Auch hier beschreibt RFC0791 was dies genau bedeutet.

         Flags : 3 bits
         Various Control Flags.

         Bit 0 : reserved, must be zero
         Bit 1 : (DF) 0 = May Fragment, 1 = Don’t Fragment.
         Bit 2 : (MF) 0 = Last Fragment, 1 = More Fragements.

         +----+----+----+
         |    | D | M |
         | 0 | F | F |
         +----+----+----+

„1“ ist binär gleich „0001“. Das erste Bit ist somit erwartungsgemäß gleich null, die
Werte für DF und MF sind jedoch widersprüchlich. Während die DF=0 bedeutet, dass das
Paket fragmentiert sein kann, bedeutet MF=0, dass es das letzte Fragment ist. Hieraus
folgt „0F BD“ ist der IP Fragment Offset, der die Fragmentposition im Datagram angibt.
Problematisch ist dies, da das Paket das erste und das letzte Paket des Datagrams ist,
also nicht noch weitere Fragmente folgen, wie in DF angedeutet.
Das sich anschließende Paar „FF“ gibt Auskunft über die maximale „time to live“, was in
diesem Fall 255 Hops wären. „06“ ist die Protokoll-ID für TCP und „15 6E“ die IP-Header-
Prüfsumme. Die letzten 8 Byte des Kopfes geben die Quell- und Zieladresse an, welche in
diesem Fall „192.168.0.1“ und „192.168.0.2“ lauten. Die restlichen Bytes sind Nutzdaten
(andere Header oder Programmdaten).

Finden Sie das Sicherheitsproblem im Paket, das durch einen
Paketfilter erkennbar ist!
Die Sicherheitslücke ist schwer zu finden, da es sich um ein Paket handelt, welches
innerhalb eines lokalen Netzes verschickt wurde, da 192.168.*.* eine für lokale Netze
reservierter Adressraum ist. Gemeinhin betrachtet man das Interne Netz als sicher und
erwartet keine Attacken von internen Teilnehmern gegeneinander. Gäbe es jedoch einen
Paketfilter für das interne Netz, über den der gesamte Intranetverkehr laufen müsste, so
würde dieser an der Stelle „1F BD“ ein Sicherheitsproblem erkennen, da es das erste und
letzte Paket ist und trotzdem einen Offset ungleich null enthält.



                                           -2-
Name:         Kolja Engelmann                                              Berlin, 24.02.2010
Matr. Nr. :   708383                                                           Seite 3 von 17




Egal ob es sich um einen Übertragungsfehler oder eine bewusst herbei geführte Attacke
handelt, würde das Paket verworfen werden.

Geben Sie ein Beispiel für ein Sicherheitsproblem, das nur durch
einen zustandsbehafteten Filter erkennbar ist!
Ein zustandsbehafteter Filter, das heißt ein dynamischer Paketfilter ist nötig, um einem
TCP- Hijacking entgegenzuwirken. In diesem Fall wird sich die Quell-/ Ziel- Adresse,
sowie der jeweilige Port gemerkt, um somit „zeitlich begrenzt gültige dynamische
Erlaubnisregel“ anwenden zu können. Da auf diesem Weg festgestellt werden kann,
welche Adressen und Portnummern erwartet werden, kann ausgeschlossen werden, dass
ein Angreifer nach einem Angriff mit Sequenznummern erhöhenden Paketen die
entsprechende Verbindung selbst verwenden kann, da in diesem Fall andere Adressen
und Portnummern vorliegen würden.
Aufgabe 2
Was ist NAT (Source NAT) und welche Sicherheitsfunktionalitäten
können mit NAT realisiert werden?
NAT dient dem Verbergen der lokalen IP- Adresse hinter einer einzigen offiziellen IP-
Adresse. Diese häufig auch "Masquerading" genannte Technik wird auf Routern, Proxy-
Servern und Firewalls eingesetzt, die dahinterliegende Netze schützt (denn was nicht
bekannt ist, kann auch nicht gezielt angegriffen werden) und die Verwendung privater IP-
Adressen ermöglicht. NAT wird im allgemeinen eingesetzt, wenn in einem
Unternehmensnetzwerk nur ein sehr beschränkter Adressraum für Internetverbindungen
zur Verfügung steht, denn durch Einsatz des Übersetzungsverfahrens kann ein großer
Adressraum benutzt werden. Gewöhnlich reisen Pakete in einem Netzwerk von ihrer
Quelle (z.B. Dein Computer) zu ihrem Ziel (z.B. www.uni-potsdam.de) durch viele
verschiedene Links. Üblicherweise verändert keiner dieser Links das Paket wirklich, sie
schicken es einfach weiter. Würde allerdings einer dieser Links NAT verwenden, dann
würde er die Quelle oder das Ziel des Pakets verändern, sobald es eintrifft. Das System
wurde allerdings nicht entworfen, auf diese Art zu arbeiten, also ist NAT immer etwas,
was man mit Vorsicht behandeln sollte. Gewöhnlich wird sich der Link, der NAT
verwendet, daran erinnern, wie er das Paket verändert hat, und wenn ein Antwortpaket
aus der anderen Richtung kommt, wird er genau das Umgekehrte darauf anwenden, und
so ist es dann auch funktionsfähig.

NAT ist also ein Verfahren zur Erhöhung der Zahl der IP- Adressen speziell innerhalb von
Firmennetzen. Im Gegensatz zu IPv6 (IPnG) kann NAT allerdings nur Firmennetzintern
und hin zum Internet verwendet werden.
Das NAT-Verfahren registriert die IP- Adressen eines privaten Netzes und ordnet sie
öffentlich registrierten IP- Adressen zu. Der Vorteil dieses Verfahrens liegt darin, dass
Rechner, die nur innerhalb des Firmennetzes miteinander kommunizieren, keine
öffentlichen IP- Adressen benötigen. Die Rechner, die eine Kommunikation zu anderen,
externen Rechner aufbauen, erhalten beim Routing einen Tabelleneintrag.




                                           -3-
Name:         Kolja Engelmann                                              Berlin, 24.02.2010
Matr. Nr. :   708383                                                           Seite 4 von 17




Des Weiteren lässt NAT sich in zwei Varianten unterteilen. Zum einen in Basic NAT und
zum anderen in Traditional NAT. Basic NAT ist eine Methode, die IP- Adressen zwischen
verschiedenen Gruppen abbildet und für den Nutzer transparent ist. Traditional NAT
hingegen bietet einen expliziten Mechanismus an, der einen privaten Adressbereich
anbindet an einen mit global eindeutig registrierten Adressen versehenen Bereich.
Realisiert wird dies per Network Address Port Translation (NAPT).
Stellt sich nun die Frage, warum man NAT benötigt und welche Sicherheitsfunktionen
NAT ermöglicht.

Modemverbindungen zum Internet
Die meisten Internetanbieter geben eine einzelne Adresse weiter, wenn man sich bei
ihnen einwählt. Ein Privatnutzer hingegen kann Pakete mit einer beliebigen Quelladresse
verschicken, allerdings nur Pakete mit der zuvor erhaltenen Antwortadresse wieder
empfangen. Wenn Du mehrere verschiedene Maschinen (so wie ein Heim-Netzwerk)
benutzen willst, um Dich durch diesen Link mit dem Internet zu verbinden, wirst Du NAT
brauchen. Dies ist die heute am meisten verbreitete Art von NAT, gewöhnlich in der
Linuxwelt als ‚Masquerading' bekannt. Ich nenne dies SNAT, weil die Quell ('source')
Adresse des ersten
Pakets verändert wird.

Mehrere Server
Es gibt Situationen in denen man den Zielort eines einkommenden Pakets im eigenen
Netzwerk nachträglich ändern möchte. Oft liegt der Grund darin, dass man (wie oben
erwähnt) nur eine IP- Adresse zur Verfügung hat, den Nutzern aber die Möglichkeit
geben möchte auch die Rechner hinter dem mit der 'echten' IP- Adresse versehenen
Rechner zu erreichen. Dies ist möglich, wenn man das Ziel von einkommenden Paketen
ändern kann. 'Load-sharing' ist eine bekannte Variation dessen. Hierbei wird eine große
Anzahl von Paketen über eine Reihe von Maschinen verändert, indem ein 'auffächern' der
Pakete durchgeführt wird. In früheren Linuxversionen wurde diese Version von NAT Port-
Forwarding genannt.

Transparente Proxies
Ebenfalls kann es vorkommen, dass man vortäuschen möchte, dass jedes Paket, welches
durch den persönlichen Linuxrechner geht, für ein Programm auf dem Linuxrechner
selbst bestimmt ist. Dies wird für transparente Proxies verwendet. Hierbei handelt es sich


                                           -4-
Name:         Kolja Engelmann                                              Berlin, 24.02.2010
Matr. Nr. :   708383                                                           Seite 5 von 17




um ein Programm, das zwischen dem eigenen Netzwerk und der Außenwelt positioniert
ist und die hier stattfindende Kommunikation regeln soll. Der transparente Teil entsteht,
weil das Netzwerk nicht bemerkt, dass es mit einem Proxy redet, es sei denn natürlich,
der Proxy ist in seiner Funktionsweise defekt. Squid kann auf diese Art konfiguriert
werden. In früheren Linuxversionen hieß das Umleiten (redirection) oder auch
transparentes Proxying.

Die Sicherheitsfunktionalitäten mit NAT und in wie Fern sie zu realisieren sind soll in
folgendem Teil behandelt werden.
Zum einen gibt es die Firewallsicherheit mit Hilfe von Maskierung. In diesem Fall wird
versucht mit Hilfe einer Firewall ein einzelner Zugangspunkt vom Netzwerk in die
„Außenwelt“ und die „Innenwelt“ abzusichern. Durch diesen Schutzmechanismus kann
ein privates Netzwerk geschützt werden, da ohne äußeren Zugriff auf das Innere Netz,
eine Kommunikation von Innen nach Außen möglich ist. Durch das gebrauchen der NAT-
Maskierung verändert sich der IP-Header aller ausgehenden Paketen in der Weise, das es
den Anschein hat, als würden alle Anfragen von ein und derselben Adresse kommen. Alle
Antwortpakete werden dann dementsprechend zurückübersetzt an die jeweilige Maschine
im inneren Netz weitergeleitet. Eine direkte Kommunikation zwischen den Rechnern
findet also nicht statt und ein Angriff auf Interne Rechner ist somit quasi nicht möglich.
Vorsicht sollte allerdings geboten sein, da Umgehungsmöglichkeiten existieren.
Eine weitere Variante der Sicherheit liegt in der interaktiven Website Security. Gegebnen
sei eine Website mit Java- Applets, CGI- Skripten, etc. bei denen zusätzlich zu
schützende Daten auf einer Datenbank liegen, welche an diese Seite angebunden ist. In
diesem Fall sollte die Datenbank durch eine Firewall geschützt werden, bei den Skripten
ist dies nicht notwendig, sie können noch vor der Firewall liegen. Das Zugriffsproblem
zwischen der Datenbank und den einzelnen Skripten kann mit Hilfe von NATP gelöst
werden. Der Sinn dieser Anwendung liegt darin, dass es scheint als gäbe es keine
Datenbank, sondern nur die Firewall auf welche die Skripte zugreifen, die sich ja
eigentlich vor der Firewall befinden.
Kommen wir nun zu der Letzten hier vorgestellten Sicherheitsvariante von NAT, den
mobilen Angestellten. Es lässt sich ein autorisierter Zugriff auf Firmennetze und Ihre
Ressourcen mit Hilfe von NAT und IPSec durchführen. Absicherrungen des internen
Netzes, welche mit Hilfe von NAT- Firewalls vorliegen sind hierbei nicht zu
kompromittieren. Der gesicherte Kanal verläuft vom mobilen Mitarbeiter bis zur Firewall,
da NAT kein Ende zu Ende Verschlüsselung zulässt. Ab der Firewall gelten die
entsprechenden Regeln, welche zuvor von Nutzer X festgelegt wurden. Dieser kann
bestimmen ob ein Maximaler Zugriff, sprich ein Zugriff auf das gesamte Netz zulässig ist,
oder aber nur ein Minimaler Zugriff, welcher das Gegenteil aussagt, d.h. zum Beispiel den
Zugriff auf eine einzelne Ressource.

Was ist bezüglich FTP zu beachten?
Bei NAT ist eine so genannte Verbindungsüberwachung von Nöten, das heißt die
Zugehörigkeit der Verbindung. Um diese Notwendig zu verdeutlichen folgendes Beispiel.
Hinter einer Nat greifen mehrere verschiedene FTP-Clients auf unterschiedliche Daten
von ein und dem Selben FTP-Server zu. Folglich muss sich natürlich gemerkt werden wer
auf was zugegriffen hat, da sonst nicht garantiert werden kann, dass wirklich jeder FTP-
Client auch seinen Download erhält. Des Weiteren wäre es möglich, dass mehrere Clients
Dateien hinter einer „Destination NAT“ von einem „load-balanced“- FTP-Server anfordern.
Die Zugehörigkeit zwischen Client und Server muss hierfür bekannt sein, sich also
irgendwo gemerkt werden.

  3. Die zwei Formen von NAT

  Ich unterscheide NAT in zwei verschiedene Typen: Source Nat (SNAT) und
  Destination NAT (DNAT).




                                           -5-
Name:         Kolja Engelmann                                              Berlin, 24.02.2010
Matr. Nr. :   708383                                                           Seite 6 von 17




  Wenn Du die Quelladresse des ersten Pakets änderst, ist das Source
  NAT: Du veränderst den Ursprung der Verbindung. Source NAT ist immer
  Post- Routing, es wirkt, gerade bevor das Paket in die Leitung geht.
  Masquerading ist eine spezielle Form von SNAT.


  Wenn Du die Zieladresse des ersten Pakets änderst, ist das Destination
  NAT: Du veränderst das Ziel, wohin die Verbindung geht. Destination
  NAT ist immer Pre-Routing, gerade wenn das Paket aus der Leitung
  kommt. Port-Forwarding, load-sharing und transparente Proxies sind
  alles Formen von DNAT.


  4. Schnelle Übersetzung vom 2.0er und 2.2er Kernel

  Sorry an alle von Euch, die noch immer geschockt sind vom Übergang
  von 2.0 (ipfwadm) auf 2.2 (ipchains). Es gibt gute und schlechte
  Neuigkeiten.


  Zuerst einmal kannst Du ipfwadm und ipchains wie gewohnt
  weiterbenutzen. Um das zu tun, musst Du das 'ipchains.o' oder
  'ipfwadm.o' Kernelmodul aus der letzten netfilter-Distribution laden
  (insmod). Diese beiden schliessen sich gegenseitig aus (Du bist
  gewarnt) und sollten nicht mit anderen netfilter-Modulen kombiniert
  werden.


  Sobald eins dieser Module installiert ist, kannst Du ipchains und
  ipfwadm wie gewohnt benutzen, mit den folgenden Unterschieden:


  o Das Masquerading Timeout mit ipchains -M -S, oder mit ipfwadm -M
    -S, zu setzen, bringt nichts. Da die neuen Timeouts der neuen NAT-
    Infrastruktur länger sind, sollte das aber egal sein.


  o Die init_seq, delta und previous_delta Felder in der ausfuehrlichen
    Masqueradingliste sind immer Null.

  o Gleichzeitig die Zähler auflisten und auf Null setzen (-Z -L)
    funktioniert nicht mehr: Die Zähler werden nicht zurückgesetzt.

  Für Hacker:


  o Du kannst jetzt auch Ports von 61000-65095 einbinden, sogar wenn Du
    Masquerading machst. Der Masquerading Code hatte frueher
    angenommen, dass alles im diesem Bereich freigehalten werden
    sollte, so dass Programme ihn nicht nutzen konnten.

  o Der (undokumentierte) 'getsockname' Hack, welchen man nutzen
    konnte, um bei transparenten Proxies das wirkliche Ziel
    herauszufinden, funktioniert nicht mehr.

  o Der (undokumentierte) 'bind-to-foreign-address' Hack ist auch nicht
    implementiert; dies wurde verwendet, um die Illusion von
    transparenten Proxies komplett zu machen.



                                           -6-
Name:         Kolja Engelmann                                             Berlin, 24.02.2010
Matr. Nr. :   708383                                                          Seite 7 von 17




  4.1. Ich will nur Masquerading! Hilfe!

  Das ist das, was die meisten Leute wollen. Wenn Du durch eine PPP-
  Verbindung eine dynamische IP-Adresse hast (wenn Du das nicht weisst,
  dann hast Du eine), möchtest Du Deinem Rechner einfach sagen, dass
  alle Pakete, die aus Deinem internen Netzwerk kommen, so aussehen
  sollen, als ob sie von dem Rechner mit der PPP-Verbindung kommen
  würden.



      # Das NAT-Modul laden (dies zieht all die andern mit).
      modprobe iptable_nat

      # In der NAT-Tabelle (-t nat) eine Regel fuer alle an ppp0 (-o ppp0)
      # ausgehenden Pakete hinter dem Routing (POSTROUTING), die maskiert
      # werden sollen, anhaengen (-A).
      iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

      # IP-Forwarding aktivieren
      echo 1 > /proc/sys/net/ipv4/ip_forward



  Beachte, dass Du hier keine Pakete filterst: hierzu lese das Packet-
  Filtering-HOWTO: Kombinieren von NAT und Paketfiltern.


  4.2. Was ist mit ipmasqadm?

  Das ist eine verzwicktere Sache, und ich habe mir hier keine grossen
  Sorgen um die Rueckwaerts-Kompatibilitaet gemacht. Um Port-Forwarding
  zu verwenden, kannst Du einfach 'iptables -t nat' benutzen. Unter
  Linux 2.2 haettest Du es zum Beispiel so machen koennen:



      # Linux 2.2
      # TCP-Pakete, die an 1.2.3.4 Port 8080 gehen, an 192.168.1.1 Port 80
      # weiterleiten
      ipmasqadm portfw -a -P tcp -L 1.2.3.4 8080 -R 192.168.1.1 80

  Jetzt wuerdest Du folgendes tun:



      # Linux 2.4
      # Eine Pre-Routing (PREROUTING) Regel an die NAT-Tabelle (-t nat) an-
      # haengen (-A), die besagt, dass alle TCP-Pakete (-p tcp) fuer 1.2.3.4
      # (-d 1.2.3.4) Port 8080 (--dport) auf 192.168.1.1:80
      # (--to 192.168.1.1:80) gemappt werden (-j DNAT).
      iptables -A PREROUTING -t nat -p tcp -d 1.2.3.4 --dport 8080 \
      -j DNAT --to 192.168.1.1:80




                                            -7-
Name:         Kolja Engelmann                                             Berlin, 24.02.2010
Matr. Nr. :   708383                                                          Seite 8 von 17




  Wenn Du willst, dass diese Regel auch lokale Verbindung veraendert
  (ich meine, wenn sogar auf dem NAT-Rechner selbst ein Telnet auf
  1.2.3.4 Port 8080 an 192.168.1.1 Port 80 geleitet wird), kannst Du
  diese Regel in die OUTPUT-Kette (fuer lokal ausgehende Pakete)
  einfuegen:



      # Linux 2.4
      iptables -A OUTPUT -t nat -p tcp -d 1.2.3.4 --dport 8080 \
      -j DNAT --to 192.168.1.1:80



  5. Kontrollieren, worauf man NAT anwendet

  Du musst NAT-Regeln erstellen, die dem Kernel sagen, was für
  Verbindungen er ändern soll, und wie er sie ändern soll. Um das zu
  tun, setzen wir das vielseitige iptables Tool ein und sagen ihm durch
  das Angeben der '-t nat' Option, dass es die NAT-Tabelle ändern soll.


  Die Tabelle der NAT-Regeln enthält drei Listen, die 'Ketten' genannt
  werden: Alle Regeln werden der Reihe nach untersucht, bis eine davon
  zutrifft. Die drei Ketten heißen PREROUTING (für Destination NAT, da
  die Pakete hereinkommen), POSTROUTING (für Source NAT, da die Pakete
  ausgehen) und OUTPUT (für Destination NAT von lokal generierten
  Paketen).


  Wenn ich irgendein künstlerisches Talent hätte, würde dieses
  Diagramm es ganz gut zeigen:



               _____                                     _____
              /     \                                   /      \
              PREROUTING -->[Routing ]----------------->POSTROUTING----->
              \D-NAT/     [Entscheidung]                \S-NAT/
                            |                            ^
                            |                          __|__
                            |                         /      \
                            |                        | OUTPUT|
                            |                         \D-NAT/
                            |                            ^
                            |                            |
                            -------->Lokaler Prozess------


  Wenn ein Paket durchgeht, schauen wir an jedem der obigen Punkte nach,
  zu was für einer Verbindung es gehört. Wenn es eine neue Verbindung
  ist, sehen wir in der entsprechenden Kette der NAT-Tabelle nach, was
  zu tun ist. Die Antwort, die wir erhalten, wird auf alle weiteren
  Pakete dieser Verbindung angewendet.


  5.1. Einfache Auswahl mit iptables




                                           -8-
Name:         Kolja Engelmann                                              Berlin, 24.02.2010
Matr. Nr. :   708383                                                           Seite 9 von 17




  iptables benötigt eine Reihe von Standardoptionen, die weiter unten
  aufgelistet werden. Die Optionen mit einem doppelten Gedankenstrich
  können abgekürzt werden, solange iptables sie danach noch von den
  anderen Optionen unterscheiden kann. Wenn Dein Kernel iptables als
  Modul unterstützt, wirst Du das 'iptables.o' Modul zuerst laden
  müssen: 'insmod iptables.o'.


  Die wichtigste Option ist hier die, mit der man die Tabelle auswaehlen
  kann, '-t'. Für alle NAT Operationen wirst Du '-t nat' verwenden
  wollen, um in die NAT-Tabelle zu schreiben. Die zweitwichtigste Option
  ist das `-A', mit dem man eine neue Regel an das Ende einer Kette
  anhängen kann (z.B. '-A POSTROUTING'), oder '-I', um eine Regel am
  Anfang einer Kette einzufügen (z.B. '-I PREROUTING').


  Du kannst die Quelle ('-s' oder '--source') und das Ziel ('-d' oder
  ('--destination') eines Pakets bestimmen, auf das Du NAT anwenden
  willst. Diesen Angaben kann eine einzelne IP-Adresse (z.B.
  192.168.1.1), ein Name (z.B. www.gnumonks.org) oder ein
  Netzwerkadresse (z.B. 192.168.1.0/24 oder 192.168.1.0/255.255.255.0)
  folgen.


  Du kannst die Schnittstelle bestimmen, an der Pakete eingehen ('-i'
  oder '--in-interface') oder ausgehen ('-o' oder '--out-interface'),
  aber welche von beiden hängt davon ab, in welche Kette Du diese Regel
  einfügst: Bei der PREROUTING-Kette kannst Du nur die eingehende
  Schnittstelle wählen, und bei der POSTROUTING-Schnittstelle (OUTPUT)
  nur die ausgehende. Wenn Du die falsche wählst, wird iptables Dir
  eine Fehlermeldung geben.


  5.2. Genauere Auswahl der betreffenden Pakete

  Ich habe weiter oben gesagt, dass Du eine Quell- und eine Zieladresse
  bestimmen kannst. Wenn Du die Quelladresse weglässt, wird jegliche
  Adresse zutreffend sein. Wenn Du die Zieladresse weglässt, wird
  jegliche Zieladresse zutreffend sein.


  Du kannst auch ein bestimmtes Protokoll ('-p' oder '--protocol')
  angeben, so wie TCP oder UDP; nur auf Pakete dieses Typs wird die
  Regel zutreffen. Der Hauptgrund hierfür besteht darin, dass das
  Bestimmen eines Protokolls Extra-Optionen erlaubt: insbesondere die
  '--source-port' und die `--destination-port' Optionen (abgekürzt als
  '-sport' und '-dport').


  Diese Optionen erlauben Dir, zu bestimmen, dass eine Regel nur auf
  Pakete mit einem bestimmten Quell- oder Zielport zutrifft. Dies ist
  nützlich für umgeleitete Web-Anfragen (TCP-Port 80 und 8080) und
  lässt andere Pakete außer Acht.


  Diese Optionen müssen der '-p' Option folgen (welche den Nebeneffekt
  hat, dass die Erweiterungen für die shared libraries für das
  entsprechende Protokoll geladen werden). Du kannst Portnummern verwenden



                                           -9-
Name:         Kolja Engelmann                                              Berlin, 24.02.2010
Matr. Nr. :   708383                                                         Seite 10 von 17




  oder Namen aus der /etc/services Datei.


  All die verschiedenen Eigenschaften, nach denen Du Pakete auswählen
  kannst, werden in schmerzhaften Einzelheiten detailliert in der Man-
  Page beschrieben (man iptables).


  6. Wie die Pakete veraendert Werden sollen

  Jetzt wissen wir also, wie wir die Pakete, die wir veraendern wollen,
  auswaehlen koennen. Um unsere Regel zu vervollstaendigen, muessen wir
  dem Kernel sagen, was genau er mit dem Paket tun soll.


  6.1. Source NAT

  Du moechtest Source NAT machen; veraendere die Quelladresse von
  Paketen zu etwas anderem. Dies wird in der POSTROUTING-Kette gemacht,
  kurz bevor das Paket schliesslich geschickt wird; dies ist ein
  wichtiges Detail, da es bedeutet, dass alles andere auf dem
  Linuxrechner selbst (Routing, Paketfilter) das unveraenderte Paket
  sehen wird. Es bedeutet auch, dass die '-o' (ausgehende Schnittstelle)
  Option verwendet werden kann.


  Source NAT wird durch '-j SNAT' bestimmt und die '--to-source' Option
  bestimmt eine IP-Adresse, eine Reihe von IP-Adressen, und einen
  optionalen Port oder eine Reihe von Ports (nur fuer UDP und TCP
  Protokolle).



      ## Quelladresse auf 1.2.3.4 aendern
      # iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4

      ## Quelladresse auf 1.2.3.4, 1.2.3.5, oder 1.2.3.5 aendern
      # iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4-1.2.3.6

      ## Quelladresse zu 1.2.3.4, Ports 1 - 1023, aendern
      # iptables -t nat -A POSTROUTING -p tcp -o eth0 -j SNAT --to \
      # 1.2.3.4:1-1023



  6.1.1. Masquerading

  Es gibt einen Spezialfall von Source NAT, der Masquerading genannt
  wird: es sollte nur fuer dynamisch zugeordnete IP-Adressen verwendet
  werden wie bei normalen Waehlverbindungen (Benutze bei statischen IP-
  Adressen SNAT weiter oben).


  Beim Masquerading musst Du die Quelladresse nicht explizit angeben: es
  wird die Quelladresse der Schnittstelle nehmen, an der das Paket
  ausgeht. Wichtiger ist, dass, wenn der Link unterbrochen wird, die
  Verbindungen (die jetzt sowieso verloren sind) vergessen werden, was
  weniger Stoerungen bedeutet, wenn die Verbindung mit einer neuen IP-



                                            - 10 -
Name:         Kolja Engelmann                                             Berlin, 24.02.2010
Matr. Nr. :   708383                                                        Seite 11 von 17




  Adresse wieder aufgebaut wird.



  ## Maskiere alles, was an ppp0 ausgeht
  # iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE



  6.2. Destination NAT

  Dies wird in der PREROUTING-Kette erledigt, wenn das Paket gerade
  eingegangen ist; das bedeutet, dass alles andere auf dem Linuxrechner
  selbst (Routing, Paketfilter) das Paket zum 'wirklichen' Ziel gehen
  sehen wird. Es bedeutet auch, dass die '-i' Option (eingehende
  Schnittstelle) verwendet werden kann.


  Um das Ziel von lokal generierten Paketen zu aendern, kann auch die
  OUTPUT-Kette benutzt werden, das ist aber eher ungewoehnlich.


  Destination NAT wird durch '-j DNAT' bestimmt und die '--to-
  destination' Option bestimmt eine IP-Adresse, eine Reihe von IP-
  Adressen, und einen optionalen Port oder eine Reihe von Ports (nur
  fuer UDP und TCP Protokolle).



      ## Zieladresse zu 5.6.7.8 aendern
      # iptables -t nat -A PREROUTING -i eth1 -j DNAT --to 5.6.7.8

      ## Zieladresse zu 5.6.7.8, 5.6.7.9 oder 5.6.7.10 aendern
      # iptables -t nat -A PREROUTING -i eth1 -j DNAT --to 5.6.7.8-5.6.7.10

      ## Aendern der Zieladresse von Webtraffic auf 5.6.7.8 Port 8080
      # iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth1 \
       -j DNAT --to 5.6.7.8:8080

      ## Lokale Pakete fuer 1.2.3.4 an das Loopback umleiten
      # iptables -t nat -A OUTPUT -d 1.2.3.4 -j DNAT --to 127.0.0.1



  6.2.1. Umadressierung (Redirection)

  Es gibt einen speziellen Fall von Destination NAT, der Redirection
  genannt wird: Es ist eine einfache Bequemlichkeit, die genau das
  gleiche tut wie NAT auf der eingehenden Schnittstelle.



      ## Eingehenden Webtraffic an Port 80 an unseren (transparenten) Squid-
      # Proxy weiterleiten
      # iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 \
      -j REDIRECT --to-port 3128




                                           - 11 -
Name:         Kolja Engelmann                                             Berlin, 24.02.2010
Matr. Nr. :   708383                                                        Seite 12 von 17




  6.3. Mappings genauer betrachtet

  Es ist gibt ein paar subtile Einzelheiten bei NAT, um die sich die
  meisten Leute nie werden kuemmern muessen. Fuer die Neugierigen sind
  sie hier dokumentiert.
  6.3.1. Auswahl von mehrere Adressen in einer Reihe

  Wenn eine Reihe von IP-Adressen gegeben ist, wir diejenige
  ausgewaehlt, die im Moment am wenigsten fuer IP-Verbindungen, von
  denen die Maschine weiss, benutzt wird. Dies macht primitives 'load-
  balancing' moeglich.


  6.3.2. Ein Null NAT Mapping erstellen

  Du kannst das '-j ACCEPT' Ziel verwenden, um eine Verbindung
  zuzulassen, ohne dass irgendein NAT stattfindet.


  6.3.3. Standard NAT-Verhalten

  Gewoehnlich veraendert man eine Verbindung so wenig wie moeglich,
  entsprechend den Vorgaben einer durch den Benutzer gegebenen Regel.
  Das bedeutet, dass wir Ports nicht 're-mappen' werden, solange wir es
  nicht unbedingt tun muessen.


  6.3.4. Implizites Quellport-Mappen

  Sogar, wenn fuer eine Verbindung kein NAT benoetigt wird, kann
  Quellport- veraenderung stillschweigend auftreten, wenn eine andere
  Verbindung ueber die neue gemappt wurde. Stell Dir den Fall von
  Masquerading vor, der recht gewoehnlich ist:


  1. Eine Webverbindung von einem Rechner 192.168.1.1 Port 1024 ist zu
    www.netscape.com Port 80 aufgebaut.

  2. Dies wird von einem Masquerading-Rechner maskiert, um 1.2.3.4 als
    Quelle zu verwenden.

  3. Der Masqerading-Rechner versucht, von 1.2.3.4 (die Adresse seiner
    externen Schnittstelle) Port 1024, eine Webverbindung zu
    www.netscape.com aufzubauen.

  4. Damit die Verbindung sich nicht ueberschneidet, wird der NAT-Code
    die Quelle der zweiten Verbindung auf 1025 aendern.


  Wenn dieses implizite Quell-Mapping auftaucht, werden Ports in drei
  Klassen aufgeteilt:

  o Ports unter 512.

  o Ports zwischen 512 und 1023.

  o Ports ab 1024.



                                          - 12 -
Name:         Kolja Engelmann                                              Berlin, 24.02.2010
Matr. Nr. :   708383                                                         Seite 13 von 17




  Ports werden niemals implizit in eine andere Klasse gemappt.


  6.3.5. Was passiert, wenn NAT versagt

  Wenn es keine Moeglichkeit gibt, eine Verbindung einheitlich zu mappen
  wie es der Benutzer verlangt, so wird sie verworfen werden. Dies
  trifft auch auf Pakete zu, die nicht als Teil einer Verbindung
  klassifiziert werden konnten, weil sie beschaedigt sind, oder der
  Rechner nicht genug Speicher hat, etc.



  6.3.6. Mehrere Mappings, Overlaps und Clashes

  Du kannst NAT-Regeln haben, die Pakete in denselben Bereich mappen;
  der NAT-Code ist clever genung, um Zusammenstoesse zu vermeiden. Es
  ist also okay, zwei Regeln zu haben, die die Quelladressen 192.168.1.1
  und 192.168.1.2 jeweils auf 1.2.3.4 mappen.


  Ausserdem kannst Du ueber wirklich verwendete IP-Adressen mappen,
  solange diese Adressen auch durch den Mapping-Rechner muessen. Wenn Du
  also ein zugewiesenes Netzwerk (1.2.3.0/24) hast, aber auch ein
  internes Netzwerk, das dieselben Adressen benutzt, und eins, das
  private Internet Adressen (192.168.1.0/24) verwendet, kannst Du die
  192.168.1.0/24-er Adressen auf das 1.2.3.0/24-er Netzwerk mappen, ohne
  Dir Sorgen um Zusammenstoesse machen zu muessen:



      # iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth1 \
      -j SNAT --to 1.2.3.0/24



  Dieselbe Logik kann auf Adressen angewandt werden, die der NAT-Rechner
  selbst benutzt: So funktioniert Masquerading (indem die Adressen der
  Schnittstellen von maskierten Paketen mit den 'wirklichen' Paketen,
  die durch den Rechner gehen, geteilt werden).


  Ausserdem kannst die dieselben Pakete auf viele verschiedene Ziele
  mappen, und sie werden aufgeteilt werden. Du koenntest zum Beispiel,
  wenn Du nichts ueber 1.2.3.5 mappen willst, folgendes tun:



      # iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth1 \
      -j SNAT --to 1.2.3.0-1.2.3.4 --to 1.2.3.6-1.2.3.254



  6.3.7. Das Ziel von lokal-generierten Verbindungen veraendern

  Wenn das Ziel eines lokal-generierten Pakets geaendert wird (ich meine
  durch die OUTPUT-Kette) und das bewirkt, dass das Paket durch eine



                                          - 13 -
Name:         Kolja Engelmann                                              Berlin, 24.02.2010
Matr. Nr. :   708383                                                         Seite 14 von 17




  andere Schnittstelle muss, wird die Quelladresse auch zu der Adresse
  der Schnittstelle geaendert. Wenn Du zum Beispiel das Ziel eines
  Loopback-Pakets auf eth0 aenderst, wird die Quelle auch von 127.0.0.1
  zur Adresse von eth0 geaendert werden; im Gegensatz zu anderen Source-
  Mappings geschieht das im selben Augenblick. Natuerlich wird beides
  wieder umgekehrt, wenn Antwortpakete eintreffen.


  7. Spezielle Protokolle

  Manche Protokolle werden nicht gern geNATted. Fuer jedes dieser
  Protokolle muessen zwei Erweiterungen geschrieben werden; eine fuer
  das Connection-Tracking des Protokolls, und eine fuer das eigentliche
  NAT.


  In der netfilter-Distibution gibt es zur Zeit Module fuer FTP:
  ip_conntrack_ftp.o und ip_nat_ftp.o. Wenn Du diese Module mit insmod
  in den Kernel laedst (oder sie permanent hineinkompilierst), sollte
  NAT auf FTP-Verbindungen funktionieren. Wenn Du das nicht tust, kannst
  Du nur passives FTP verwenden, und sogar das koennte nicht
  zuverlaessig funktionieren, wenn Du mehr als einfaches Source-NAT
  machst.


  8. Einsprueche gegen NAT

 Wenn Du NAT auf einer Verbindung machst, muessen alle Pakete in beide
 Richtungen (in und aus dem Netzwerk) durch den NAT-Rechner, sonst wird
 es nicht zuverlaessig funktionieren. Im Besonderen heisst das, dass
 der connection tracking Code Fragmente wieder zusammensetzt, was
 bedeutet, dass Deine Verbindung nicht nur unzuverlaessig sein wird,
 sondern koennten Pakete sogar ueberhaupt nicht durchkommen, da
 Fragmente zurueckgehalten werden.
Quelle: http://www.netfilter.org/documentation/HOWTO/de/NAT-HOWTO.txt

Um aus einem lokalen Netzwerk mit mehreren Rechnern über einen zentralen Router
oder ein Gateway auf das Internet zuzugreifen, ist es nötig, die unterschiedlichen
internen IP-Adressen in eine öffentliche IP-Adresse umzuwandeln.
Der Router muss hierzu alle IP-Adressen des internen Netzes kennen und über den
Provider eine öffentliche IP-Adresse beziehen. Mit Hilfe einer Tabelle werden die internen
IP-Adressen auf die öffentliche gemappt/maskiert (Maskieren = Masquerading). Da die
Anforderung von Seiten sowie der Datentransport über den Router läuft, kann dieser für
eingehende Daten den Zielrechner bestimmen und die IP auf die lokale IP-Adresse des
Rechners über die Tabelle zurückwandeln.
Eine besondere Form des Masqueradings ist NAT (= Network Address Translation). Hier
werden die IP-Adresse nicht n:1 (von mehreren internen auf eine externe IP-Adresse)
abgebildet sondern n:m.
Das Ziel der NAT besteht zum einen darin, die interne Host-Adresse zu verbergen, indem
die IP auf eine öffentliche gemappt wird. Des Weiteren ist eine Kontrolle der eingehenden
Daten von Extern nach Intern möglich. Hierzu werden zwar nach außen alle Datenpakete
durchgelassen (Forward-NAT), nach intern allerdings nur mit expliziter Freigabe.
Dadurch, dass die Verbindung nur über den Router läuft, können Ziel- und Quellangaben
der Adressen und Ports überwacht werden.

NAT benötigt eine Verbindungsüberwachung, was bedeutet, daß sich bei einer NAT die
jeweilige Verbindungszugehörigkeit gemerkt werden muss.
Diese ist vor allem bei folgendem Szenario wichtig:


                                          - 14 -
Name:         Kolja Engelmann                                             Berlin, 24.02.2010
Matr. Nr. :   708383                                                        Seite 15 von 17




Vorausgesetzt es existiert folgende Situation: Zwei FTP-Clients hinter einer source NAT
beziehen unterschiedliche Dateien vom gleichen FTP-Server. Um garantieren zu können,
dass der Download an den jeweils richtigen FTP-Client geht, muss sich die nach außen
gesendete Adress-Port-Kombination gemerkt werden, sowie zu welchem Client sie
gehört.
Ebenso wäre es möglich, dass mehrere Clients von „load-balance“-FTP-Servern hinter
einer „Destination NAT“ Dateien anfordern. Auch hier muss sich gemerkt werden, welcher
Client mit welchem Server verbunden war.

Aufgabe 3
a) iptables -A INPUT --protocol udp --dport 53 -i eth0 -j ACCEPT
b) iptables -A INPUT --protocol tcp -i eth1 --syn -j ACCEPT

# Da ich nicht weiß, ob eine fixe IP Adresse oder eine dynamische IP
# für die externe Anbindung gegeben ist, gebe ich für beide
# Möglichkeiten in dieser Reihenfolge die entsprechende Regel an.

c) iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4
   iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

Aufgabe 4
Unterschiede zwischen SSL und TLS
Die Unterschiede zwischen SSL und TSL sind eigentlich nicht gravierend, da TLS eine
Weiterentwicklung von SSL ist. Dies wird schon bei der Betrachtung der Versionsnummer
deutlich. TLS arbeitet mit dem gleichen Record Protokoll wie SSL. So zeigt das Feld Major
Version im TSL Header eine 3 und Minor Version eine 1. TSL 1.0 wird also als SSL
Version 3.1 angezeigt.

Bei der Erstellung des MAC weicht SSL etwas von der Definition des HMAC ab. Bei TSL
entscheid man sich auf den Standard HMAC zurückzugreifen, da man auf Grund der
ähnlichen Strukturen der beiden MACs eine Kompatibilität rasch realisieren kann.

Im Gegensatz zu SSL, ist bei TLS Version 1.0 die Erzeugung von Pseudozufallszahlen
definiert. Dieses iterative verfahren kann beliebig oft angewendet werden, um eine
bestimmte Menge an Zufallsdaten zu generieren. Ein Startwert dient zusammen mit dem
geheimen Schlüssel als Input für den HMAC. An das als A(1) bezeichnete Ergebnis wird
der Startwert angehängt und diese Daten dienen nochmals zusammen mit dem
geheimen Schlüssel als Input für den HMAC. Das Ergebnis ist der erste Block an
Zufallszahlen, der je nach verwendeter Hashfunktion 128bit (MD5) oder 160bit(SHA-1)
groß ist. Wird ein weiterer Block Daten benötigt, so dient A(1) statt des Startwerts als
Input für den HMAC.




                                          - 15 -
Name:             Kolja Engelmann                                                                               Berlin, 24.02.2010
Matr. Nr. :       708383                                                                                          Seite 16 von 17




                        Startwert




      Schlüssel          HMAC

                                                      A(1)



                           II       Startwert




       Schlüssel         HMAC             Schlüssel              HMAC

                                                                                                A(2)



                                                                    II        Startwert




                                           Schlüssel             HMAC              Schlüssel           HMAC
                                                                                                              ...




                                                                                                        II          Startwert




                                                                                    Schlüssel          HMAC




                                                                                                                          ...

                                                       Größe des Hashwertes




Die folgenden Unterschiede in den Alert Meldungen stammen von der Webseite
http://www.repges.net/SSL/UNTERS_1/unters_1.HTM von Markus Repges:

Die Alert Meldungen von SSL Version 3.0 sind bis auf die no_certificate Meldung alle
in TLS Version 1.0 definiert. Darüber hinaus gibt es bei TLS noch einige zusätzliche
Meldungen, welcher in der folgenden Liste von
Stets die Bewertung fatal haben dabei:
decryption_failed (21): Der Chiffretext ließ sich nicht entschlüsseln, da z.B. die
                              Blocklänge nicht korrekt ist.
record_overflow (22):         Ein Record Paket wurde empfangen, dessen Größe
                              verschlüsselt 214 + 2048 Byte oder entschlüsselt 214 +
                              1024 Byte überschreitet.
unknown_ca (48):              Ein gültiges Zertifikat wurde abgelehnt, weil die Certification
                              Authority CA nicht lokalisiert werden konnte oder nicht als
                              vertrauenswürdig eingestuft wurde.
access_denied (49):           Der Sender dieser Meldung hat den Verbindungsaufbau nach
                              Erhalt des Zertifikats der Gegenseite abgebrochen.
decode_error (50):            Eine Nachricht konnte nicht ausgewertet werden, weil ein
                              Parameter außerhalb des erlaubten Bereichs liegt oder die
                              Länge der Nachricht nicht korrekt ist.
export_restriction (60): Beim Verbindungsaufbau wurde eine Verletzung der
                              Exportbestimmungen bezüglich der erlaubten
                              Schlüssellängen festgestellt.
protocol_version (70): Die vom Client angegebene Protokollversion von SSL / TLS
                              ist zwar bekannt, wird aber nicht unterstützt.
insufficient_security (71): Diese Meldung ersetzt die Meldung handshake_failure,
                              wenn der Server stärkere Verschlüsselung fordert, als der
                              Client unterstützt.




                                                                 - 16 -
Name:         Kolja Engelmann                                                Berlin, 24.02.2010
Matr. Nr. :   708383                                                           Seite 17 von 17




internal_error (80):            Ein interner Fehler, der keinen Bezug zur Gegenseite oder
                                zur Korrektheit des Protokolls hat, macht eine weitere
                                Verbindung unmöglich.

Des Weiteren existieren bei TLS Version 1.0 drei zusätzliche Meldungen, die im Normalfall
der Einstufung warning unterliegen. Dies sind:
decrypt_error (51):         Der Verbindungsaufbau schlug fehl, da eine Signatur nicht
                            verifiziert werden konnte, der ausgetauschte Schlüssel nicht
                            entschlüsselt werden konnte oder die Meldung finished nicht
                            bestätigt wurde.
user_canceled (90):         Der Verbindungsaufbau wurde vom Benutzer abgebrochen.
no_renegotiation (100): Diese Nachricht folgt auf ein hello_request des Servers oder
                            ein client_hello des Clients, wenn der Absender der Meldung
                            nicht in der Lage ist, eine neue Verhandlung durchzuführen.

Die folgenden Informationen zu Unterschieden zwischen SSL und TLS stammen ebenfalls
von der Webseite http://www.repges.net/SSL/UNTERS_1/unters_1.HTM von Markus
Repges.

        Auch die Zertifikate des Clients werden anders eingeteilt. Im Gegensatz zu SSL
         Version 3.0 werden bei TLS 1.0 keine gesonderten Zertifikatstypen beim
         ephemeral Diffie-Hellman Schlüsselaustausch definiert. Die Verfahren SKIPJACK
         und KEA werden bei TLS nicht unterstützt, weswegen es auch kein KEA-Zertifikat
         gibt.
        Während bei der Berechnung des Hashwertes bei TSL 1.0 für die Nachricht
         certificate_verify nur die Handshake Nachrichten als Input genutzt werden,
         werden bei SSL Version 3.0 zusätzlich auch die Paddingwerte und der geheime
         Schlüssel in den Hashwert einbezogen.
        Auch bei der Nachricht finished ist die Berechnung des MAC unterschiedlich zu SSL
         Version 3.0. Im Falle von TLS 1.0 dienen der geheime Schlüssel, die
         Kennzeichnung, ob die Nachricht vom Client oder vom Server stammt, und die
         Hashwerte der Handshake Nachrichten nach MD5 und SHA-1 als Input für den
         Pseudozufallszahlengenerator.
        Der Pseudozufallszahlengenerator spielt auch bei der Gewinnung des geheimen
         Schlüssels aus dem sogenannten Pre-Master Secret eine wichtige Rolle. Nutzt SSL
         Version 3.0 die Hashverfahren MD5 und SHA-1, um den geheimen Schlüssel zu
         ermitteln, so geschieht dies bei TLS Version 1.0 wiederum durch den
         Pseudozufallszahlengenerator. Als Input dienen hier das Pre-Master Secret, der
         Schriftzug „master secret“ und die Zufallswerte, die Client und Server in ihren
         Hello Meldungen geschickt haben.
        Schließlich unterscheidet sich auch das Padding bei TLS Version 1.0 vom Padding
         bei SSL Version 3.0. Bei SSL Version 3.0 wird genau die Menge an Bits
         angehängt, die der Verschlüsselungsalgorithmus benötigt, um alle Datenblöcke
         verarbeiten zu können. Bei TLS Version 1.0 hingegen, ist die Paddinglänge
         variabel und kann den Minimalwert um Vielfache der gewünschten Blocklänge bis
         zu einem Wert von 255 Byte übersteigen. Dies soll einen Angreifer zusätzlich
         verwirren, da er sich bei einer gegebenen Klartextlänge verschiedenen
         Möglichkeiten des Paddings gegenüber sieht.




                                              - 17 -

								
To top