Client Server Kommunikation verschlüsseln

brainless

Mitglied
hallo Java-forum :)

Ich zerbreche mir gerade über folgendes Problem den Kopf:
Es geht um die Benutzeranmeldung von Clients an einen Server. Dazu wird momentan beim Server eine Funktion aufgerufen, welche den Login-Name und Passwort übergeben bekommt und der Server fragt dies dann bei der Datenbank ab. Das Problem dabei ist, dass momentan die Kommunikation zwischen Client und Server unverschlüsselt ist und so das Passwort im Klartext übertragen wird. :oops:

Als eine erste Lösung wird das Passwort symmetrisch mit AES verschlüsselt, wobei der dazu verwendete Key (salt) fest im Code vom Server und Client verdrahtet ist. Nun ist es aber nicht gewünscht, dass der Key im Code steht.

Als erstes habe ich an ein Hybrides-Verfahren aus RSA und AES gedacht:
  1. der Client erfragt beim Server den PublicKey
  2. Server erstellt Private- und PublicKey und sendet den PublicKey an Client
  3. Client erzeugt zufälligen SecretKey (AES) und verschlüsselt diesen mit dem PublicKey des Servers
  4. Client sendet SecretKey an Server
  5. Server entschlüsselt den SecretKey mit seinem PrivateKey
  6. --> Client und Server kennen den SecretKey (AES)
  7. --> alte Methode vom ersten Ansatz kann genutzt werden
Eigentlich könnte man für diesen Fall auf ein hybrides Verfahren verzichten und das Passwort gleich mit dem PrivateKey verschlüsseln. :eek: Ich dachte mir aber man könnte die Symmetrische Verschlüsselung dann später noch für andere Aufrufe benutzen. :cool:

So... das Problem was ich bei diesem Ansatz sehe ist: Wie authentifiziert sich der Server? :confused: (um sicher zu stellen, dass wirklich mit dem Server kommuniziert wird und niemand die Passwörter klauen will = Sicherheitslücke?)

Ich habe auch schon an ein Signaturverfahren mittels PKI gedacht. Allerdings ist da, glaube ich, der Aufwand zur Verwaltung der gültigen Signaturen für die Clients und den Server zu hoch. o_O

Das selbe Problem bei SSL-Sockets: dafür müsste man auch die gültigen Signaturen bei Client und Server verwalten. :confused:

Hat jemand vielleicht eine Idee, wie man das Problem der Verschlüsslung/Authentifizierung lösen könnte? ;)
 

Ch4t4r

Aktives Mitglied
Speicher doch einfach den publickey des Servers ab. Nachteil ist hierbei natürlich, dass der Schlüssel nicht einfach geändert werden kann, Vorteil aber, dass nur dein Server die Daten lesen kann. Ob ein solches Konzept sinnvoll ist, ist deine Entscheidung.
Ein Tipp, falls du eine app für z.b Android programmieren willst: aus den usa exportierte Produkte haben teilweise Beschränkungen, was die Verschlüsselung angeht. Allerdings steige ich dort auch nicht komplett durch.
 

brainless

Mitglied
Danke für deine Antwort. :)

Ja man müsste dann halt alle Clients einmalig mit dem PublicKey des Servers versorgen (und dann nur noch, falls dieser geändert wird). Dann müsste man sich halt nur überlegen, wo im Client man den Speichert, um ihn austauschbar zu halten? (Am besten wahrscheinlich einfach als externe Datei, welche eingelesen wird...)
 

cafebabe

Mitglied
Als eine erste Lösung wird das Passwort symmetrisch mit AES verschlüsselt, wobei der dazu verwendete Key (salt) fest im Code vom Server und Client verdrahtet ist. Nun ist es aber nicht gewünscht, dass der Key im Code steht.

Ja, davon würde ich auch abraten, symmetrische Schlüssel gehören nicht hart in den code...

