Du befindest dich hier: FSI Informatik » Prüfungsfragen und Altklausuren » Hauptstudiumsprüfungen » Lehrstuhl 1 » Allgemein   (Übersicht)

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.

Link zu der Vergleichsansicht

Nächste Überarbeitung		Vorherige Überarbeitung
pruefungen:hauptstudium:ls1:appitsec_20150316_1 [18.03.2015 09:47] – angelegt Diveflopruefungen:hauptstudium:ls1:appitsec_20150316_1 [25.03.2015 10:52] (aktuell) – Diveflo
Zeile 16: Zeile 16:
   * Liste werden über 9 fixe Server verteilt: Directory Authority    * Liste werden über 9 fixe Server verteilt: Directory Authority 
   * Authentifikation der Relays über Public Key   * Authentifikation der Relays über Public Key
-  * Public Key, aber nur für Auth, "echte" Verschlüsselung per symmetrischen Session key der per Diffie-Hellman Handshake ausgemacht wird -> perfect forward security+  * Public Key, aber nur für Auth, "echte" Verschlüsselung per symmetrischen Session key der per Diffie-Hellman Handshake ausgemacht wird -> perfect forward secrecy
   * Bridges erklärt: China, Iran etc blocken normale Onion Router -> nicht öffentliche Liste von Entry-Nodes für diese Nutzer   * Bridges erklärt: China, Iran etc blocken normale Onion Router -> nicht öffentliche Liste von Entry-Nodes für diese Nutzer
   * Vertraulichkeit nur komplett wenn z.B. https verwendet wird, da Exit-Node alles sonst unverschlüsselt sieht   * Vertraulichkeit nur komplett wenn z.B. https verwendet wird, da Exit-Node alles sonst unverschlüsselt sieht
-  * Hidden Services erklärt: Circuits von beiden Seiten. Rondevouz Points bzw. descriptors liegen auf normalen relays (HSDir Flag wird bei >25h Uptime vergeben)+  * Hidden Services erklärt: Circuits von beiden Seiten. Rendevouz Points bzw. descriptors liegen auf normalen relays (HSDir Flag wird bei >25h Uptime vergeben)
  
 F: Die Directory Authority hat ja die Public Keys um so zu authentifizieren. Gibt's sowas ähnliches im "normalen" Web auch? F: Die Directory Authority hat ja die Public Keys um so zu authentifizieren. Gibt's sowas ähnliches im "normalen" Web auch?
Zeile 36: Zeile 36:
 F: Was kann man dagegen machen? F: Was kann man dagegen machen?
  
-A: Prepered statements, also genau definieren was für ein Input kommen soll. Andere Möglichkeit wäre diese SQL Funktion: real_string, die ein escape char vor "gefährliche" inputs setzt.+A: Prepared statements, also genau definieren was für ein Input kommen soll. Andere Möglichkeit wäre diese SQL Funktion: real_string, die ein escape char vor "gefährliche" inputs setzt.
  
 F: Wäre das Whitelisting? F: Wäre das Whitelisting?
  
-A: Preperred statements wäre sowas wie whitelisting, real_string mehr Blacklisting+A: Prepared statements wäre sowas wie whitelisting, real_string mehr Blacklisting
  
 F: Wann benutzt man denn White und wann Blacklisting? Oder ist eins immer besser? F: Wann benutzt man denn White und wann Blacklisting? Oder ist eins immer besser?
Zeile 47: Zeile 47:
  
 Dann war die Zeit schon rum. Wurde kurze Zeit später wieder reingebeten und bin sehr zufrieden mit dem Ergebnis. Dann war die Zeit schon rum. Wurde kurze Zeit später wieder reingebeten und bin sehr zufrieden mit dem Ergebnis.
- 
-