Kellene nekem egy olyan szolgáltatás, ahová tetszőleges user-ek tudnak állományokat feltölteni. Az alap probléma az, hogy van egy pendrive-on terjesztett windows-os portable program, amit a felhasználók különféle gépekbe bedugva használnak. Amikor a programból kilépnek, akkor kellene egy adatmentést végezni. A pendrive-on levő adatbázist először helyileg összetömöríti egy program (titkosítva), utána feltölti egy backup tárhelyre.
Fontos, hogy ne más által üzemeltetett cloud storage legyen, hanem saját szerveren.
A backup tárhely megvalósítása a kérdés. Sok user lehet, és nem szeretnék egyesével mindegyiknek külön felhasználói nevet és jelszót allokálni. Az adatmentés kizárólag azt a célt szolgálja, hogy ha tönkremegy a pendrive, akkor elő lehessen venni az utolsó mentést. A mentések mérete max. 10MB. Minden user saját titkosító jelszót használ. Az adatok biztonságát elsősorban a backup-ok AES titkosítása adja. A szerverhez való hozzáféréshez is kell kulcs, hogy ne tudjon bármi feltölteni.
A backup szolgáltatással kapcsolatban a következő elvárások vannak:
* működjön NAT mögül, szinte bármilyen belső hálózatból
* write-only. A felhasználók ne láthassák egymás mentéseit még akkor sem, ha az egyébként titkosítva van tárolva.
* portable - lehessen úgy megvalósítani mint egy egyszerű portable programot amit az adtmentő script a végén meghív
* ne kelljen hozzá saját programot fejlesztenem, már létező szolgáltatást használjon
Korábban már írtam egy programocskát ami 443-as porton töltött föl állományokat HTTPS-sel, de tényleg valami olyat szeretnék amihez nem kell saját programot írni. Létező megoldás kellene!
Nem elvárás de bónusz lenne, ha a feltöltést végző program valami grafikus folyamatjelzőt tudna mutatni. (WinSCP tud ilyet.)
Mik a lehetőségek:
* openssh scp + pscp (putty) - nem sikerült vele egyszerre megvalósítanom a write-only módot
* vsftpd - kilőve, nem tud rendes SFTP-t és SCP-t Kizárólag a passzív módú FTP over TLS-t de az nem megy egy rendesen tűzfalazott belső hálózatból
* proftpd - elvileg ez tud sftp-t de még nem próbáltam
Olyan megoldást én is tudok, amihez programot kell írni, de gondoltam megkérdezem hátha valakinek van ötlete. Mi lenne az a legegyszerűbb és legbiztonságosabb megoldás erre a problémára?
Hozzászólások
Ha azt akarod, hogy mindenhol működjön, akkor https-t csinálj, vagy álcázd annak!
Ha az adatbázis fájlokban van és mindig csak kicsit változik, akkor jó ötlet lehet verziókezelőt használni. Ráadásul azzal könnyű elrejteni egymástól a userek adatbázisát is.
A legegyszerűbb:
* gitosis vagy hasonlóval csinálsz egy git szervert. Minden usernek generálsz egy SSH kulcs/repónév párost, amit felmásolsz az USB-re és bejegyzel a gitosis konfigjába is.
* Egy szkript az adatbázist (fájlokat) mindig kommittolja lokában, és push-olja a szerverre is.
* (persze ez pont nem https, hanem ssh portot használ, ennyi hátránya van. Valahogy talán lehet az ssh-t https-nek álcázni.)
Előnye, hogy a mentés automatikusan inkrementális lesz, ha az adatok ügyesen vannak fájlokba téve, akkor mindig csak kis különbségek közlekednek a hálón, és a szerveren bármelyik régebbi állapotot is vissza tudod állítani.
Tömörítés helyett sok kis fájlba érdemes tenni az adatokat, úgy lesz a leghatékonyabb a git használata.
Más "programozásmentes" megoldás nem jut eszembe. Én kicsit programoznék, és egy mini webszervert írnék, ami csak file uploadot enged, és ezt hívnám a kliensről. A legtöbb nyelven a https feltöltés egyműveletes gyerekjáték - feltéve, hogy nem szakad meg a feltöltés közben a TCP kapcsolat, nincs szükség darabolva feltöltésre.
Igen, egy szimpla https post lenne a legalkalmasabb arra, hogy átmenjen a tűzfalakon. Elég röhejes hogy nem találok olyan kész programot ami ezt tudná. Van egy csomó ingyenes program ami tud adatot menteni, de egyik se alkalmas. Vagy nem portable, vagy nem tud https-t. Egy nagyon egyszerű dologra (POST-oljunk el egy file-t) nem létezik egy portable exe file, de ennél sokkal bonyolultabb backup feladatokra van egy csomó megoldás. Azt hittem, hogy csak én vagyok béna és nem látom a nyilvánvalót... Lehet hogy rászánom a holnapot és írok egyet. Ha a HUP-on nem tudott senki kész programot egy backup problémára, akkor az valószínűleg nem létezik.
Talán a curl és társai környékén lehet valami paraméterezéssel találni megfelelő változatot a kliensre. A szervert szerintem mindenképpen meg kell írnod.
Ha az egyben/darabokban feltöltés problémáját is magadra akarod venni, akkor még bonyolult is lesz, és utána kell olvasni is.
A klienst is megírom. 10 év kihagyás után ma telepítettem a Visual Studio Community-t. Hosszas mérlegelés után döntöttem úgy, hogy ennek C#-ban kell íródnia. Ez kell ahhoz, hogy kicsit portable és natív legyen a végeredmény. Gondolkoztam még Lazarus-on és AutoIt script-en is, de végül maradt a C#. Ez nem kapcsolódik szorosan az eredeti thread-hez, de nem bírom magamban tartani. Az első telepítés után azonnal előjött néhány hiba:
* Extension telepítése után kérdezett valamit de ez a főképernyő alatt jelent meg, lehetetlen volt rákattintani. 10 perc után sikerült rájönnöm hogy tudom leokézni
* A visual form designer sziplán nem működik dot net core-ra. néztem erről fórumokat, az MS 2018 óta ígérgeti hogy majd lesz, de még mindig nincs. (.net framework-ös projektre van de akkor is!)
* plusz a gépem egyszer csontra kifagyott tőle úgy hogy csak hard reset segített. Határozottan állítom hogy ez a visual studio miatt van. Ezt a gépet egy hónapja telepítettem újra, soha semmi hasonló gond nem volt vele. Most meg első telepítés után csontra fagy.
Hát jobb véleményem nem lett az MS-ről, de ez van. Ezt kell szeretni.
.NET-et lehet telepítés nélkül használni? Azért kérdezem, mert nem biztos, hogy szeretni fogják a userek, ha telepítgetni kell.
Java-t tuti, hogy lehet protable módon használni, azt már próbáltam. Én abban csinálnám a klienst is, de én ugye mindent Java-ban csinálok ami mikrovezérlőnél nagyobb procin fut.
Attól függ milyen .NET verzióra fordítod. A .net framework be van építve Windows-ba. Kérdés, hogy melyik Windows-ba melyik verzió van előre telepítve. Erről sajnos nem találtam konkrét táblázatokat. Ha esetleg tudsz ilyen leírást azt beküldheted. Egyébként a legtöbb gép amin használják az Win 10 lesz, és ott biztosan nem kell .NET 4.5 -höz külön telepíteni framework-öt. De azt nem tudom, hogy mi van a Windows 8 és Windows 7-tel. Szívesen használnék bármi mást, ami natív azonnal futtatható kódot eredményez. De vajon mi lenne az? A Java nem ilyen, a Python se ilyen. Sima win32 API (nem managed) kód lenne talán a legjobb. De létezik még olyan modern programnyelv ami ilyet fordít? Az AutoIt az natív win32 kódot fordít, és az azonnal futtatható. Nem kell hozzá keretrendszer. De úgy láttam, hogy ott a feltöltés egy winhttp DLL betöltése után, elég bonyolult módon van, és nincs lehetőség progress bar-t megjeleníteni. Az nekem nagyon hasznos lenne. Milyen lehetőségeim vannak még? Talán Lazarus/Free Pascal, és hozzá Indy komponensek? De vajon azzal menni fog a TLS 1.2 és 1.3 (mármint ha a szerver olyan) Amit most gyorsan megírtam C#-ban az lefordítva 17KB, plusz egy 200KB-os DLL. Ez azért elég jó, feltéve hogy megfelelő lesz a kompatibilitása a régebbi Windows verziókkal is.
A dotnet C# kombinációval teljesen elakadtam. Megpróbáltam a Lazarus-t. A telepítése sokkal egyszerűbb és gyorsabb volt. 5 perc olvasás után már sikerült POST-olni vele egy file-t. Nem kell hozzá .NET framework, viszont egy 17 MB-os EXE-t csinált elsőre. Még lehet hogy lejjebb tudom faragni a debug info-k kikapcsolásával.
Debug info kikapcsolása után 2MB alatti exe-t készített, aminek elvileg a win32 API-n kívül semmi függősége nincs. Még hátra van az, hogy kipróbáljam egy Windows 7-es gépen. Egy probléma valószínűleg borítékolható, TLS titkosítású cél szerverrel nem fog menni. De ez alap Windows 7 probléma. Az is hozzátartozik az igazsághoz, hogy ez az 5 perc alatt készített program egyetlen egy file-t tud POST-olni, valószínűleg több file-ból álló multipart form/data -t nem tud.
Saját boost beast-tel? (Mondjuk egy nginx mögött, ahol csak az egyik path a saját progi.)
https://naszta.hu
Nos, még mindig nincs megoldva a probléma. A szerver oldalt megírtam, ha valakit érdekel:
https://github.com/nagylzs/dropzone-backup-server
Teljesen jól működik. A kliens még mindig nem jó. A C# verziót végül sikerült lefordítani, de egyáltalán nem tetszik az, hogy géptől függően az egész .NET keretrendszert le kell hozzá tölteni. Ez nagyon távol áll az eredeti elvárástól. ("Kis méretű portable program".) A Lazarus verziót is sikerült befejeznem és http -re tök jól működött. De amikor https -t próbáltam akkor kiderült hogy TLS 1.0 fölött nem működik semmivel. Valószínűleg az az oka, hogy az Indy 10 komponensek nem friss OpenSSL verzióval lettek fordítva. Sajnos a freepascal fórumon napok óta senki nem tud erre írni semmit ( https://forum.lazarus.freepascal.org/index.php/topic,47221.0.html ), az pedig szerintem teljesen egyértelmű, hogy egy ilyen program nagyjából semmilyen web szerverrel nem működik együtt (vagy ha van amivel igen az még csak rosszabb).
Azt még el tudtam fogadni, hogy nincsen készen letölthető program ami ennyire pofonegyszerű. De hogy egy normális nyelvet nem találok amivel ilyet lehetne írni viszonylag magas szinten, az már elég idegesítő. Ne kelljen kézzel buffert allokálnom meg pointereket használnom és window message handler függvényeket írnom. A lefordított program ne legyen egy 30MB-os szörny mindenféle dependency-vel, hanem egy egyszerű kis programocska ami win32 API-t használ, esetleg mondjuk olyan DLL-t ami minden Windows-os gépen alapból rajta van (pl. WinHTTP). Szerintem ez nem egy túl nagy elvárás így 2019-ben.
Mondom miket próbáltam:
* Lazarus/FreePascal - nem jó mert elavult, nem kezeli a TLS 1.2-őt (vagy legalábbis senki nem tudja megmondani hogy hogyan)
* C# VBScript és társai - nem jó mert .NET keretrendszer kell hozzá, nekem natív win32 program kellene
* Go - nincs hozzá natív GUI (vagy talán valaki már beleerőszakolt egyet, de akkor sem ez a megfelelő eszköz)
*Java - felejtős, JVM kell hozzá, nem éppen "kicsi és portable"
* Python - sajnos mellékelni kell hozzá egy teljes portable python disztribúciót, baromira nem a megfelelő eszköz (egyébként ez a kedvenc nyelvem, de akkor se erre való)
* AutoIt, AutoHotKey - ezek natív windows programot fordítanak, és van is bennük http API. Elég magas szintű nyelvek, és van benne natív win32 gui is. Ez már majdnem teljesen jó! Sajnos az belőlük elérhető API-k közül egyik sem alkalmas arra, hogy file-ból stream-ként POST-oljak adatokat multipart/form-data -val.
* Rust- ez már elég low level. Még talán épp el tudnám fogadni, de ehhez se létezik natív win32 alapú UI toolkit ( lásd : https://www.reddit.com/r/rust/comments/af43dy/rust_windows_gui/ )
* C++ sima GDI-vel - na ha valamiben akkor ebben egészen biztosan meg lehet csinálni. De nehogy már 2019-ben pointerekkel meg malloc() hívásokkal kelljen bajlódnia annak, aki el akar küldeni egy file-t egy URL-re??? Régen (kb. 15 éve) már programoztam ilyen low level gui-t. Azóta elfelejtettem, és nagyon nem szeretnék újra minimum egy héten keresztül GDI-t tanulni csak azért, hogy ezt meg tudjam valósítani. Nyilván meg lehetne tenni, de a befektetendő munka nagyon nem áll arányban a feladat bonyolultságával. Valami ésszerűbb megoldás kellene.
De milyen opciók vannak még? Kitépem a hajam.
Bárki tud még bármilyen nyelvet amivel érdemes lenne próbálkoznom?
Félve kérdezem: PowerShell?
ha csak annyi kell, hogy összepakolni, és elküldeni, mert minden mas megvan, arra eleg valami zip+curl, meg egy ketsoros batch... mondjuk nem a legszebb megoldas, de legalabb egyszeru
“Any book worth banning is a book worth reading.”
Java-bol is lehet nativ programot forditani.
https://www.graalvm.org/docs/reference-manual/native-image/
Csak pontositas, nem azert irom, mert Java-t kene hasznalni erre a feladatra.
Ezt a megoldás nem nevezném "Natívnak". Legfeljebb portable jelző aggatható rá.
Van/volt valódi natív java fordító: GCJ
Egy éve már befejezték a fejlesztését, de a final GCJ ma is használható.
Én Amazon S3/Glacier-be menteném, és hozzá egy S3browser klienst használnék.
Az alap feladat, hogy POST-oljunk egy file-t egy kicsi portable natív programmal. Erre te azt mondod hogy használjak egy nagy, nem portable programot ami nem sima file POST-ot használ egy olyan helyre ahová nem akarok adatot küldeni. Bocsi de ez fényévekre van attól amit szeretnék.
Sry csak láttam, hogy nyitó hsz-ben kész backup szolgáltatást kerestél, lehet akkor e szerint érdemes módosítani az eredeti kiírást.
S3browser egyébként portable, de az S3 API is publikus, nem kizárt, hogy létezik számodra is megfelelőbb implementáció.
Igazad van, nem jól írtam ki a kérdést. Nem egy más által üzemeltetett kész backup szolgáltatást keresek, hanem saját magam által üzemeltetett verziót. Ez nem volt egyértelmű.
Módosítottam.
Minio ?
Szerk: de ha irni akarsz, nezz go-t, franko egybeforditott binarisokat csinal
A Go-t már néztem, lásd kettővel följebb.
Mondjuk ha tudsz go-hoz olyan ui lib-et ami nem tölt be 30MB-nyi qt vagy gtk dll-t windows alatt, akkor ne kímélj. :-)
Lehet mégis lesz. https://github.com/lxn/walk
Elnézést, nem vettem észre, hogy a go-t már elvetetted.
Az a baj, hogy bár szerinted tök egyszerűek az igényeid, igazából nem:
Értem én, hogy a go (vagy akármi mellé) hozzá kell tenni 30 mega qt-t, de most komolyan, és akkor mi van?
Ha mindenféleképp gui kell, és te akarod fejleszteni, akkor megkeresed a legkisebb .NET-et ami kell, és megírod. Mondjuk én nem nagyon értem, hogy minek a gui. Ha tényleg annyi a dolga, hogy a processz végén húzzon egy csíkot, akkor huzasd egy terminál ablakban. Vagy legyen a feltöltés böngészőben, egy ismert urln, aztán húzzon csíkot a javascript. Vagy legyen meta refresh x másodpercente, mint 96ban, és akkor még javascript sem kell :)
Mondjuk nem értem, hogy miért nem jó a kiscsilló backup sw valamelyike, vagy egy kutya egyszerű (mondjuk) ftp, ahol egy jól sikerül setgides, rw only könyvtárba mennek a dolgok egy akármilyen neked tetsző klienssel.
> Elnézést, nem vettem észre, hogy a go-t már elvetetted.
> Értem én, hogy a go (vagy akármi mellé) hozzá kell tenni 30 mega qt-t, de most komolyan, és akkor mi van?
A teljes gui toolkit mellékelése is elfogadható, ha nincs más. :-)
> Ha mindenféleképp gui kell, és te akarod fejleszteni, akkor megkeresed a legkisebb .NET-et ami kell, és megírod.
Igen, azt hiszem ez lesz belőle. dotnet 4.5, lefordított program kb. 300-400KB és Win 8-tól fölfelé mindennel megy. (Win 7-tel csak framework letöltéssel)
> Mondjuk én nem nagyon értem, hogy minek a gui. Ha tényleg annyi a dolga, hogy a processz végén húzzon egy csíkot, akkor huzasd egy terminál ablakban.
Á nem értheted ezt. Ezek orvosok, és nem szeretnek látni fekete terminál ablakokat pöttyökkel. :-D
> Vagy legyen a feltöltés böngészőben, egy ismert urln, aztán húzzon csíkot a javascript. Vagy legyen meta refresh x másodpercente, mint 96ban, és akkor még javascript sem kell :)
De ahhoz el kellene indítani egy böngészőt és behúzni a backup file-t. Ilyeneket nem várhatok el tőlük. Annyit lehet elvárni, hogy ha bedugja a pendrive-ot akkor elindul a program, és amikor kilép a végén akkor megvárja hogy a progress bar elérjen 100%-ig. Sok felhasználóra számítok, és inkább most töltöm el vele az időt, mint később a szükséges extra support-tal.
> Mondjuk nem értem, hogy miért nem jó a kiscsilló backup sw valamelyike, vagy egy kutya egyszerű (mondjuk) ftp, ahol egy jól sikerül setgides, rw only könyvtárba mennek a dolgok egy akármilyen neked tetsző klienssel.
Azért nem jó az ftp, mert ismeretlen helyről lesz használva a kliens program, valószínűleg kórházak, magánrendelők és ismeretlen cégek belső hálózataiból. Olyan megoldás kell, ami átmegy a tűzfalakon, és biztonságos. Egy ilyet ismerek, a HTTPS-t.
Ha nem lesz más akkor lehet hogy mégis marad ez. Bár nem annyira tetszik hogy egy komplett third party ui toolkit-et be kell tölteni egyetlen progress bar miatt egy olyan gépen, ahol van natív ui is. :-( De még mindig jobb mint pár 100 MB .net framework.
megnezted a minio-t is, vagy ignoraltad a hozzaszolas felet? behuzol egy s3 libet, kiraksz fole egy "feltoltes" gombot egy ablakba, es kesz van amit akartal.
Megnéztem, de ha jól értem akkor az cloud-ba tölt. Arról pedig törvényileg le vagyok tiltva.
Nem jól erted. A minio egy self hosted s3 alternatíva. Tud kompatibilis is lenni, meg van saját kliens, bindinggel kb mindenhez is. Gyak a server oldalt tudja egész jól, meg stabil feltöltést, resumeot ilyesmit. Ill ha kell segít a normális, elosztott tarolasban is.
Csak hogy elkerüljük a további cloud storage-s hozzászólásokat: ezek a fileok részben olyan mentések amik egészségügyi adatokat tartalmaznak. Konkrétan törvény tiltja a Magyarország területén kívüli adattárolást. Szóval semmiféle giga cég által üzemeltetett cloud storage nem jó.
De ez csak egy kis magyarázkodás. Az alapfeladat a lényeg: nagy file https post-olása progress bar kíséretében, kicsit natív portable alkalmazásból.
Whoa
Félve merem megkérdezni: egy Apache + mod_dav + mod_dav_fs, letiltott GET-tel (vagy ha még nagyobb kontrollt akarsz, akkor pl. egy PHP és SabreDAV-val azt csinálsz, amit akarsz)? A programod a backup végeztével felcsatolja (lehet, hogy nem is kell, mert tudsz közvetlenül UNC pathel is hivatkozni rá) és megkéri a shellt (mármint az explorer.exe-t), hogy másolja fel, így a standard másolás dialógus ablakot kapod (Win 10 alatt már egész értelmes).
BlackY
"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)
De ehhez nem kellenek rendszergazda jogok meg egy mount dir? Itt egy pendrive-ról futó portable alkalmazásról van szó, amit normál user-ként dugdosnak bele gépekbe. Lehet hogy ez is működne, de elég nehéz lenne erre egy portable kliens programot írni, ami rgazda jogokat igényel, mount-ol másol és umount-ol. Az összes lehetséges hibát kellene ellenőrizni és kezelni, hogy az egyszeri felhasználó értelmes üzenetet kapjon. Elég bonyolultnak tűnik.
Az eredeti kéréshez képest azóta már megszületett a szerver oldali saját programkód, azóta letettem arról, hogy programírás nélkül megúszom.
Nem kell hozzá rendszergazda jog, jó ideje WebDAV-ot is simán kezel a rendszer UNC útvonallal (elég hülye szintaxissal: \\[szerver]@SSL\DavWWWRoot\mappanév), kb. pont mintha egy SMB megosztásra írnál. Vannak hülyeségei a kliensüknek (a szokásos Windows stílusban semmi értelmes hibaüzentet/kódod nem ad ha pl. a cert-et nem akarja elfogadni, meghatározatlan hiba meg hasonló bullshiteket ad helyette), de kezelhető.
BlackY
"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)
Na ezt jó tudni!
Alapból elérhető .NET verziók a különféle Windowsokban:
https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/versi…
Ezt a "ne kelljen hozzá programot írni" ezt nem értem. Ennek egyedi megoldásnak kell lenni, a te GUIddal, hibaüzenetek megmutatásával, vágólapra másolással, logolással (network problémák felderítéséhez), a log fájl megmutatásával, Retry logikával...
Ez egy egyedi kis program kell hogy legyen.
Azt mondja még az Internet, hogy " TLS 1.2 is supported from .NET 4.5 onwards" ez meg Windows 8-tól, illetve Windows Server 2012-től bent van az OS-ben.
Na pontosan ilyen táblázatot kerestem, csak nem találtam meg. ( https://hup.hu/comment/2395952#comment-2395952 ) Ezek szerint a .NET 4.5 garantáltan menni fog Windows 8 -tól fölfelé bárhol. A Windows 7-re meg külön telepíteni kell. Remélem, hogy ha a felhasználó Windows 7-et akar használni, akkor meg lehet vele értetni hogy oda még plusz dolgokat kell telepíteni. Még mindig támogatott: https://support.microsoft.com/hu-hu/help/4057281/windows-7-support-will…
Szóval azt leszámítva hogy W7 -en framework-öt kell hozzá telepíteni, mégis ez a legjobb megoldás. W8-tól fölfelé a 300KB-os program méret elég baráti.
> Ezt a "ne kelljen hozzá programot írni" ezt nem értem.
Ez egy rendkívül egyszerű feladat (küldjünk el egy file-t egy szerverre). Amikor elkezdtem foglalkozni a feladattal, akkor azt hittem hogy erre a triviális és nagyon általános feladatra találni fogok egy hasonlóan triviális és általános programot. Azóta a probléma kinőtte magát, és szent küldetés vált belőle. :-) Mostanra 10-szer annyi időt töltöttem el vele mint amennyit ér az egész, de most már rendesen meg akarom csinálni.
Újra előveszem a .NET-es programkódot és megpróbálok vele megbarátkozni.
Köszönöm a segítséget!
Egyik oldalt ez egy ~10-20 soros PHP script (vagy bármi random, amiben írod) a másik oldalt meg ~10 sornyi kód akármiben, amiben a programot írták + megfelelő konfigolás. Már, ha az általad említett dolgok, mint titkosítás megvan. Ha nincs, akkor felmehet a komplett dolog kb. 2-300-ig is.
Nem értem a problémát.
Hát ez nagyon nem akar sikerülni. Most a C#-os programom ezt írja:
> A kérelmet megszakították: Nem sikerült létrehozni az SSL/TLS biztonságos csatornát.
Ez egy jogtiszta, teljesen frissített Windows 10-re telepített Visual Studio 2109-ból fordítva, és a Visual Studio is pont ma lett frissítve.
A szerver SSL tesztje: https://www.ssllabs.com/ssltest/analyze.html?d=dropzone.mess.hu&s=164.6…
Ha nem erre a szerverre POST-olok hanem https://postman-echo.com/post -ra, akkor működik. Ha nem ebből a C# programból post-olok hanem egy böngészőből, akkor is működik. Csak akkor nem működik, ha C#-ból erre a szerverre próbálom.
Ha downgrade-elem a szervert hogy megengedje a TLS 1.0 kapcsolatokat, akkor működik. Ezek szerint a .NET 4.5 nem képes legalább TLS 1.2- re? WTF???
Valami cipher basz lesz, vagy a c# nem a beépített certstoreból működik. Vagy kapard ki tls hibaüzenetet, vagy wwiresharkold meg.
Megtettem. Annyira nem nagyon értek hozzá de ezek vannak benne:
TCP SYN ,TCP SYN ACK , ACK seq=1 ki, TLSv1 "Client Hello" ki, TCP ACK Seq=1 b, TLSv1 Alert be
Az utolsó TLSv1 alert ilyen:
TLSv1 Record Layer: Alert (Levl: Fata, Description: Protocol Version)
A negyedik csomagnál (kimenő TLSv1 "Client hello") ez van a header-ben:
TLSv1 Record Layer: Handshake Protocol: Client Hello, Content type: 22 (handshake), Version: TLS 1.0 (0x0301)
Ezek alapján nem a cipher-rel van baja, hanem a TLS protokol verzióval. Egyébként a cipher list kézzel van beállítva a szerveren, és ha TLS 1.0 -ra veszem le a szervert akkor nincs baja vele. De ha TLS 1.2-re veszem a minimum szintet, akkor handshake error lesz.
Na most akkor mondja meg valaki, hogy egy frissített Win 10-en alapból mi a búbánatos f*szért TLS 1.0 -val akar kapcsolódni? Normális dolognak számít, hogy egy legalább 10 éve deprecated protokolt akar használni?
Így működik!
> System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12 | System.Net.SecurityProtocolType.Tls11;
Eldobom az agyamat, hogy ezt még külön mondani kell neki. Miért egy 10 éve biztonságtalannak számító sz*r a default?
Bár az is lehet, hogy az NSA vette rá a Microsoft-ot hogy ez legyen az alap. Abban bízva, hogy a sok hülye programozó nem foglalkozik vele, és így majd könnyebb lesz feltörni.
Mert egyrészt a 4.5 régen volt, másrészt az MS hülye volt. És nem a windows 10 miatt ilyen, hanem a régi .net miatt. Van itt egy hosszabb szenvedés arról, hogy hogyan kell beállítani a régebbi .NETeket, hogy legyenek kedvesek és az OS által támogatott TLS verziókat használják. Ez kissé jövőtállóbnak tűnik, mint amit te csináltál, különös tekintettel arra, hogy épp nyakunkon a TLS1.3.
> We recommend that you: Target .NET Framework 4.7 or later versions on your apps. Target .NET Framework 4.7.1 or later versions on your WCF apps.
Aha, de ugye akkor az összes Win8-at is kizártam az egyszerűen, külön framework telepítés nélkül használható rendszerek közül. általuk javasolt másik "megoldás":
> Set the SchUseStrongCrypto and SystemDefaultTlsVersions registry keys to 1. See Configuring security via the Windows Registry. The .NET Framework version 3.5 supports the
SchUseStrongCryptoflag only when an explicit TLS value is passed.Na persze, de az ugye világos, hogy ezt nem a program írójának, hanem a programot futtató rendszer gazdájának kell csinálni? Egy pendrive-ról futtatható portable program esetén ez gyakorlatilag nem használható "megoldás".
Őszintén szólva annyira nem néztem meg. Oda lehet tenni a portable izé mellé is egy .reget, bár kétségtelen hogy kevésbé elegáns.
Mondjuk bizonyára ki lehet túrni, hogy az adott OS mit tud. :)
Ennél rosszabb a helyzet. Azt szerintük a HKEY_LOCAL_MACHINE alá kellene tenni, de olyat csak rendszergazda tud. Egy pendrive-ról indított portable program esetén a user-nek jellemzően nincsen rendszergazda joga. Akkor már inkább az a megoldás a jobb amit én csináltam - a programból beállítom hogy arra a egy kapcsolatra engedélyezze a magasabb verziót.