Prinzipell sehe ich hier mehrere Möglichkeiten (alle haben vor/nachteile):
  1. Auth. per Hash:
    Client erfragt Challenge C vom Server
    Client berechnet aus C und Password P [bzw. Hash(Passwort) HP] Response R1 = HMAC(HP , C)
    Server berechnet ebenfalls R2 = HMAC(HP , C)
    R1 bzw R2 ist der sym. Schlüssel für die Verschlüsselung (z.b. mit AES)
    Das ganze kann man beliebig erweitern...

    Vorteil: Sehr einfach implementierbar und schnell
    Nachteil: Wie kommt das Passwort auf den Server/Datenbank ??? , Keine Eigenschaften wie PFS
  2. Dein beschriebens Protokoll, public-key wird im Code des Clients hinterlegt.

    Vorteil: Sehr einfach implementierbar, PFS umsetzbar, etc.
    Nachteil: Wird der Server kompromentiert, lassen sich Clients nicht mehr sicher updaten (evtl. eine 2 pubKey hinterlegen)
  3. SSL / TLS
    Zertifikat kann auch selbst erstellt werden

    Vorteil: Alles was TLS bietet
    Nachteil: Aufwand etwas höher

Was du einsetzen solltest hängt vom Anwendungsfall ab.
 

Tobse

Top Contributor
Ich kann mich cafeable nur anschließen; allerdings ist es immer äußerst Risikoreich, sowas selbst zu implementieren. Du kannst auf SSL zurückgreiffen - von Hartbleed abgesehen ist das die Sicherste Methode. Du kannst die Mechanismen von SSL auch selbst implementieren, nur musst du hierbei weider auf viele kleine Details achten, die dein ganzes System komprommitieren können.

Bei SSL läuft es im grunde so:

1. Server hat ein Zertifikat (= RSA Public Key + Sigantur vom CA)
2. Nach dem TCP Verbindungsaufbau gibt es einen Schlüsselaustausch alá DiffieHellman; dabei ist wichtig, dass der Server (und am besten auch der Client) ihre Parameter ordentlich (= sicheres Padding) signieren.
3. Mit dem über DH ausgetauschten Schlüssel wird dann ein synchroner Cipher genutzt, z.B. AES-128 oder AES-256

Bei der synchronen Verschlüsselung gibt es auch wieder einige Fallstricke: Richtiger Cipher Mode of Operation, sicheres Padding, gute NONCEs.

Über den Kanal, der dann zustande kommt, kannst du dann sicher kommunizieren. Aber auch dann macht es sinn, die Passwortprüfung mit einer Challenge zu machen, wie cafebable beschrieben hat.
 

brainless

Mitglied
Vielen Dank für euer Input. :)

JPrinzipell sehe ich hier mehrere Möglichkeiten (alle haben vor/nachteile):

1. Auth. per Hash:
Client erfragt Challenge C vom Server
Client berechnet aus C und Password P [bzw. Hash(Passwort) HP] Response R1 = HMAC(HP , C)
Server berechnet ebenfalls R2 = HMAC(HP , C)
R1 bzw R2 ist der sym. Schlüssel für die Verschlüsselung (z.b. mit AES)
Das ganze kann man beliebig erweitern...

Vorteil: Sehr einfach implementierbar und schnell
Nachteil: Wie kommt das Passwort auf den Server/Datenbank ??? , Keine Eigenschaften wie PFS
Die Idee mit Challenge-Response finde ich eigentlich super. ;-) Aber leider stehen die Passwörter gehasht in der Datenbank. Und auf Clientseite steht die entsprechende Hash-Funktion nicht zur Verfügung. :-/ Ein anderes gemeinsames Geheimnis müsste man wieder hart in den Clientcode rein - und das wollen wir ja nicht.^^ Dann wahrscheinlich lieber doch lieber mit Public-Key.

2. Dein beschriebens Protokoll, public-key wird im Code des Clients hinterlegt.

Vorteil: Sehr einfach implementierbar, PFS umsetzbar, etc.
Nachteil: Wird der Server kompromentiert, lassen sich Clients nicht mehr sicher updaten (evtl. eine 2 pubKey hinterlegen)
Das Updaten der Clients wäre kein Problem, da diese zusammen mit dem Server ausgeliefert werden, falls die Software geupdatet wird.

3. SSL / TLS
Zertifikat kann auch selbst erstellt werden

Vorteil: Alles was TLS bietet
Nachteil: Aufwand etwas höher
Die Umsetzung wäre mit ein wenig Aufwand verbunden. Schlimmer ist aber, das wohl der Aufwand zur Verwaltung der KeyStores und TrustedStores bei den ganzen Clients zu hoch wäre.

