VPN vs https

[toppas27]

hallo

in unserer Firma soll über eine Javeapplikationich Daten ausgetauscht werden. nun stehe vor dem Problem welche Sicherheitsmechanismen benutze werden sollen.

Ein VPN oder https.

Über beide Protokolle wäre das Programm lauffähig.

es handelt sich hierbei für die Firma um hochsensible Daten.

Hat jemand dazu eine Meinung....wäre schön diese mal zu lesen.

viele Grüße toppas27

[lordy]

Ich würde ganz klar HTTPS einsetzen.

Die Komplexität ist geringer, HTTP ist klar definiert im Gegensatz zu vielen, teils properitären, VPN-Protokollen.

Was die Verschlüsselung angeht kann man zu einem Großteil die gleichen Algorithmen (AES, Blowfish, 3DES, etc.) sowohl in HTTPS als auch in einem VPN verwenden.

[toppas27]

danke für die antwort

als VPN würde OpenVPN zur verfügung stehen.

wie ist es mit der sichtbarkeit und man in the middle attacken bei https ud vpn innerhalb des internet?

viele grüße toppas

[lordy]

Wenn du OpenVPN, ähnlich wie HTTPS, Zertifikat-basiert betreibst ist da kein Unterschied. Dann kannst du MITM-Angriffe anhand des Zertifikats erkennen. (Immer vorrausgesetzt, das deine CA, die die Zertifikate ausstellt, sicher ist)

[Schandfleck]

Wenn du OpenVPN, ähnlich wie HTTPS, Zertifikat-basiert betreibst ist da kein Unterschied. Dann kannst du MITM-Angriffe anhand des Zertifikats erkennen. (Immer vorrausgesetzt, das deine CA, die die Zertifikate ausstellt, sicher ist)

Wobei sich dann der Einsatz von Client-Zertifikaten anbietet, damit beide Seiten in der Lage sind Main-in-the-Middle-Angriffe zuerkennen.

[M.A.Knapp]

Für allgemeinen Datenaustausch tuts auch SSL (z.b. TLS 1.0)

HTTPS ist einfach nur HTTP über SSL

[toppas27]

Danke für die antwort.

es handelt sich bei unserem datenaustausch um hochsensible firmendaten, wie z.B. Projektpläne, gutachten, patentbearbeitung, personaldaten ect.

ich für meinen teil würde eher zu vpn tendieren.

daher meine fragestellung hier um auch mal von außenstehenden eine meinung einzuholen.

[lupo49]

Ob du jetzt die Daten AES/3DES/... verschlüsselt über HTTPS überträgst oder über VPN ist doch letztendlich egal?

Bei VPN hättest du den Vorteil, dass du ggf. die Kommunikation weiterer Anwendungen über den Tunnel absichern kannst. Aber VPN ist meistens site-to-site aufgebaut, was den Nachteil hätte, dass die Daten erstmal unverschlüsselt im internen LAN übertragen werden. Wenn deine Anwendung über https kommuniziert wäre es site-to-end(?)/end-to-end(?) unter der Voraussetung, dass die Applikation lokal auf den Clients läuft.

[lordy]

Wie gesagt, VPN hat mehr Komplexität und ich bin immer für "keep it simple".

Wenn es irgendwann Verbindungsprobleme gibt, kannst du bei HTTPS einfach über einen Telnet-Client bzw. OpenSSL die Verbindung testen und siehst sofort, geht oder geht nicht. Wenn du stattdessen ein VPN benutzt wirst du erst mal in den Logs des VPN oder der Firewall schauen müssen.

Da die Auswahl an Algorithmen quasi identisch ist und diese ja die eigentliche Sicherheit schaffen, votiere ich nochmal klar für HTTPS.

lupo49 hat natürlich Recht, VPN ist häufig Site-to-Site, HTTPS ist immer End-to-End, was auch nochmal ein Vorteil für HTTPS darstellen kann.

[VaNaTiC]

Ich würde auch definitiv https auswählen. Aus genau den Gründen, wie hier schon geschrieben wurde ist VPN dafür die weniger gute Wahl. Da der Tunnel für Dich "transparent" ist, gehst Du - wenn auch auf kurzem Weg - unverschlüsselt und zwar von Deiner Anwendung bis zum Tunneleingang und vom Tunnelausgang bis zur Partneranwendung. Wenn genau zwischen diesen beiden Punkten - was ehrlich gesagt sowieso am wahrscheinlichsten wäre - ein MITM-Angriff stattfindet hast Du verloren. Wenn Du stattdessen allerdings sowieso zwischen Endpunkt-Endpunkt z.Bsp. auf https setzt, muss schon jemand direkt in den Prozess Deiner Anwendung, wenn er die Zertifikate nicht umgehen kann.

