2017-01-15 3 views
0

Ich habe einen Hauptserver, der den gesamten eingehenden Verkehr zu https://www.example.com dient. Der Hauptserver weist dem Client einen sekundären Server zu, um eine dauerhafte sichere WebSocket-Verbindung herzustellen.Wie werden Ad-hoc-Server, die TLS erfordern, normalerweise implementiert?

Diese sekundären Server können ad-hoc gestartet und gestoppt werden (abhängig davon, wie überfüllt die vorhandenen sekundären Server sind), und sie erhalten beim Start eine neue öffentliche IP-Adresse (möglicherweise mit AWS oder Linode-ähnlich) Cloud-Hosting-Dienste). Beim Start authentifiziert sich der sekundäre Server beim Hauptserver und teilt dem Hauptserver seine öffentliche IP-Adresse mit (so dass der Hauptserver eingehende Clients informieren kann).

Um eine sichere WebSocket (wss: //) Verbindung zu verwenden, muss ich ein Zertifikat für diesen Server erhalten, was wahrscheinlich bedeutet, dass ich einen Subdomain-Namen für jeden sekundären Server benötige. Aber Domain-Namen brauchen eine Weile, um über das Internet zu verbreiten, so dass ich nicht in der Lage bin, den Server sofort zu starten und zu verwenden.

Es sei denn, ich bekomme ein Zertifikat nur mit der IP-Adresse (was bedeutet, dass meine sekundären Server keinen Domain-Namen haben). Dies scheint nicht sehr sicher zu sein, da Cloud-Hosting-Dienste beim Herunterfahren des Servers keine feste IP-Adresse behalten.

Für meine Zertifizierungsstelle verwende ich Let's Encrypt, weil ich ein Online-Spiel betreibe, in dem die Daten über die WebSocket-Verbindung nicht wirklich empfindlich sind.

Diese ganze Sache scheint zu kompliziert, um der richtige Weg zu sein, um TLS auf meinen Servern einzurichten.

Wie soll das richtig gemacht werden? Gibt es eine Möglichkeit, eine sekundäre Serverinstanz einfach zu starten und TLS automatisch einzurichten? Oder sollte ich einfach alles vergessen und nicht TLS für die sekundären Server verwenden?

Antwort

1

Der erste Name "Propagation" ist nicht real, oder vielmehr, es ist eine Legende, die nur lose auf die Fakten über DNS-Caching basiert. Wenn Sie es ernst meinen mit Servern, die Server hochfahren und sie in Echtzeit zerstören, werden Sie irgendwann lernen müssen (oder jemanden einstellen müssen, der das weiß). Wenn Sie die Idee haben, dass "Propagierung" Stunden oder sogar Tage dauert, wird das von billigem Webhosting sein, das nicht daran interessiert ist, besseren Service anzubieten, weil es Zweifel hat, dass Sie den Unterschied kennen.

Der einfachste Weg, dies zu tun, wenn dies ein großer Dienst mit vielen Servern wird und wird abgerissen werden, ist ein Wildcard-Zertifikat zu kaufen, das heißt, dass * .example.com und funktioniert für jeden Server mit dem Namen anything.example.com (keine zusätzlichen Punkte, beachten Sie, dass es wegen des extra Punktes nicht für something_domain.example.com funktioniert). Let's Encrypt bietet keine Platzhalter, aber sie sind nicht besonders teuer, wenn Sie nur einen brauchen, um Ihren gesamten Service zu betreiben.

Auf der anderen Seite, wenn Sie Dinge auf die billige tun, verwenden Sie Let's Encrypt DNS-01-Prüfmethode, damit Sie ein Zertifikat für eine Reihe von Server-Namen ausstellen, bevor Sie wissen, was ihre Adressen sein werden. Vielleicht verwenden Sie diese Validierung, um eine Zertifikatliste server01.example.com, server02.example.com usw. bis zu server40.example.com zu erhalten. Sie können dieses Zertifikat (und den dazugehörigen privaten Schlüssel) jetzt für alle Maschinen mit verwenden irgendwelche dieser Namen, die hochgespielt werden. Diese Art, Dinge zu tun, ist nicht in sicherheitstechnischer Hinsicht ideal, aber du sagst, dass dir das nicht so wichtig ist.

Die Verwendung der DNS-01-Methode bedeutet, dass die Server beim Ausstellen des Zertifikats nicht funktionieren müssen, sondern nur die Kontrolle über ihre DNS-Einträge. Sie müssen die ungefähre Anzahl der Server, die Sie vielleicht im Voraus benötigen, herausfinden, aber ehrlich gesagt, wenn Sie ein Spiel bauen nicht sicher, ob es fünf Spieler oder fünf Millionen Spieler haben wird, sind die Chancen Ihre schlimmsten Probleme werden nicht mit TLS sein.

+0

Nach dem Lesen Ihrer Antwort und der Erkenntnis, dass stackoverflow.com TLS (abgesehen von der Anmeldeseite) nicht verwendet, denke ich, dass ich TLS nicht verwenden werde, bis ich vielleicht ein Account-System brauche. Vielen Dank! – Bernard

Verwandte Themen