Ich kann mich cafeable nur anschließen; allerdings ist es immer äußerst Risikoreich, sowas selbst zu implementieren. Du kannst auf SSL zurückgreiffen - von Hartbleed abgesehen ist das die Sicherste Methode. Du kannst die Mechanismen von SSL auch selbst implementieren, nur musst du hierbei weider auf viele kleine Details achten, die dein ganzes System komprommitieren können.
Ja SSL/TLS wäre wohl ein sichere und saubere Umsetzung. Leider ist die Verwaltung der Zertifikate mit dem Java keytool sehr aufwendig?

Über den Kanal, der dann zustande kommt, kannst du dann sicher kommunizieren. Aber auch dann macht es sinn, die Passwortprüfung mit einer Challenge zu machen, wie cafebable beschrieben hat.
s.o. die Frage ist, was ich als gemeinsames Geheimnis benutze? Da das Passwort im Server nur gehasht zur Verfügung steht.
 
Zuletzt bearbeitet von einem Moderator:

cafebabe

Mitglied
Die Idee mit Challenge-Response finde ich eigentlich super. ;-) Aber leider stehen die Passwörter gehasht in der Datenbank. Und auf Clientseite steht die entsprechende Hash-Funktion nicht zur Verfügung. :-/ Ein anderes gemeinsames Geheimnis müsste man wieder hart in den Clientcode rein - und das wollen wir ja nicht.^^ Dann wahrscheinlich lieber doch lieber mit Public-Key.

Das ist ja mal ein setup... Der client keine Java SE ?!
Kannst/darfst du uns die Vefahren verraten (Hashverfahren der Passwörter etc.) Vielleicht findet sich eine Möglichkeit
dem Client das beizubringen... ;-)

s.o. die Frage ist, was ich als gemeinsames Geheimnis benutze? Da das Passwort im Server nur gehasht zur Verfügung steht.

Also dass das passwort nur gehasht auf dem Server liegt ist schonmal lobenswert!
Prinziepell wäre es jetzt praktisch wenn der Client das Hashverfahren ebenfalls beherrscht (lässt sich viell. nachrüsten?)

Die publickey-im-code variante hat noch ein paar tücken, z.B muss, falls das Passwort mit dem Public-key des Servers, verschlüsselt wird, die übertragene Nachricht einmalig sein, was ein encoding wie OAEP oder PKCS1v2 erfordert

Mit ein paar mehr infos zu den Verfahren und den Anforderungen lässt sich das evtl. besser beantworten...
 

brainless

Mitglied
Also dass das passwort nur gehasht auf dem Server liegt ist schonmal lobenswert!
Prinziepell wäre es jetzt praktisch wenn der Client das Hashverfahren ebenfalls beherrscht (lässt sich viell. nachrüsten?)
Das müsste ich mal überprüfen...

Die publickey-im-code variante hat noch ein paar tücken, z.B muss, falls das Passwort mit dem Public-key des Servers, verschlüsselt wird, die übertragene Nachricht einmalig sein, was ein encoding wie OAEP oder PKCS1v2 erfordert
Ich würde ein Hybrides Verfahren verwenden: Mit dem Public Key wird nur der Key für die Symmetrische Verschlüsselung ausgehandelt, welcher zufällig vom Client erzeugt wird. Und mit diesem wird dann das Passwort verschlüsselt. Dies sollte die Einmaligkeit gewährleisten.
 

brainless

Mitglied
Als erstes habe ich an ein Hybrides-Verfahren aus RSA und AES gedacht:
  1. der Client erfragt beim Server den PublicKey
  2. Server erstellt Private- und PublicKey und sendet den PublicKey an Client
  3. Client erzeugt zufälligen SecretKey (AES) und verschlüsselt diesen mit dem PublicKey des Servers
  4. Client sendet SecretKey an Server
  5. Server entschlüsselt den SecretKey mit seinem PrivateKey
  6. --> Client und Server kennen den SecretKey (AES)
  7. --> alte Methode vom ersten Ansatz kann genutzt werden
