localhost im Backend https vs. http

[grindelaner]

Hallo,

ich habe eine allgemeine Frage. Wir haben ein Webserver, welcher nach außen natürlich über https abgesichert ist.
ABER im Backend kommunizieren die Services über REST über die localhost-Adresse miteinander...

Da frage ich mich wie sinnvoll dort eine Verschlüsselung via BasicAuth oder TLS wäre...

Da localhost eigentlich nur durch das Betriebssystem aufgelöst wird und die Kommunikation nicht den Rechner verlässt kann ja eigentlich auch kein Angriff in die localhost-Kommunikation stattfinden...

Da eine Verschlüsselung auch Performanceeinbußen mit sich bringt frage ich mich ernsthaft, ob eine REST-Verbindung via https Sinn macht...

Ich würde mich über eure Meinungen und einen Erfahrungsaustausch freuen.

 

[mihe7]

Ich sag mal so: wenn ein Unbefugter auf dem Server die Rechte hat, einen Sniffer zu starten, dürfte die Kommunikation zwischen REST-Services Dein geringstes Problem sein.

Es mag Fälle geben, wo Verschlüsselung innerhalb des Geräts sinnvoll ist (-> wenn das Gerät außer Haus geht) aber ich habe noch nirgends gehört, dass jemand zur Absicherung des Servers lokal verschlüsselt.

 

[Dukel]

Wenn du irgendwann skalieren musst und Dienste auslagern landen diese plötzlich auf anderen Maschinen (ggf. auch übers Internet erreichbar) und da wäre es sinnvoll, wenn diese Dienste dann schon TLS sprechen und nicht noch angepasst werden müssen.

 

[grindelaner]

Ja ihr bestätigt meine Meinung

Laufen die Dienste auf einem Server, macht eine Verschlüsselung kein Sinn...
Laufen die Dienste auf verteilten Servern, oder gar über das Internet macht eine Verschlüsselung SEHR VIEL Sinn.

 

[kneitzel]

Also ich sehe ähnlich wie @mihe7 das wirklich als Services. Und wo die Services laufen sollte egal sein, daher würde ich immer die Verschlüsselung fahren. Das macht dann die Verlagerung relativ einfach.

Ansonsten ist es aus meiner Sicht eine Frage des Risikomanagements. Das ist keine Design Entscheidung vom Entwickler oder von dem, der die Installation aufsetzt!
Wer kann das Risiko bewerten und dann den Umgang mit dem Risiko festlegen? So es da keine klare Aussage von Verantwortlichen gibt, die klar festgehalten sind, würde ich das Risiko komplett vermeiden: https konfigurieren, dann ist das Risiko einer Fehlkonfiguration nicht mehr gegeben. (Und meine Erfahrung ist auch, dass Audits oft auf Trigger reagieren: "Ihr habt http im Einsatz? Dann bitte Passierschein A38 ausfüllen!")
Aber das sind halt auch alles Risiken: Risiko ein Passierschein A38 ausfüllen zu müssen, Risiko, dass die Performance des Systems nicht ausreicht, ....

 

[Thallius]

Ich sehe das natürlich mal wieder anders.
Wenn das Design gut ist, dann sollte es nur eine Stelle im Code geben wo der http request gemacht wird. Dort sollte im Moment auch die url, also das Localhost, stehen. Solange es localhost bleibt ist eine verschlüsselung nur pure Ressourcen Verschwendung.
Besteht irgendwann die Notwendigkeit Teile auszulagern, dann muss dieser Code geändert werden und dann ist es kein Aufwand aus dem http request einen https request zu machen.

Ich finde vorher schon zu verschlüsseln ist quatsch

Claus

 

[Dukel]

Alles was im Fall der Fälle geändert werden muss kann vergessen werden.
Der Performance / Ressourcenbedarf sollte vernachlässigbar gering sein.

 

[mrBrown]

ich würde das gar nicht die Services selbst, sondern die Infrastruktur abhandeln lassen, je nachdem was man nutzt zB verschlüsselte Overlay-Networks von Docker Swarm/Kubernetes/oä oder Service-Discovery, nur Services nur mit entsprechendem Protokoll veröffentlicht.

Alles was im Fall der Fälle geändert werden muss kann vergessen werden.

Kann man verhindern, indem die Server von außen einfach generell nur https zulassen - wenn's vergessen wurde, schlägt dann einfach die Verbindung fehl.

 

[Thallius]

Kann man verhindern, indem die Server von außen einfach generell nur https zulassen - wenn's vergessen wurde, schlägt dann einfach die Verbindung fehl.

Was eigentlich heute standard sein sollte.

 

[grindelaner]

Moin,

Ich will diesen Thread mal wieder aufleben lassen...
@Thallius: Ich gebe dir Recht, localhost über https laufen zu lassen sehe ich auch als pure Ressourcen Verschwendung...

Jedoch... oh wunder... https klingt toll, also soll jetzt ALLES in https laufen, auch wenn an dieser Stelle nur zwei Contexte innerhalb einer
Tomcat-Instanz hier mit einander kommunizieren...

Also machen wir es nun richtig und stellen die (eine) Stelle auf https um...
Da wir jetzt natürlich ALLES richtig machen wollen, ist und der CN total wichtig... Also müssten wir jetzt unsere Keystores um ein weiteres Zertifikat erweitern... Also brauchen wir ein Zertifikat mit CN=localhost...

Ist das soweit richtig...?

Jetzt darf ich mich wieder in das Thema eingraben

Vielleicht hat jemand schon einmal Erfahrungen mit https und localhost auf einem Tomcat... Die Kommunikation soll via REST stattfinden...