Meiner Meinung nach ist https als Beispiel hier keineswegs die pragmatische, sondern die einzig logische Alternative, wenn Du Dich vor zu erwartenden MITM-Angriffen halbwegs absichern willst.

[M.A.Knapp]

Für konkrete Point-to-Point Kommunikation würde ich SSL/TLS empfehlen

Obs darüber dann HTTP oder was anderes läuft, ist dann eine andere Geschichte.

Beruflich arbeite ich an einer Anwendung, die Patientendaten an andere Punkte (immer point-to-point) überträgt. Da verwende ich SSL/TLS als Grundlage. Über diese sichere Verbindung läuft dann HTTP (=HTTPS) für RID und XDS (SOAP) und Datenaustausch mittels der DICOM und HL7 Protokolle und auch Syslog (RFC5424).

[Mr Unix]

Ich versteh gar nicht warum hier so viele mit "HTTPS" antworten... :confused: Dabei sollte die Antwort doch klar sein: Beides.

Ich wuerde IPsec im Transportmodus nehmen um Langohren fernzuhalten und anschliessend die Daten ueber HTTPS austauschen um die Authentizitaet der Gegenstelle zu ueberpruefen.

Wenn das wirklich so sensible Daten sind wie du sagst, dann solltest du dich fragen, ob das Internet wirklich der richtige Medium ist, um die Daten auszutauschen. Wenn du dir nicht sicher bist, kannst du vielleicht zusaetzlich nochmal vor dem Austausch ein asynchrones Verschluesselungsverfahren à la GPG drueberlaufen lassen...?

Absolute Sicherheit gibt es nicht!

[lordy]

Mr.Unix: mehr Komplexität geht dann aber nicht mehr, oder ?

Doppelte Verschlüsselung != Doppelte Sicherheit

[Mr Unix]

Mr.Unix: mehr Komplexität geht dann aber nicht mehr, oder ?

Doppelte Verschlüsselung != Doppelte Sicherheit

Wieso Komplexitaet? Also ich weiss nicht was auf dem Zielsystem laeuft, aber IPsec ist zusammen mit Racoon unter FreeBSD in zehn Minuten eingerichtet.

Und hier geht es nicht um die doppelte Verschluesselung. Es geht darum Zertifikate sauber auszutauschen. Das mit GPG war nur so ein Gedanke. Man weiss ja nie ob ein Dienst mal nicht funktioniert und wie das Worst-Case-Szenario dann aussieht. Nicht, dass die Daten am Ende doch noch Plain gesendet werden...

[toppas27]

Danke für Deine Antwort

wir haben uns im letzten meeting für eben diese vorgehensweise entschieden.

erst einen VPN und dann https mit RSA/AES Verschlüsselung und zusätzlicher Signatur durch Karte...

und ja es sind nun mal richtig wertvolle daten die aus dem gesamten bundesgebiet über unsere Server laufen wie sollte man es denn sonst machen ohne enorm Geschwindigkeit einzubüßen???

[RipperFox]

Wieso Komplexitaet? Also ich weiss nicht was auf dem Zielsystem laeuft, aber IPsec ist zusammen mit Racoon unter FreeBSD in zehn Minuten eingerichtet.

So ist das wenn man sich zu weit von der Fragestellung fortbewegt. OPs Programm ist in Java geschrieben - also zumindest vom Programmieraspekt Plattformunabhängig gestaltbar.

Normalerweise ist auch das Deployment von Java-Applikationen einfach zu realisieren.

Kommt nun aber IPsec hinzu wirds sehr schnell sehr, sehr kompliziert. (FreeBSD in allen Ehren, aber was ist z.B. mit einer von der hauseigenen IT gemanagten Windows-Büchse beim Kunden, auf der schon "Fremdsoftware für IPsec" läuft? Auch müssen dann z.B. Firewalls und Router mitspielen.

Die im Bankbereich als ausreichend angesehene Variante (!) über HTTPS (siehe HBCI/FinTS) dürfte da wesentlich weniger Probleme bereiten und kommt z.B. auch mit nem Proxy klar. Das ganze noch mit gegenseitigen Zertifikaten und meinetwegen Chipkarten sollte bei weitem reichen.

Aber ich muss das ganze ja eh nich beim Kunden installieren

Grüße Ripper