[PHP] Beveiligen van verbinding

[devhouse]

Hallo allemaal,

Ik ben met een projectje bezig in PHP, waarbij er data tussen 2 servers en de browser veilig moet worden overgebracht. Ik heb voor de duidelijkheid maar een schets gemaakt:


De bedoeling is dus dat de browser via een ajax request een commando stuurt naar SERVER A. Dus bijvoorbeeld een post request naar http://site.ext/connect met in de post: edit memo 1 with text: blaat. Server A geeft dit commando duur aan Server B door middel van een post request via curl. Server A krijgt die request bijvoorbeeld de tekst 'OK' terug, en Server A stuurt dit terug via de Ajax Request.

Dit bovenste gebeuren lukt mij zelf wel. Maar nu komt het probleem. De informatie die verzonden kan worden, kan persoonlijk zijn. En mag niet in de verkeerde handen vullen. Dus ook niet in de handen van een hacker die toevallig tussen Server A en B de verbinding zit af te luisteren. Ik heb alleen geen enkel idee hoe ik de data veilig naar Server B kan brengen. Ik heb al gedacht aan versleutelen, maar omdat de eerste paar woorden vaak hetzelfde zijn(zoals in edit memo ? with text: ?) is het al makkelijker om de juiste sleutel te vinden. Mijn vraag is dus of jullie misschien een manier weten, om de data veilig naar server B te brengen. Iemand een idee?

Alvast bedankt!

[Herko_ter_Horst]

Ja, HTTPS gebruiken.

[Grijze Vos]

SSL

[ Voor 12% gewijzigd door Grijze Vos op 19-06-2009 14:17 ]

[devhouse]

en wat nou als Server B geen SSL ondersteund? want iedereen met php ondesteuning moet dit kunnen gebruiken.

[Noork]

tom.keim schreef op vrijdag 19 juni 2009 @ 14:19:
en wat nou als Server B geen SSL ondersteund? want iedereen met php ondesteuning moet dit kunnen gebruiken.

Dan encrypt je toch zelf de inhoud. Volgens mij zijn daar wel kant en klare php oplossingen voor.

[ Voor 8% gewijzigd door Noork op 19-06-2009 14:24 ]

[Icey]

tom.keim schreef op vrijdag 19 juni 2009 @ 14:19:
en wat nou als Server B geen SSL ondersteund? want iedereen met php ondesteuning moet dit kunnen gebruiken.

Ik neem aan dat jij de eigenaar bent van Server B en de gebruikers gerepresenteerd worden als Server A? Een zelfde opzet zoals bijv. een postcodeDB of bijv. een SMS dienst als mollie.

Zorgen dat Server B alleen maar request accepteerd via https:// moet niet zo'n probleem zijn toch? Dan hoef je alleen maar te zorgen dat alle gebruikers cURL gebruiken met https ondersteuning.

[BtM909]

Wil je een veilige verbinding hebben of wil je je data beveiligt over een verbinding sturen (beide hebben randvoorwaarden en die bepalen wat je kan / wilt gebruiken)

[devhouse]

Icey schreef op vrijdag 19 juni 2009 @ 14:25:
[...]


Ik neem aan dat jij de eigenaar bent van Server B en de gebruikers gerepresenteerd worden als Server A? Een zelfde opzet zoals bijv. een postcodeDB of bijv. een SMS dienst als mollie.

Zorgen dat Server B alleen maar request accepteerd via https:// moet niet zo'n probleem zijn toch? Dan hoef je alleen maar te zorgen dat alle gebruikers cURL gebruiken met https ondersteuning.

nee, ik beheer Server B niet. De beheerder hievan kan een bestand op die server zetten, die voor de communicatie dient te zorgen

BtM909 schreef op vrijdag 19 juni 2009 @ 14:26:
Wil je een veilige verbinding hebben of wil je je data beveiligt over een verbinding sturen (beide hebben randvoorwaarden en die bepalen wat je kan / wilt gebruiken)

het liefst natuurlijk een veilige verbinding(dus dat de data door niemand anders gelezen kan worden)

[ Voor 89% gewijzigd door devhouse op 19-06-2009 14:28 ]

[devhouse]

ok, ik heb wat gebrobeerd met mcrypt, en heb nu de volgende code:

PHP:

<?php
$key = '394dHH27';
$input = "Dit is een test voor encryptie!";

$encrypted_data = mcrypt_ecb (MCRYPT_3DES, $key, $input, MCRYPT_ENCRYPT);
echo $encrypted_data.'::';
echo mcrypt_ecb(MCRYPT_3DES, $key, $encrypted_data, MCRYPT_DECRYPT);

?>

als je nu kijkt op http://devhouse.nl/encrypt.php, zie je zo'n rare ? op het einde staan, iemand een idee hoe ik daar af kom?

[Verwijderd]

Dat "rare" vraagteken wat jij ziet staan heeft te maken met een karakter wat niet ondersteund wordt... dit zie je ook als je UTF-8 Encoding gebruikt voor een webpagina en vervolgens direct een copyright teken wilt laten zien (dus een copyright teken in je html pagina zelf), je moet dan UTF-8 code zelf gebruiken, in dat geval dus: #169;

Het is dus waarschijnlijk dat de output van de versleutelde data hetzelfde probleem heeft (zie ook die andere tekens)

[Woy]

Overigens gebruik je nu 3DES, wat als kraakbaar beschouwd word ( Wikipedia: 3DES-encryptiealgoritme ).

Je kunt beter iets als AES gebruiken.

[Data-base]

