paymentgateway
paymentgateway copied to clipboard
csob
Odstranění slabých šifer
Dobrý den,
měl bych dotaz ohledně tohoto emailu, přiloženého níže, který přišel našemu zákazníkovi. Přiznám se, že nevím jak poznám jestli se mě (případně Vás) to nějak týká.
Nebo jestli to je nějaká akce čistě ČSOB a na šifrování komunikace s platební bránou to nemá vliv?
Víte o tom něco a případně mohl bych poprosit o objasnění o co jde?
Předem díky moc za odpověď
Vážený kliente, V rámci zvyšování bezpečnosti platební brány došlo k odstranění šifer, které již nejsou považované za bezpečné. Tyto šifry dle specifikací jsou považovány za prolomitelné a hrozí zde riziko jejich prolomení. Riziko vzniká například v podvržení, nebo úpravě, platebního požadavku z e-hopu a z toho plynoucí možné peněžní traty (podvržení částky, obsahu košíku a dalších údajů). Kromě jiného také vzniká riziko odposlechu přenášených dat třetí osobou. Tento upgrade musí být proveden co nejdříve, neboť je potřeba dodržovat standardy PCI-DCC a chránit i data zákazníků. S těchto důvodů bychom Vás chtěli požádat o update SSL knihovny na vaší straně, či update SSL knihovny ve vaší mobilní aplikaci. V první řadě se provede test na integračním rozhraní platební brány, kde se otestuje funkčnost vaší nové knihovny. Testování se provádí z toho důvodu, že po odstranění rizikových šifer na API platební brány může dojít k problémům se sestavením SSL spojení z důvodu rozdílu sady šifer v SSL knihovně na straně zákazníka a platební brány. Odstranění rizikových šifer proběhne na integračním rozhraní 1.4.2022. Od této chvíle budete mít možnost otestování nových knihoven na vaší straně. Po jejich úspěšném otestování bude dále naplánováno nasazení na produkční prostředí. Předpokladem je, že otestování proběhne v průběhu dvou měsíců, tedy nasazení na produkční prostředí proběhne v průběhu června. Níže je výčet šifer, které jsou považovány za prolomitelné a přestanou být podporovány na API platební brány.
- • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
- • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
- • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
- • TLS_RSA_WITH_AES_128_GCM_SHA256
- • TLS_RSA_WITH_AES_128_CBC_SHA
- • TLS_RSA_WITH_AES_128_CBC_SHA256
- • TLS_RSA_WITH_AES_256_GCM_SHA384
- • TLS_RSA_WITH_AES_256_CBC_SHA
- • TLS_RSA_WITH_AES_256_CBC_SHA256
- • TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
- • TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
V případě dalších otázek či detailu k uvedené problematice nás neváhejte kontaktovat na schránce platební brány [email protected]. S pozdravem
Dobrý den,
požadavek byl předán na servis.
S pozdravem
-- Jan Stuchlík IT Support Specialist
~Zákazník může provést kontrolu, zda-li jeho systém potřebuje update SSL knihoven, zkusí-li se spojit s následující adresou: https://tapi.tplatebnibrana.csob.cz/.~
Toto je výstup, pokud dojde k úspěšnému spojení:
~V takovémto případě není nutno provádět update SSL.~
(Aktualizace: 1. 4. 2022 byla zmena promitnuta na sandbox, spojeni lze tedy uz overit beznym zpusobem testu komunikace s integracnim prostredim… OK odpoved od https://iapi.iplatebnibrana.csob.cz/api pri nacteni ze serveru odkud normalne zakladate volani je dostatecne overeni.)
Samozřejmostí je, aby byl test proveden ze správného serveru, který se napojuje na platební bránu, její API či další systémy banky. Je důležité spojení z hlavního serveru, ze kterého je zahájeno spojení - může být neaktuální SSL knihovna.
Update se také týká zákazníků, kteří se přímo napojují na tyto URL banky a nepoužívají prostředníka (tedy jinou firmu, zprostředkující spojení s bankou, přičemž se zákazník připojuje na prostředníka). Pokud je spojení nepřímé a zákazník využívá prostředníka, musí jej kontaktovat a požádat ho o kontrolu SSL knihoven. Opět je možno vyzkoušet URL výše, ale ze správného serveru.
Výstup může být proveden i z konzole serveru, například otestováním openssl příkazu na danou URL.
Dobrý den, při obyčejném GET požadavku z produkčního serveru se nám vrátí hlavička 503 a tedy musíme provést update. U knihovny openssl je nutný update na verzi 3.x, nebo stačí poslední jedničková verze (1.1.x)?
Dobrý den,
Jsme PCI-DSS prostředí, SSL knihovny by měly byt neustále aktualizované. Otestujte 1.1.x, ale doporučujeme provést upgrade na co nejvyšší možnou verzi.
S pozdravem,
Daniel Komárek IT application specialist
@radek-jurica Samozrejme co se podpory sifer tyce nema tolik vliv verze, jako spis konfigurace, sestaveni ci dana verze v dobe kompilace. https://www.openssl.org/docs/man1.1.1/man1/ciphers.html openssl ciphers -s -tls1_2 vam pomuze ukazat ktere suity vase prostredi aktualne pro danou verzi muze pouzit.
Spis je problem misto nalezeni slabych sifer z toho seznamu poznat pokud vam chybi nektere moderni. Obecne od OpenSSL 1.0.1c/d vyse by mely potrebne byt pritomne, ale je mozne ze je system nejak jinak zkonfigurovany.
Co se tyce verzi, tak se OpenSSL 1.1.1 LTS vs 3.0.x lisi primarne ve strukture, licenci, verzovani atp. — a nejsou vuci sobe uplne dobre zpetne kompatibilni, ale to plati i 1.x verzich (napr. zmena 1.0.2- na 1.1.0+ obnasi taky spoustu kompatibility starosti) ale jinak oboje maji aktualni probihajici podporu, a 1.1.1 bude jeste rok a pul aktivne podporovana; na rozdil od cehokoliv starsiho:
The latest stable version is the 3.0 series supported until 7th September 2026. This is also a Long Term Support (LTS) version. The previous LTS version (the 1.1.1 series) is also available and is supported until 11th September 2023. All older versions (including 1.1.0, 1.0.2, 1.0.0 and 0.9.8) are now out of support and should not be used. Users of these older versions are encouraged to upgrade to 3.0 as soon as possible. Extended support for 1.0.2 to gain access to security fixes for that version is available.
- 2022-Mar-15
openssl-1.1.1n- 2022-Mar-15
openssl-3.0.2
Takze pro nyni by 1.1.1n (vydana stejne jako posledni 3.x) mela byt zcela v poradku, pokud vam kompletni upgrade na 3.x pri jedne praci aktualne neprijde vhod.
moze sa to vyskusat aj vytvorenim plaby na integracne prostredie (sandboxu)?
@maros-852 Ano, od minuleho patku hej — zminene weak cipher suites jsou jiz na sanboxu vypnute, tzn. pokud se nyni spojite a operace probihaji, vse je v poradku.
@maros-852 Ano, od minuleho patku hej — zminene weak cipher suites jsou jiz na sanboxu vypnute, tzn. pokud se nyni spojite a operace probihaji, vse je v poradku.
Dobrý den,
při GET požadavku adresy https://tapi.tplatebnibrana.csob.cz/ je mi vrácena chyba 503, ale vytvoření požadavku platby v integračním prostředí (https://iapi.iplatebnibrana.csob.cz/api/v1.8) mi v pořádku funguje, jak tomu tedy rozumět?
Děkuji za odpověď
@jardadu Hezky den, ve strucnosti: pokud pro vas v tuto chvili iapi/ibrana funguje, nemusite se o nic starat, vse je v poradku… a bude i pozdeji behem roku az stejna zmena nastane v produkci.
(PS: @radek-jurica Toto se nejspis tyka i vas — radeji si dnes uz zkousejte spojeni na ibranu, a informaci o tbrane prosim ignorujte.)
Podrobneji: tu 503 vidite ("spravne") protoze tapi/tbrana neni prostredi, kam by vas firewall pustil cokoliv delat — byl to pouze "hack", kterym se v dobe vzniku ticketu (tj. jeste pred zmenou TLS konfigurace na ibrane) dalo overit samotne HTTPS spojeni na podobne prostredi, kde uz tato konfigurace byla nastavena. A tak trochu nestastne je HTTP/503 {900: request rejected} jedina odpoved, ktere se dokazete toho prostredi doptat. Ale to nevadi — uz to ze tuto komunikaci dokazete obdrzet znamena, ze se samotne HTTPS spojeni zdarilo navazat.
Nicmene od minuleho patku 1. 4. 2022 kdy se konfigurace na ibrane zmenila je opravdu nejlepsi cesta si zavolat nejakou podepsanou echo operaci primo na sandboxu, a krom overeni spojeni dostanete i smysluplnejsi payload odpovedi.
Hezký den, děkuji za tagnutí a informace. Vyzkoušel jsem vytvoření nové transakce na testovacím api a následné přesměrování/připojení na testovací platební bránu a vše proběhlo v pořádku. Na adrese https://iplatebnibrana.csob.cz/ jsem mohl úspěšně dokončit transakci přes testovací platební kartu a v testovacím rozhranní na adrese https://iposman.iplatebnibrana.csob.cz/ se transakce zobrazila jako úspěšně dokončená. Plánované úpravy v červnu na produkční platební bráně se nás tedy nedotknou, je to tak? Děkuji.
@radek-jurica Je to presne tak. Soucasnou konfiguraci sandboxu dostane v lete i produkce, takze pokud nyni bez problemu zakladate a testujete transakce, nemusite se o nic starat — mate v systemu moderni sifrovaci sady a vypnuti starych nebezpecnych na serveru se vas nijak nedotklo. 🎉
Dobrý den, rád bych se zeptal, jaká šifrování po vyřazení těch zmíněných podporujete. Aplikace, kde přístup k platební bráně používáme, běží na Windows Server 2012r2. Seznam podporovaných šifrování je zde. Pomocí SSL Server Test jsem našel, že iapi.iplatebnibrana.csob.cz podporuje tato šifrování:
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
Je tento seznam kompletní? Bohužel ani jedno z nich není pro verzi serveru 2012r2 podporováno a zatím jsem nenašel způsob, jak je pro .NET aplikaci povolit. Děkuji
Zdravim, je to presne tak, pro TLS 1.2 jsou povoleny pouze analogicke sifry jako pouziva vychoze TLS 1.3, tzn. zadne Diffie–Hellman bez jednorazovych klicu ap., obecne jde jen o PFS suity — zda je mozne pridat jeste navic nejake dalsi "soucasne" ECC ci vice kompatibilni GCM RSA, ale bez znamych omezeni/zranitelnosti v podpisech ci vypoctech, to bude muset poradit nekdo vice fundovany za networking (zda treba ~(bez PFS(?))~ lze provozovat _ECDHE_ i pomalejsi _DHE_ varianty toho stejneho AEAD, ktere by v 2012 R2 mely byt?) — nicmene v tuto chvili ten seznam pro TLS 1.2 vnimame stejne, a skutecne 2012 R2 tyto ECDHE-RSA neumi (ruzne aplikace si sice mohou prinest vlastni vrstvu, ale .NET aplikace spoleha na systemovy Schannel a ten opravdu pokud takovou suitu nedoruci Windows Update tak neni jak jinak ozivit) a prvne se to objevuje az od Server 2016 dale.
@jahr Tady se to nekomu podarilo "hacknout" https://community.spiceworks.com/topic/2333529-new-ciphers-old-servers-surely-there-s-a-workaround ale spis bych to videl ze se jim tim "povedl" nejaky downgrade kde spis nasli konfiguracni mezeru protistrany. Kazdopadne zkuste, je k tomu i tool https://www.nartac.com/Products/IISCrypto — treba pomuze. Take si overte ze mate nainstalovany update 2919355 ktery mozna neco z toho pridaval.
@dkomarek2 Tzn. ano, odstraneni CBC a non-DHE je urcite spravne, ale nedalo by se naopak jeste pridat neco navic, co by pomohlo s kompatibilitou, bez oslabeni cele suity? Vychazim z PCI DSS aktualnich doporuceni: https://wiki.mozilla.org/Security/Server_Side_TLS#Intermediate_compatibility_.28recommended.29
0xC0,0x2B - ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD 0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD 0xC0,0x2C - ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD 0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD 0xCC,0xA9 - ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD 0xCC,0xA8 - ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD 0x00,0x9E - DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD 0x00,0x9F - DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEADRationale:
- All cipher suites are forward secret and authenticated
- TLS 1.2 is the minimum supported protocol, as recommended by RFC 7525, PCI DSS, and others
- ECDSA certificates are recommended over RSA certificates, as they allow the use of ECDHE with Windows 7 clients using IE11, as well as allow connections from IE11 on Windows Server 2008 R2
- The cipher suites are all strong and so we allow the client to choose, as they will know best if they have support for hardware-accelerated AES
Takze pridani GCM variant _ECDHE_ECDSA_ a _DHE_RSA_ s klicem 2048-bit a delsim (dle aktualnich FIPS/NIST specs) by melo byt i pro tento hardening stale pripustne? Kdyztak me pls nekdo opravte, pokud to vidim prilis ruzove (a treba ty neelipticke suity jsou nevhodne)… /cc @matejcekdav @tomkadlecek
Dobrý den, děkuji za reakci. Odkaz jsem četl a IISCrypto zkoušel. Bohužel, ani jedno nefunguje (obojí dělá to samé, jen IISCrypto pro to má GUI), můžu sice "povolit" nějaká šifrování, ale když v knihovnách SChannel nejsou, tak to samozřejmě nepomůže :-( Spíš bych se rád zeptal, jestli je šance, že bude dodatečně přidáno nějaké zpětně kompatibilní šifrování, nebo jestli je potřeba upgradovat produkční Windows Server. Času moc nezbývá a upgrade není práce na odpoledne ;-) Děkuji
@jahr Byly pridany elipticke chainy ad #625 — nyni by si i v defaultnim nastaveni mel Windows Server 2012r2 dokazat vybrat.