Nieuws:

We zijn er weer.

Na lange tijd van afwezigheid zijn we er weer  :laugh:
We hebben alle wachtwoorden gereset, je oude wachtwoord werkt niet meer.Je moet via het "wachtwoord vergeten"-linkje je wachtwoord resetten. Je krijgt hiervoor een mailtje op het adres dat je bij ons geregistreerd hebt.

De komende tijd zijn we nog druk bezig om de rest van de site op te bouwen, dus het kan zijn dat sommige onderdelen (tijdelijk) niet werken.

Welkom, Gast. Alsjeblieft inloggen of registreren.
Heb je de activerings-mail niet ontvangen?

Auteur Topic: Java NIO + SSL  (gelezen 1213 keer)

Offline SeySayux

  • Lid
    • SeySayux.net
  • Steunpunt: Nee
Java NIO + SSL
« Gepost op: 2008/06/18, 16:11:21 »
Hallo iedereen,

Ik ben een online MMO-spel in Java aan het programmeren. Ik moet informatie van spelers, met passwoorden en zo, over het netwerk verzenden hiervoor. Uiteraard wil ik deze verbinding beveiligen, maar omdat ik liever niet heb dat er continue over een beveiligde verbinding gespeeld wordt, en ik de gegevens van de spelers en de spelsimulatie apart wil houden, heb ik, onafhankelijk van de spelserver een loginserver gemaakt. Omdat de spelserver en de loginserver moeten communiceren, om zo de spelergegevens te updaten, heb ik een extra listener gemaakt die enkel dient om spelserver en loginserver met elkaar te laten communiceren, en wiens poort dus niet geforward wordt. Hierdoor hoeft een client maar heel eventjes een beveiligde verbinding te maken met de loginserver, waarna die alles overdraagt aan de spelserver die de rest doet.

Nu is het probleem uiteraard die beveiligde verbinding. Ik gebruik een netwerk-api (Java Game Networking, kortweg JGN) die gebaseerd is op NIO (non-blocking I/O). JGN heeft enkel ondersteuning ingebouwd voor Blowfish-encryptie. Dat betekent dat er een sleutel moet zijn. Die sleutel moet zowel in de client als in de server zitten. Momenteel wordt de sleutel opgehaald via https. Maar, zo dacht ik, dan kan toch iedereen gewoon zijn browser op het adres van mijn server zetten en zo de sleutel downloaden, en een man-in-the-middle attack doen op de client? Dat moet dus veiliger kunnen. De sleutel inbouwen lijkt me ook niet zo'n goed idee, het kan namelijk ge-reverse-engineerd of gedecompiled worden.

Dus dacht ik aan SSL. Nu lijkt SSL in Java toch niet zo eenvoudig te zijn als ik dacht. Er is een zeer goede API voor gewone Sockets, maar deze zijn niet non-blocking, oftewel voor iedere verbinding moet er een nieuwe thread gemaakt worden. Voor Channels (NIO variant van sockets) zijn er geen klaargemaakte API's, maar moet er zelf iets ineen gedraaid worden met behulp van SSLEngine. Nu, ik versta niet veel van die NIO-klassen. Die zijn allemaal abstract? Hoe werken ze? Welke klasse moet ik extenden? en hoe moet ik het in JGN inbouwen dan?

Nu, omdat de verbinding toch normaal gezien maximaal 10 seconden duurt (gewoon gebruikersnaam en passwoord verifieren, spelserver verwittigen dat hij een nieuw Player-object moet aanmaken, client toestemming geven te verbinden met de server dmv dit genoemde player-object, client met spelserver verbinden, syncronisatie-loop in client opzetten, verbinding verbreken), zou het toch niet beter zijn om dan even gewone sockets te gebruiken en voor iedere verbinding een thread te maken, die wordt afgesloten na de verbinding?

Weet iemand hier meer van NIO of SSL? Bestaan er libraries voor NIO en SSL te combineren? Zo ja, onder welke licentie (liefst zoeits als BSD)? Of weet iemand een andere manier om dit probleem op te lossen?

Alvast bedankt,

- SeySayux
I use a Unix-based system, that means I'll get laid as often as I have to reboot.
LibSylph
SeySayux.net

Offline SeySayux

  • Lid
    • SeySayux.net
  • Steunpunt: Nee
Java NIO + SSL
« Reactie #1 Gepost op: 2008/06/20, 22:01:18 »
Citaat
Nu, omdat de verbinding toch normaal gezien maximaal 10 seconden duurt (gewoon gebruikersnaam en passwoord verifieren, spelserver verwittigen dat hij een nieuw Player-object moet aanmaken, client toestemming geven te verbinden met de server dmv dit genoemde player-object, client met spelserver verbinden, syncronisatie-loop in client opzetten, verbinding verbreken), zou het toch niet beter zijn om dan even gewone sockets te gebruiken en voor iedere verbinding een thread te maken, die wordt afgesloten na de verbinding?
Omdat niemand me hiermee kon helpen helaas, heb ik voor deze oplossing gekozen.

- SeySayux
I use a Unix-based system, that means I'll get laid as often as I have to reboot.
LibSylph
SeySayux.net