Misschien sla ik de plank mis, maar wat is het punt van het beveiligen van het verkeer tussen A en B als hetzelfde verkeer onbeveiligd van client/browser naar A gaat? Ik zie namelijk nergens in het verhaal dat dat wel zo is.

En ik denk dat in het algemeen SSL een voordeel heeft boven het encrypten van je message en doorsturen gezien het feit dat er een PKI vasthangt aan eth gebruik van SSL(ok dat is niet noodzakelijk, maar zou wel moeten).

Op het moment dat je je data zelf encrypt moet je ook gaan bedenken wat je meot gaan doen bij replay attacks, hetgeen niet hoeft bij SSL mits beide partijen een certificaat van elkaar vereisen(meen ik? kan iemand dit bevestigen?)

Snap ik het overigens goed dat je in je startpost met

Ik heb al gedacht aan versleutelen, maar omdat de eerste paar woorden vaak hetzelfde zijn(zoals in edit memo ? with text: ?) is het al makkelijker om de juiste sleutel te vinden.

Het idee hebt om zélf je informatie te versleutelen met je eigen algoritme? Dat is een no-go

[ Voor 20% gewijzigd door Data-base op 19-06-2009 22:28 ]

[Voutloos]

Data-base schreef op vrijdag 19 juni 2009 @ 22:25:
Op het moment dat je je data zelf encrypt moet je ook gaan bedenken wat je meot gaan doen bij replay attacks, hetgeen niet hoeft bij SSL mits beide partijen een certificaat van elkaar vereisen(meen ik? kan iemand dit bevestigen?)

Certificaten zijn primair voor vaststellen van identiteit, om zodoende man-in-the-middle attacks uit te sluiten.

Voor het onmogelijk maken van replay attacks zal je doorgaans alsnog goed na moeten denken over je protocol en mogelijke server state om eea bij te houden (zoekworden: timestamps, nonces, etc.). Bij een protocol bij elke handeling de vraag stellen 'wat gebeurt als ik deze actie (al dan niet kwaadschiks) herhaal?' is in het algemeen een goed idee.

[Confusion]

tom.keim schreef op vrijdag 19 juni 2009 @ 14:19:
en wat nou als Server B geen SSL ondersteund? want iedereen met php ondesteuning moet dit kunnen gebruiken.

Ik moet de eerste (*nix) server nog tegenkomen die geen SSL ondersteunt. Of er een goede manier is om die vanuit PHP te gebruiken weet ik niet, maar ik twijfel er eigenlijk niet aan dat dat mogelijk is.

Om even een stukje van dit fantastische security blog te citeren:

NATE LAWSON

Professional crypto people don’t even get this stuff right. But if you have to encrypt something, you might as well use something that has already been tested.

THOMAS PTACEK

GPG for data at rest. TLS for data in motion.

Geen PHP, Java, wat-dan-ook implementatie pakken: pak de best geteste. OpenSSL voor SSL/TLS, PGP/GPG voor 'gewone' encryptie.

[ Voor 6% gewijzigd door Confusion op 20-06-2009 11:12 ]

[Remus]

Confusion schreef op zaterdag 20 juni 2009 @ 11:10:
Geen PHP, Java, wat-dan-ook implementatie pakken: pak de best geteste. OpenSSL voor SSL/TLS, PGP/GPG voor 'gewone' encryptie.

Wat is er mis met de Java SSL/TLS implementatie?

[Confusion]

Remus schreef op zondag 21 juni 2009 @ 12:37:
Wat is er mis met de Java SSL/TLS implementatie?

Misschien niets. Maar als je zijn blog leest, dan staat 1 ding als een paal boven water: zelfs de experts maken fouten bij het implementeren van crypto. Er zijn zoveel manieren waarop je een subtiele fout kan maken waardoor een ervaren aanvaller informatie of zelfs keys kan achterhalen, dat het eigenlijk een wonder is dat er niet veel vaker van alles gestolen wordt. Blader zijn blog maar eens door op zwakheden in implementaties van allerlei protocollen. Wat betreft Java implementaties is BouncyCastle waarschijnlijk nog het meest betrouwbaar, omdat daar de meeste ogen overheen gegaan zijn. Het punt van Ptacek is gewoon: als het echt veilig moet zijn, moet je er vanuit gaan dat Sun's JCE waarschijnlijk wel bugs bevat.

Daarnaast kan je op allerlei manieren crypto niet goed gebruiken, waardoor je informatie kan laten lekken zonder dat je het zelf doorhebt, door net niet helemaal standaard te werken. Dat kan bijvoorbeeld komen doordat de API die je gebruikt dat net niet helemaal helder documenteert of net niet helemaal handig in elkaar zit. Ook daar zijn OpenSSL en PGP sterk: het is moeilijk ze zo te gebruiken dat het mis gaat. Wat Jeff Atwood in http://www.codinghorror.com/blog/archives/001267.html bijvoorbeeld beschrijft was deel van de inspiratie van het blogartikel waar ik hier boven naar linkte: als je in je API zelf moet kiezen voor een block cipher mode, dan zijn niet-crypto-kenners als jij en ik verkeerd bezig, omdat een oppervlakkig begrip van de mode niet genoeg is om de gevolgen van de keuze te kunnen overzien.

[eghie]

Ik heb ooit in PHP een SSL classe gebouwd. Dit voor in gebruik in het KohanaPHP framework. Maar die kun je vrij makkelijk los strippen van Kohana. Zie hier voor de bron code: http://projects.kohanaphp.com/attachments/233/Ssl.php