Mir ist aufgefallen, dass dieses Verfahren anfällig für Replay-Attacken ist. Mallory sendet den verschlüsselten SecretKey an den Server und danach das verschlüsselte PW, ohne jeweils den genauen Inhalt zu kennen.
Als Gegenmaßnahme könnte der Server zu Beginn ein "Nonce" erzeugen, welche als Initialisierungsvektor für die AES-Verschlüsselung benutzt wird. So kann Mallory zwar den alten SecretKey dem Server unterschieben, aber das PW wäre falsch verschlüsselt?
 

cafebabe

Mitglied
Mir ist aufgefallen, dass dieses Verfahren anfällig für Replay-Attacken ist. Mallory sendet den verschlüsselten SecretKey an den Server und danach das verschlüsselte PW, ohne jeweils den genauen Inhalt zu kennen.
Als Gegenmaßnahme könnte der Server zu Beginn ein "Nonce" erzeugen, welche als Initialisierungsvektor für die AES-Verschlüsselung benutzt wird. So kann Mallory zwar den alten SecretKey dem Server unterschieben, aber das PW wäre falsch verschlüsselt?

Das kommt darauf an wie man's implementiert...
Meine Empfehlung wäre:

Vorbereitung:

  • Erzeuge private & public key des Servers
    Hinterlege den public key im Code des Clients (public key pinning)

