Delphi

Delphi + https + POST - paras salauskirjasto?

Miten parhaiten Delphillä toteutetaan se, kun pitää tehdä http post -kysely (GET EI kelpaa) JA URL alkaa https:// eli sivu siirtyy salattuna eli SSL on käytössä? Ainoa toistaiseksi toimintavarmaksi osoittautunut on Microsoftin WININET API. Edes Microsoftin oma uudempi (ja ehkä nopeampi) API ei tässä tilanteessa toimi oikein ! Muut kuin MS: Onhan noita: OpenSSL ja CryptLib. MUTTA: Sekä OpenSSL että CryptLib kärsivät samasta ongelmasta: JOS sekä palvelimella että asiakassovelluksen käytössä on sama versio (tai edes ajallisesti lähellä toisiaan julkaisupäivältään oleva versio) niin todennäköisesti toimii ok. Mutta jos palvelimella ja asiakassovelluksen käytössä on eri ajoilta oleva salauskirjasto, niin todennäköisesti ei toimi ! Sopii kysyä: MIKSI salauskirjastot eivät voisi toimia näin: Lähtökohtaisesti käytetään salaukseen uusinta / parasta versiota salausprotokollasta, jota sekä palvelinpää että asiakaspää tukevat. Tästä poiketaan VAIN, jos joko palvelimen tai asiakkaan salauskirjasto on konfiguroitu siten, että nimenomaan ehdottomasti kielletään tiettyjen salausprotokollien tai salausprotokollaversioiden käyttö: tällöin estetään ko. salausprotokollat tai salausprotokollaversiot ja jos ei toista soveltuvaa löydy, yhteydenmuodostus epäonnistuu. Tällöin oikein suunnitellun salauskirjaston pitäisi tarjota funktio, jota kutsumalla saisi aina selville miten kunkin protokollan tai version osalta neuvottelussa kävi ! Esim: SSL 1.0: Server: Disallowed, Client: Disallowed (due to known vulnerabilities). Nyt homma menee hankalaksi, kun joissain tilanteissa yhteydenmuodostus epäonnistuu eikä ole ollenkaan selvää miksi, tai mitä voisi tehdä tilanteen korjaamiseksi ! Jatkanko siis vain Microsoftin WININET API:n käyttöä, koska oman kokemukseni mukaan se on ainoa, joka toimii aina luotettavasti (tai sitten en vain ole törmännyt sellaiseen palvelimeen, joka tuon kanssa kieltäytyisi yhteistyöstä). HUOM: Jos sinulla ei ole muuta kommentoitavaa kuin: "Delphin ongelma on se, että siinä ei ole mitään sellaista miksi pitäisi käyttää sitä kun parempaakin löytyy.", niin parempi, kun et vastaa ollenkaan. Kas, kun jokin ulkoinen salauskirjasto toimii ihan samalla tavalla, olipa kutsuva sovellus tehty Delphillä tai vaikkapa C -kielellä. JOS ko. salauskirjasto on tehty C -kielellä, niin funktiot käyttävät joko C -kielen oletuskutsutapaa ( cdecl ) tai Windows API:n kanssa samaa tapaa ( stdcall ). GPL -lisensioidut käyttävät aina tuota cdecl -tapaa. HUOM: vaikka M-Kar tulee tod.näk. taas jauhamaan typeryyksiään tyyliin "ei kutsutavalla ja lisensioinnilla ole mitään tekemistä keskenään", niin kyllä niillä vain ON tekemistä (teoriassa tietenkään ei pitäisi olla, mutta käytännössä on!). Nimittäin: Et tule koskaan löytämään GPL -lisensioitua DLL -kirjastoa, joka käyttäisi Windows API:n kanssa samaa tapaa ( stdcall ). Tähän on syynsä ! Niiden miettiminen jää sinulle vapaaehtoiseksi harjoitustehtäväksi, mutta ne EIVÄT ole tässä pääasia ! Mainittakoon vielä, että en tykkää Indy -komponenttien toteutustyylistä. Eli joko suoraan MS APIn avulla toimiva tai sitten Synapse + siihen soveltuva salauskirjasto. Mutta miksi tosiaan salauskirjastojen yhteensopivuudesta on tehty ongelma ? MS:n omista API -vaihtoehdoista se uudempi ja nopeampi toimii oikein hyvin https GET -pyynnöissä sekä http POST -pyynnöissä. Mutta yhdistelmä https + POST on sille myrkkyä, onneksi vanha kunnon WININET API toimii hyvin ! Ikävä kyllä yhä useampi netti-API on tehty siten, että https POST on ainoa, joka kelpaa !