Sichere HTTP-Kommunikation für Komponenten kommerzieller Produkte

Question

Angenommen, ich möchte ein kommerzielles Produkt versenden, das zwei in Java geschriebene Komponenten enthält, die über ein REST-API in einem lokalen Netzwerk miteinander kommunizieren. Es könnte ein Musikmanager, eine Kontaktdatenbank, ein Kochbuch sein - wichtig ist, dass dies ein vernünftiges und extrem wahrscheinliches Szenario ist.

Beachten Sie, dass es sich um zwei Komponenten handelt, die über ein lokales Netzwerk miteinander kommunizieren - nicht über die Kommunikation mit meinem Server.

Wie also mache ich die Kommunikation sicher?

Ich weiß, wenn ich einen HTTP-Server für die Welt einrichten, kann ich (sogar billig) ein SSL-Zertifikat kaufen. Ich habe es getan. Aber ich kann dem Benutzer nicht sagen, dass er ein Zertifikat kaufen soll - sie werden keine Ahnung haben, wovon ich rede, und ich würde niemals herausfinden, wie ich es installieren soll.

Also was mache ich? Jedem mein selbstsigniertes Zertifikat schicken und eine sehr schlechte Sache wie disable certificate validation in Java machen? Schrecklich, ich weiß. Aber zumindest werden die Informationen nicht im Klartext über die Linie gehen.

Wer hat bessere Lösungen?

Answer 1

Suchen Sie nach OAuth 2.0, um Ihre Dienste zu sichern, und Sie sollten nur Token für Ihre Clients anstelle von SSL bereitstellen. Facebook, Google usw. verwendet es.

https://en.wikipedia.org/wiki/OAuth

Answer 2

Ihre linked answer stellt eine andere Lösung: Statt Zertifikatsvalidierung für selbstsignierte Zertifikate zu deaktivieren, ‚Exportieren Sie das Zertifikat (...) und es in Ihrer JVM-Vertrauens importieren‘.

Nur zum ersten Mal, wenn ein unbekanntes Zertifikat gefunden wird, fragen Sie nach Benutzerbestätigung.

Answer 3

20. September '15aktualisiert in den Kommentaren

angehoben, um die Punkte zu klären

Um zu verstehen, wie dies getan werden kann, lassen Sie uns ein mögliches Einsatzszenario einer solchen Anwendung untersuchen. Angenommen, die fragliche Anwendung besteht aus zwei Komponenten - dem Client-Teil und dem Server-Teil, die auf verschiedenen Computern in einem lokalen Netzwerk installiert werden sollen. Wir möchten, dass unser Server nur sichere Verbindungen akzeptiert, daher wird das lokale Netzwerk als feindlich betrachtet.

1. Installieren Sie den Server Teil. Zum Zeitpunkt der Installation erstellen Sie programmgesteuert ein selbstsigniertes Zertifikat mit dem Hostnamen eines Zielcomputers. Wenn es keinen DNS-Eintrag für den Computer gibt (wie myserver.mycorp.com), verwenden Sie seine IP-Adresse - es muss statisch sein, da wir den Client-Teil darauf verweisen müssen. Sie können Bouncy Castle API verwenden, um ein Zertifikat in Code zu erstellen.

2. Installieren Sie das Client-Teil auf einem anderen Computer und kopieren Sie das generierte Zertifikat in den Installationsordner. Wenn Sie dies manuell tun, wird effektiv Vertrauensstellung zwischen dem Server und dem Client hergestellt. Der Versuch, dies automatisch über eine unverschlüsselte Verbindung über ein feindliches Netzwerk zu tun, würde den Zweck vereiteln.

3. Da Sie die Kommunikation strikt zwischen Ihren eigenen Anwendungsteilen sichern, haben Sie die volle Kontrolle darüber, welche Zertifikate die betreffende Anwendung anvertraut.Auf dem Client erstellen einen Schlüsselspeicher, und fügen Sie das generierte Zertifikat, um es:

   FileInputStream fis = new FileInputStream(yourCertificateFile); 
   CertificateFactory cf = CertificateFactory.getInstance("X.509"); 
   X509Certificate c = (X509Certificate)cf.generateCertificate(fis); 
   
   KeyStore ks = KeyStore.getInstance(KeyStore.getDefaultType()); 
   ks.load(null, aRandomKeystorePasswordCharArray); 
   ks.setCertificateEntry(aUniqueNameForYourCertificate, c); 
   
   FileOutputStream fos = new FileOutputStream(aRandomKeystoreFileName); 
   ks.store(fos, aRandomKeystorePasswordCharArray); 
   fos.close(); 
   

   die JVM sagen, dass Ihre Anwendung nur Zertifikate von seinem eigenen Schlüsselspeicher vertrauen wird.

   // replace backslashes '\' with slashes '/' in aRandomKeystoreFileName on Windows 
   System.setProperty("javax.net.ssl.trustStore", aRandomKeystoreFileName); 
   System.setProperty("javax.net.ssl.trustStorePassword", aRandomKeystorePassword); 
   

Answer 4

Werfen Sie einen Blick auf Vergleich zwischen Facebook Connect, OAuth und OpenID bei TheNextWeb

OpenID: OpenID als dritte Partei dient, die überprüfen können, wer Sie sind

OAuth: Eine sicherere und sicherere Möglichkeit für Leute, Ihnen Zugang zu geben

Facebook Connect: Mit Facebook Connect sehen wir Elemente von OpenID und OAuth. Facebook Connect kann bestätigen, dass Sie der sind, der Sie für die Person halten, und Sie können dann auf Ihre Daten zugreifen, sobald Sie die entsprechende Erlaubnis dazu erteilt haben.

Zusammenfassung:

OpenID und OAuth denken, dass sie eine kollektive richtige Antwort haben, aber Facebook denkt klar, dass es seine eigene hat. Wir müssen sehen, wie es sich in Zukunft gestaltet.