Protokol:

  • Client erzeugt zufälligen geheimen Schlüssel für AES : SK
    Client verschlüsselt SK mit dem public key : EK = Enc_RSA (Pub , SK)
    Client verschlüsselt Passwort mit SK : EP = Enc_AES (SK , Passwort)
    Client sendet EK und EP an den Server
    Server berechnet geheimen AES Schlüssel : SK' = Dec_RSA (Pri , EK)
    Server berechnet Passwort : Passwort = Dec_AES (SK' , EP)
    Server berechnt Hashwert des Passworts : H = Hash (Passwort)
    Server überprüft ob H == DB_Hashwert, wenn ja ist das übertrage passwort richtig, wenn nein, wurde die Kommonikation manipultiert oder das passwort war falsch

Wichtig:
SK darf sich nicht wiederholen -> Sichere Zufallszahlen
Wie wird das Passwort auf die Blocklänge expaniedert? Padding, AES-CTR mit IV aus 0-bytes

Dieses Protokol ist unter folgenden Vorrausetzungen sicher:

  • SK wiederholt sich nicht -> krypt. sichere Zufallszahlen
    Ciphertext der Blockcipher ist von einer Zufallsfolge nicht zu unterscheiden (bei AES erfüllt)
    EK hoch e > n (e ist RSA-exponent , n ist RSA modulus), ansonsten muss z.b das OAEP verwendet werden
 

brainless

Mitglied
  • Client erzeugt zufälligen geheimen Schlüssel für AES : SK
    Client verschlüsselt SK mit dem public key : EK = Enc_RSA (Pub , SK)
    Client verschlüsselt Passwort mit SK : EP = Enc_AES (SK , Passwort)
    Client sendet EK und EP an den Server
    Server berechnet geheimen AES Schlüssel : SK' = Dec_RSA (Pri , EK)
    Server berechnet Passwort : Passwort = Dec_AES (SK' , EP)
    Server berechnt Hashwert des Passworts : H = Hash (Passwort)
    Server überprüft ob H == DB_Hashwert, wenn ja ist das übertrage passwort richtig, wenn nein, wurde die Kommonikation manipultiert oder das passwort war falsch
Genau so hatte ich es mir ja gedacht. Nun ist aber doch folgendes Problem:
  • Client erzeugt zufälligen geheimen Schlüssel für AES: SK
    Client verschlüsselt SK mit dem public key : EK = Enc_RSA (Pub , SK)
    Client verschlüsselt Passwort mit SK : EP = Enc_AES (SK , Passwort)
    Client sendet EK und EP an den Server
    böser Client Mallory fängt EK und EP ab (kennt aber SK und PW nicht, da verschlüsselt)
    beliebige Zeit später:
    Mallory sendet EK und EP an Server

    Server berechnet geheimen AES Schlüssel : SK' = Dec_RSA (Pri , EK)
    Server berechnet Passwort : Passwort = Dec_AES (SK' , EP)
    Server berechnet Hash und überprüft, böser Client Mallory authentifiziert
Obwohl Mallory SK und PW nicht kennt, kann er sich mit dem Mitgeschnitteten EK und EP anmelden (Replay-Attacke). Natürlich ist dann keine weitere Kommunikation möglich, da er SK nicht kennt. Aber das er sich anmelden kann, ist schon eine Lücke. ?

Das mit dem Padding habe ich mir schon notiert. Danke für deine Tipps. :)
 

cafebabe

Mitglied
  • böser Client Mallory fängt EK und EP ab (kennt aber SK und PW nicht, da verschlüsselt)
    beliebige Zeit später:
    Mallory sendet EK und EP an Server

    Server berechnet geheimen AES Schlüssel : SK' = Dec_RSA (Pri , EK)
    Server berechnet Passwort : Passwort = Dec_AES (SK' , EP)
    Server berechnet Hash und überprüft, böser Client Mallory authentifiziert
Obwohl Mallory SK und PW nicht kennt, kann er sich mit dem Mitgeschnitteten EK und EP anmelden (Replay-Attacke). Natürlich ist dann keine weitere Kommunikation möglich, da er SK nicht kennt. Aber das er sich anmelden kann, ist schon eine Lücke. ?

Hab ich doch tatsächlich übersehen! Danke für den Hinweis! Im nachhinein, ist es dann völlig klar... ;-)
Die einfachste und wahrscheinlich sehr effektive Methode wäre das generieren einer Nonce durch den Server , wie du es bereits gesagt hast.
Am besten erzeugt der Server die Nonce gleich zu beginn und der Client verwendet diese zur verschlüsselung des Passworts. Der AES key kann weiterhin zufällig gewählt werden und asymmetrisch verschlüsselt übertragen werden.
 

Tobse

Top Contributor
Seht ihr? Ihr habt es selbst versucht und seit direkt auf eine Lücke gestoßen :) Ich sags nochmal: benutze TLS; und damit meine ich das Protokoll, nicht den ganzen kram drumrum.
Meines Wissens nach kann man die Java-Klassen, welche das SSL Protokoll implementieren, auch mit einem im Client gespeicherten Public-Key nutzen. Solange du ein KeyPair nimmst, was von einem bekannten CA signiert ist, musst du dich auch nicht um die Keystores kümmern.

Hier ein Auszug aus dem Google Android Developer Blog über SSL-Verbindungen ausserhalb von HTTP:
Java:
// Open SSLSocket directly to gmail.com
SocketFactory sf =SSLSocketFactory.getDefault();
SSLSocket socket =(SSLSocket) sf.createSocket("gmail.com",443);
HostnameVerifier hv =HttpsURLConnection.getDefaultHostnameVerifier();
SSLSession s = socket.getSession();

// Verify that the certicate hostname is for mail.google.com
// This is due to lack of SNI support in the current SSLSocket.
if(!hv.verify("mail.google.com", s)){
    throw new SSLHandshakeException("Expected mail.google.com, found "
                                    + s.getPeerPrincipal());
}

// At this point SSLSocket performed certificate verificaiton and
// we have performed hostname verification, so it is safe to proceed.

// ... use socket ...

socket.close();
 

cafebabe

Mitglied
Seht ihr? Ihr habt es selbst versucht und seit direkt auf eine Lücke gestoßen :)

Ja, und dann auch noch auf eine sehr banale...
Fast schon peinlich xD

Ich sags nochmal: benutze TLS; und damit meine ich das Protokoll, nicht den ganzen kram drumrum.

Ist im Allgemeinen auch die beste Wahl, aber auch hier muss man so manches bachten:
z.B ist TLS/SSL keine Option, wenn die Standardimplementierung < JDK-7 verwendet wird -> beherscht kein TLS_1.2
Ist in Unternehmen öfter mal der Fall, das JDK-6 noch im Einsatz ist.

Also ja, TLS ist (richtige version, CA-cert etc. vorrausgesetzt) die 1. Wahl.
Wenn man es aber richtig macht (nicht so wie ich vorher ;-) ), dann ist ein etwas einfacheres Protokoll (cha-resp + encryption) durchaus auch einsetzbar
 
Ähnliche Java Themen
  Titel Forum Antworten Datum
