Re: warum PnP Dienst über Netzwerk?

On Sun, 21 Aug 2005 15:45:59 +0200 Daniel Melanchthon [MSFT] wrote:

> Denis Jedig schrieb:
>
>> Es wiederholt sich
>> ja lediglich die Geschichte von RPC over HTTPS, wo ziemlich eindeutig auf
>> Druck des Marketings eine technisch minderwertige, spezialisierte
>> Zwischenlösung, die "just good enough" ist, einer generischen Tunnellösung
>> vorgezogen wurde.
>
> Ich glaube, das verwechselst Du etwas. Ich empfinde RPC over HTTPS nicht
> als "minderwertig".

Das habe ich auch nicht behauptet. Allerdings tu ich es ;-) Es ist keine
Lösung des Problems[1], sondern ein Workaround für einen extrem speziellen
Anwendungsfall.

> Auch hier vergleichen wir wieder Äpfel mit Birnen. Die
> Möglichkeit, einzelne Protokolle direkt mit SSL zu sichern und/oder mit
> HTTP connect proxytauglich zu machen, ist eine weitere Möglichkeit *neben*
> VPNs.

Ja. Allerdings keine besonders elegante.

> Bei VPNs hast Du immer das Problem, dass Du nicht sicherstellen
> kannst, dass nur der Client in das Netz kommt. Was hindert den Client
> daran, weitere Netzwerkverbindungen lokal einzurichten und damit den
> Zugriff an der zentralen Firewall direkt in das LAN zu ermöglichen?

Lese ich es richtig, wenn ich hinter "Firewall" noch ein "vorbei" einsetze?

> Oder andersrum: Viele Firmen sperren ausgehende VPNs, weil sie nicht
> wissen, welche Daten dann dadurch getunnelt werden. Da sind einzeln
> absicherbare Protokolle wie RPC over HTTPS, die keine Netz-Netz-Kopplung
> (mit oder ohne Filtermöglichkeit) herstellen, einfacher zu erlauben.

Ich glaube, ich verstehe das Argument nicht.
Siehst du die Gefahr darin, dass der Client als Plattform dient, um über
das VPN auf Daten zuzugreifen, die geheim sind?
Oder siehst du die Gefahr darin, dass der Client in einem Netz X, welcher
tunnelt, geheime Daten aus dem Netz X herausblasen kann?

In keinem Fall will sich mir ein Sicherheitsvorteil der HTTPS-Kapselung
einzelner Protokolle gegenüber einer generischen IP-Kapselung erschließen.

Ersteres greift nicht, weil durch die Bereitstellung eines kompletten
IP-Transportes du natürlich auch zwei virtuelle, aber voll funktionsfähige
IP-Interfaces hast, deren einkommenden Traffic du zum einen nach Lust und
Laune filtern kannst und zum anderen auch nach Bedarf (nicht) routen. Der
VPN-Client hat also nur noch Zugriff auf das, was er haben darf - genau wie
mit Tunneln am Application Layer.

Und letzteres greift nicht, weil so unzählig viele Methoden gibt, um aus
einem Netz unbemerkt vertrauliche Daten herauszuschicken, dass einem
schwindlig werden kann, wenn man sie sich anschaut. Da gehört ein
VPN-Tunnel noch zu den Auffälligeren und HTTPS-Kapselung ist kein Stück
weniger fähig oder verdächtig, unrechtmäßig Entwendetem als Transport zu
dienen.

Der Unterschied der beiden Methoden liegt nicht in der Sicherheit, sondern
in der Technik - Tunnel am Application Layer können schlicht weniger und
sind immer die Lösung für nur ein spezielles Protokoll. Tunnel am Network
Layer hingegen sind wesentlich flexibler und besser kontrollierbar.

> Nun wurden die Firewalls noch dichter konfiguriert und nur noch HTTP, HTTPS
> , SMTP, etc., also well known ports erlaubt. Nächster Schritt auf
> Anwendungsseite war das Umstellen der Applikationen auf diese well known
> ports.

Was, wie du selber angemerkt, endlos weiter gehen kann und deshalb grober
Unfug ist.

> Aktueller Stand ist, dass die Securityseite HTTPS aufbricht, um auf
> Anwendungsebene zu filtern...

Und das eigentlich schon beinahe ein Verbrechen.

[1] Ich definiere das Problem als sicheren Zugriff auf die Daten eines
Firmennetzes.
--
Denis Jedig
syneticon networks GbR http://syneticon.net/service/
.

Relevant Pages

  • Re: UI, Lisp, CLOS, MVC, design
    ... this cookie thing? ... hand, when I type in some Web2.0 thingie and add a https before it, I ... It's not like a C based client in Gtk+ can be written in a sloppy ... Yeah, good thing I don't have to worry about distributing upgrades etc. ...
    (comp.lang.lisp)
  • Re: UI, Lisp, CLOS, MVC, design
    ... this cookie thing? ... hand, when I type in some Web2.0 thingie and add a https before it, I ... It's not like a C based client in Gtk+ can be written in a sloppy ... Yeah, good thing I don't have to worry about distributing upgrades etc. ...
    (comp.lang.lisp)
  • Re: What is the easiest way to query a remote XML file on someone elses Linux box using secure commu
    ... I'd recommend HTTPS then. ... The encryption strength depends on the browser. ... client does not support 128. ... Either SSH or something. ...
    (microsoft.public.dotnet.general)
  • Re: HTTPS durch ISA
    ... > Client die Verbindung aufbaust? ... jetzt NAT oder Route - vielleicht erinnerst Du dich. ... Jetzt geht halt nur kein HTTPS mehr. ... andere geht sauber durch den ISA, ...
    (microsoft.public.de.german.isaserver)
  • Re: How effective is a router as a firewall?
    ... SMTP Client ... POP3 Client (Port 110 Receive Mail) ... DNS Client (Port 53 Dynamic Name Server) ... Neither HTTP nor HTTPS can be limited addresswise. ...
    (comp.security.firewalls)