Wincrypt és libReSSL SSL-től TLS-ig - GoTo RetroCode
Valójában nagyon egyszerű HTTP/1 klienst írni. Ha olyan funkciók nélkül is megteheti, mint a proxyk vagy az életben tartás, akkor egyszerűen megnyit egy portot, elküldi a GET-sort és egy üres sort, megvárja a választ, elolvassa a fejlécet az üres sorig, mögötte pedig a letöltési adatok vannak, nagyszerű.

Csak hülyeség, hogy ma szinte mindent titkosított formában továbbítanak HTTPS-en keresztül, azaz SSL/TLS-alagúton keresztül.
és nem olyan könnyű megvalósítani magad. Ehhez segítségre van szükséged.
Szerencsére ma már vannak olyan könyvtárak, amelyek mentesíthetik a titkosítástól. De a kereskedelmi projektekben szereti találkozni azzal a követelményrel, hogy ne használja a copyleft nyílt forráskódot.
A Windows alatt akkor kavarhat a Windows Crypto API-val.
Ha pedig engedélyezett egy POSIX operációs rendszer, akkor mindig a libReSSL-t használom, a régebbi OpenSSL projekt rendezett villáját.
Csak emlékeztető:
Az egész a „Secure Socket Layer”, röviden SSL címmel kezdődött, amelynek volt egy 1. és 2. verziója, amelyeket gyorsan elvetettek, mert bizonytalanságok merültek fel benne. Az SSL 3 sokáig tartott, és nem sokkal később jött az SSL 3.1, amelyet TLS (Transport Layer Security) 1.0 névre kereszteltek át.
Ezután a technológiát TLS néven kibővítették és kibővítették, 2018-ban pedig a TLS 1.3-mal érték el a legújabb szintet.
Az SSL 3 biztonsági problémái, amelyeket az elmúlt években szintén felismertek, azt eredményezték, hogy az SSL 3 ma minden szerveren deaktiválódik, és ma gyakorlatilag semmit nem használnak a TLS 1.2 alatt.
WinCrypt
A Crypto-API bosszantó eleme az általános megközelítése, amely valóban jó lenne, ha csak jobban dokumentálnák. Szóval örökké tartott, mire végre rájöttem, hogyan valósítsam meg rajta az SSL/TLS kapcsolatokat.
Dióhéjban itt járok az egyszerű SSL-ügyfelek számára:
OpenSSL és libReSSL
A libReSSL-ben is elérhető OpenSSL API lehetővé teszi a socketek közvetlen használatát, de ez a változat nem tetszik, mert nincs felügyelet alatt a kommunikációs réteg, és nem integrálható a meglévő kommunikációs kezelőkbe.
Ezért memóriafolyam adatpuffereken keresztül haladok. Az SSL/TLS réteg beolvassa és beírja az adatait ezekbe a pufferekbe, majd tovább tudjuk adni őket a kívánt kommunikációs rétegnek (pl. TCP/IP).
Ez a módszer különösen hasznos aszinkron kommunikáció megvalósításakor.
És ez így működik:
Következtetés
Phew, a legutóbbi SSL API-s kirándulásom szinte egy kis oktatóanyaggá vált. Természetesen még mindig sok hiányzik a „tanúsítványok célzott felhasználása” témában. De ha csak a titkosítás érdekli, és nem a kapcsolat hitelesítése, akkor írhat vele egy kis klienst.