ExceptionOfExpectation Server/Client-Kommunikation Netzwerkprogrammierung 34
I Client/Server Kommunikation bei einem Spiel Netzwerkprogrammierung 4
T Socket Server/Client Kommunikation Netzwerkprogrammierung 8
P MIME-TYPE Erklaerung, Kommunikation zwischen Client und Server Netzwerkprogrammierung 3
J Sichere Kommunikation bei Server Client Netzwerkprogrammierung 3
M allgemeine Frage über Server-Client-Kommunikation Netzwerkprogrammierung 5
L Ratschlag zur Umsetzung einer client-server-Kommunikation Netzwerkprogrammierung 6
R Server zu Client Kommunikation Netzwerkprogrammierung 11
V Socket UDP Server/Client Kommunikation sehr langsam Netzwerkprogrammierung 2
F Socket Server/Client Kommunikation Netzwerkprogrammierung 4
X Problem mit Server-Client-Kommunikation Netzwerkprogrammierung 14
D Server-Client (Web) Kommunikation Netzwerkprogrammierung 9
E Client-Server-Kommunikation Netzwerkprogrammierung 13
C HTTP Studienarbeit Kommunikation via HTTP mit POST zwischen Server und Client Netzwerkprogrammierung 7
G Problem mit Client-Server Kommunikation Netzwerkprogrammierung 4
G unvollständige Daten: Http Client-Server-Kommunikation Netzwerkprogrammierung 2
J client/server kommunikation Netzwerkprogrammierung 3
M Client-Kommunikation ohne Server Netzwerkprogrammierung 7
S Kommunikation Fortran <-> Java auf Client-Server-Archi Netzwerkprogrammierung 2
G JINI über RMI // Client-Server Kommunikation Netzwerkprogrammierung 4
I Performanteste Kommunikationsmethode zwischen Client u. Server Netzwerkprogrammierung 4
L Socket Automatische Zuweisung von Server und Client Rolle Netzwerkprogrammierung 12
M Server-Client-System für Browsergame Netzwerkprogrammierung 5
Yonnig Threads mit Client/Server und GUI (laufend bis button-click) Netzwerkprogrammierung 9
J Client-Server und SOAP Netzwerkprogrammierung 23
L30nS RMI Aufruf einer Client-Methode von einem RMI-Server Netzwerkprogrammierung 3
T String von Client zu Server kommt nicht an Netzwerkprogrammierung 92
D WebSocket Server mit HTML Client und Java Server Netzwerkprogrammierung 5
D Server - Client Informationsaustausch, Möglichkeiten Netzwerkprogrammierung 3
H Socket Chat entwickeln mit Java Server Client Netzwerkprogrammierung 4
X Kann ich einen Client/Server verbindung hinkriegen die mir alle paar Sekunden die aktuellen Daten per Realtime zuschickt ? Netzwerkprogrammierung 9
D Slf4j - Logging - Client-Server Architektur Netzwerkprogrammierung 3
J client server mit nur einem PC Netzwerkprogrammierung 33
M Socket Nachricht von TCP-Client an Server schicken Netzwerkprogrammierung 12
M Socket Verbindung Matlab(Server) Java(Client) Netzwerkprogrammierung 1
R Socket FATAL EXCEPTION MAIN bei Socket based client/server app Netzwerkprogrammierung 2
G Server-Client IO Problem Netzwerkprogrammierung 6
I Socket Das erste Server-Client Programm Netzwerkprogrammierung 16
M Socket Server antwortet dem Client nicht Netzwerkprogrammierung 6
E Objekte versenden, Client-Server Netzwerkprogrammierung 25
C Mini Client-Server-Anwendung funktioniert nicht Netzwerkprogrammierung 8
P Server als Client nutzen Netzwerkprogrammierung 8
D Socket Run Args Client/Server Socket Netzwerkprogrammierung 1
Cromewell Socket Multithreaded Server und Client Netzwerkprogrammierung 1
Y Client/Server/DB communication Netzwerkprogrammierung 3
JavaWolf165 Socket mit .writeUtf etwas vom Client zum Server schicken Netzwerkprogrammierung 13
P RMI Client Server Programm über Internet Netzwerkprogrammierung 2
gamebreiti Socket Server / Client Anwendung Manipulation von Objekten durch Server Netzwerkprogrammierung 9
F Server Client Anwendung mit UDP Netzwerkprogrammierung 2
A RMI Wo treten Exceptions bei RMI Aufrufen auf? Auf Client oder auf Server? Netzwerkprogrammierung 3
A ByteBuffer - Client/Server Netzwerkprogrammierung 9
K C# Server - Android Client Netzwerkprogrammierung 0
T Frage zu Client-Server Applikation Netzwerkprogrammierung 2
H Socket Client/Server Socket Programmieren Netzwerkprogrammierung 1
M Theoretische Frage zu Server - Client Netzwerkprogrammierung 2
P HTTP Server / Client Netzwerkprogrammierung 1
E Thematik Client server Netzwerkprogrammierung 2
D Client/Server per Crossover Lan Kabel Netzwerkprogrammierung 1
S Client Server Connection Netzwerkprogrammierung 4
V erste Client - Server Anwendung, paar Fragen wie Socketverbindung checken usw. Netzwerkprogrammierung 4
S Sichere Server/Client Architektur Netzwerkprogrammierung 1
D Chat Server/mehre Client Netzwerkprogrammierung 9
I Server+Client Netzwerkprogrammierung 3
N Client am Server abmelden Netzwerkprogrammierung 0
F Server/Client Probleme Netzwerkprogrammierung 3
U Socket Instant Messanger (Server Linux, Client Windows) Netzwerkprogrammierung 1
Athena Grundsatzfragen zu Client-Server-Architektur / Matchmaking Netzwerkprogrammierung 1
A Problem beim Senden von Client zu Server Netzwerkprogrammierung 10
F Client Server DB Netzwerkprogrammierung 0
A Verständnisfrage Multi-Threaded Client/Server Netzwerkprogrammierung 5
F Tipps zum Thema Server/Client vie SOAP Netzwerkprogrammierung 0
F Socket Java - Server/Client simple Netzwerkprogrammierung 1
R Zeitliche Syncronisation Server - Client Netzwerkprogrammierung 0
S Server-Client: Image senden Netzwerkprogrammierung 2
C Multithreading Client / Server erklärt Netzwerkprogrammierung 11
P server - client verbindung (anfänger) Netzwerkprogrammierung 8
J Client Server - Serialisierung Netzwerkprogrammierung 8
Luk10 Server / Client: Clients speichern! Netzwerkprogrammierung 6
K Client => Server Netzwerkprogrammierung 2
A ? Home-Network, Server/Client-Einrichtung Netzwerkprogrammierung 4
S Socket Server: ConnectionError vom Client erkennen Netzwerkprogrammierung 31
A Java Server - IOS Client Applikation Netzwerkprogrammierung 20
M RMI RMI Probleme zwischen Client und Server Netzwerkprogrammierung 5
J Erster Server-Client läuft auf lokalem Rechner problemlos. Zwei Rechner über das Internet nicht Netzwerkprogrammierung 8
N Client-Server-Datenbank Netzwerkprogrammierung 13
Kjubert Synchronisieren von Objekten über Client/Server - bester Weg? Netzwerkprogrammierung 7
B Client/Server Connection Problem Netzwerkprogrammierung 2
S Server Client Daten hin und herschicken Netzwerkprogrammierung 2
D TCP Verbindung (Java Client und Visual Basic Server) Netzwerkprogrammierung 12
S Socket Applet Client bekommt keine GLOBALE Verbindung zum Server Netzwerkprogrammierung 25
T Server und Client verbinden nicht Netzwerkprogrammierung 6
D Server Client Verbindung - Unexpected End of File - Invalid HTTP Response Netzwerkprogrammierung 4
das-mo Client/Server sendet nicht Netzwerkprogrammierung 7
Z Socket Server/Client vernünftiger Verbindungsabbruch Netzwerkprogrammierung 4
G Bild über Socket schicken - Client/Server Netzwerkprogrammierung 10
F TCP Server/Client Netzwerkprogrammierung 14
M Problem Client - Server Sockets: .ready() wird nie true! Netzwerkprogrammierung 6
Ollek Socket Sucher passende Server/Client Lösung für meine Anwendung Netzwerkprogrammierung 2
N eine klasse mit server & client Netzwerkprogrammierung 5
D RMI Gui auf client updaten basierend auf den Property Änderung des Models auf dem Server ohne polling Netzwerkprogrammierung 12

Ähnliche Java Themen

Neue Themen


Oben