Re: FreeBSD-basierter Firewall

From: Harold Gutch <logix(at)foobar.franken.de>
Date: Thu, 17 Jan 2013 01:28:36 +0100

On Thu, Jan 17, 2013 at 01:02:03AM +0100, Bernhard(at)gtkx.de wrote:
> Am 17.01.2013 um 00:22 schrieb Harold Gutch <logix(at)foobar.franken.de>:
> > On Thu, Jan 17, 2013 at 12:00:32AM +0100, Bernhard(at)gtkx.de wrote:
> >> das ssl "aufzubrechen" ist mit sicherheit eine recht fragwürdige methode und ich denke in den meisten staaten nicht legal, da es einem "einbruch" gleich kommt.
> >>
> >> für was wurde denn das ssl erfunden?
> >>
> >> um ganau dies zu verhindern!
> >
> > Quatsch. Es wurde erfunden um eine sichere Kommunikation zwischen
> > Server und Client zu ermöglichen und falls dies nicht möglich ist,
> > sollte der Client davon erfahren. Das ist hier der Fall, du bekommst
> > eine Fehlermeldung weil das Zertifikat ungültig ist. Wenn nicht, dann
> > traut dein Client dem Zertifikat des Proxys (bzw. der DPI-Maschine),
> > z.B. weil der Admin das Zertifikat da installiert hat - oder
> > alternativ, weil der User einfach auf "Ja, mir egal was die
> > Fehlermeldung soll, ich will weitermachen" geklickt hat. Im ersten
> > Fall hast du einen Rechner auf dem ein anderer Benutzer so und so
> > genug Rechte hat alles mitzulesen. Im zweiten Fall hast du einen
> > Benutzer, bei dem SSL eh hinfällig ist, weil er auch bei
> > MITM-Angriffen einfach auf "OK" klicken wird
>
> da hast du freilich recht, es geht aber um die "heimliche" also dem anwender verborgene manipulation.

Ja, die geht aber eben nicht mit purer SSL-Interception. Dafür muss
man dem Client zumindest die Root-Zertifikate mit denen der Proxy die
SSL-abgegriffenen Verbindungen neu signiert beibringen. Wenn wir davon
ausgehen, dass wir beiden Endpunkten trauen, aber *nicht* der Mitte,
dann geht das nicht (ohne Fehlermeldung). Wenn wir nicht beiden
Endpunkten trauen, dann ist eh Hopfen und Malz verloren.

SSL-Interception *rein* in der Mitte, ohne jegliche Manipulation an
den Endpunkten wird dir *immer* [ das ist kein mathematisches "immer",
sondern ein "realistisches immer" ] Fehlermeldungen geben, zumindest
im korrekten Einsatz (CA arbeitet korrekt, der Verifikationscode auf
dem Client ist korrent etc.).

Gruß,
  Harold

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Thu 17 Jan 2013 - 01:28:42 CET

search this site