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 !
Delphi + https + POST - paras salauskirjasto?
20
426
Vastaukset
- R348934
Jos wininet koodi toimii, niin miksi tarvetta siirtyä käyttämään jotain muuta?
Omat Windows sovellukset käyttää MSXML2.XMLHTTP.6.0 (joka sisäisesti lienee wininet.dll) ja vaihtoehtoisesti WinHttpRequest.5.1 (winhttp.dll)
GET ja POST toimii, riippumatta onko ssl käytössä vai ei, ei toimivuudessa ole eroa. Suurimmat ongelmat on ollut lähinnä, kun käyttäjä tietoturva jostain syystä blokkaa- http_post
"Omat Windows sovellukset käyttää MSXML2.XMLHTTP.6.0 (joka sisäisesti lienee wininet.dll) ja vaihtoehtoisesti WinHttpRequest.5.1 (winhttp.dll)"
Oletko todella onnistuneesti saanut WinHTTP:n toimimaan silloin, kun käytetään POST -pyyntöä https -osoitteeseen?
Jos, niin miten ?
WinHTTP toimii oikein hyvin, kun joko on https GET tai http POST.
Mutta tuo https POST on osoittautunut vaikeaksi tapaukseksi, ja toistaiseksi vanha Wininet API on ainoa, jonka olen saanut toimimaan luotettavasti tässä tapauksessa.
"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ä?"
Tällaista ohjetta löytyi: http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Using_an_HTTP_Client
"Edes Microsoftin oma uudempi (ja ehkä nopeampi) API ei tässä tilanteessa toimi oikein !"
Kyllä toimii: https://msdn.microsoft.com/en-us/library/system.net.webrequest.create(v=vs.110).aspx
"Nimittäin: Et tule koskaan löytämään GPL -lisensioitua DLL -kirjastoa, joka käyttäisi Windows API:n kanssa samaa tapaa ( stdcall )."
Kääntäjästä se on kiinni ja tuo on täysin yhdentekevää.
"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ä)."
Vanhoja kannata käyttää kun ne siivotaan pois aiemmin. Käytä sitä Delphin omaa ja jätä sen toimivuus Embarcaderon päänsäryksi ja sitten vaan päivität sitä Delphiä vuosittain niin pitäisi toimia.
"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."
Ei se asiakaspää voi sitä valita. Muuten hakkerit tekisi asiakasohjelman mikä käyttäisi aina sitä paskinta protokollaa mikä on murrettu. Tästä artikellista voi olla apua: https://en.wikipedia.org/wiki/Transport_Layer_Security- turhautt_salauskäytäntö
M-Kar :"Ei se asiakaspää voi sitä valita. Muuten hakkerit tekisi asiakasohjelman mikä käyttäisi aina sitä paskinta protokollaa mikä on murrettu. "
Ylläoleva lainaus osoittaa täydellistä ymmärtämättömyyttä salauksen ja autentikointiprotokollien olemassaolon tarkoituksesta!
Tottakai verkkorikollinen voi tehdä asiakasohjelman mikä käyttäisi aina sitä paskinta protokollaa mikä on murrettu.
Mutta niin tekemällä verkkorikollinen pääsee ITSE käyttämään huonoa salausta, jonka voi helposti murtaa.
Toki, jos verkkorikollinen saa tekemänsä huonon ohjelman jotenkin puffattua yleiseen käyttöön useammallekin taholle, silloin verkkorikollinen voisi pyrkiä murtamaan noiden kyseisten huonojen ohjelmien käyttäjien tietoturvan. Tämä toki edellyttää muutakin kuin pelkkää salauksen murtamista, mm. keinon, jolla saisi esim aikaan sen, että kun asiakas verkkorikollisen tekemällä/muokkaamalla ohjelmalla yrittää yhteyttä esim
palvelimeen:
https://www.nordea.fi/
niin verkkorikollisella täytyisi olla myös keino uudelleenohjata tämä:
https://www.rikollistenfeikkinordeasivusto.fi/
toki, jos yrittää käyttää nordean verkkopankkia verkkorikollisen tekemällä/muokkaamalla ohjelmalla, niin silloin kerjää onghelmia itselleen, sillä tekemäänsä ohjelmaan voi tosiaan tehdä muokatun funktion, joka tietyissä tapauksissa (esim. *.nordea.fi ) ohjaa kyselyn pomalle feikkipalvelimelleen, mutta muut osoitteet ratkaistaan ihan julkisen dns:n avulla.
Mutta jos rikollinen EI SAA omaa huijausohjelmistoaan levitettyä laajalti, niin sivullisten verkkopankki-istunnot nordeaan ovat täysin turvassa, jos nordean palvelin hyväksyisi minkä tahansa alunperin turvallisena pidetyn protokollan, jos asiakkkaan selain ilmoittaa, ettei tue uudempia (ja turvallisempia) protokollia.
Tässä ei siis ole tarkoitus se, että rikolliset jakavat tahallaan paskoja ohjelmia, joiden tietoturva on tahallaan väärennetty, vaan mahdollistaa esim. nordean verkkopankin käyttö vaikkapa win98 käyttöjärjestelmällä ja ikivanhalla selaimella (eipä uusista selaimista mikään toimi win98:ssa).
Sopii muuten kysyä miksei !
Eihän mikään pakota selaimen tekijää käyttämään Microsoftin salausprotokollapinoa, kyllä salausprotokollan voi toteuttaa sovellusohjelman omalla koodilla, jolloin se toimii kaikissa käyttöjärjestelmissä.
Ainoa mahdollinen tietoturvaongelma voi syntyä siitä, että vanhojen käyttisten ns. "secure random" -toiminto voi olla tietoturvaton, eli genereoidut satunnaisluvut eivät olekaan ihan niin satunnaisia kuin pitäisi.
Eikös muuten joku vanha debian kärsinyt juuri tuollaisesta ongelmasta ?
M-Karin jakama linkki EI VASTAA kysymykseen:
Miksi sekä OpenSSL että CryptLib joskus epäonnistuvat tiettyyn https -osoitteeseen yhteyden muodostuksessa, vaikka täsmälleen samalla cl32.dll tai openSSL:n vastaavalla yhteyden muodostus johonkin muuhun https -osoitteeseen toimii ihan hyvin ?
Ilmeisesti jotkut palvelimet vaativat vain uusinta tls 1.2 -versiota asiakaspäältä, ja kieltäytyvät yhteistyöstä minkä tahansa muun SSL tai TLS -version kanssa.
Ja joku toinen palvelin (jota ei ole viimeaikoina päivitetty) hyväksyy vain TLS 1.1 -version, eli pitää TLS 1.0:aa tietoturvattomana eikä kelpuuta sitä, mutta sitten itse ei tue TLS 1.2:ta lainkaan !
Tai sitten versioasia on oikein, mutta toteutuksista jompikumpi tai molemmat ei noudata standardia, jolloin esim palvelinpään TLS1.2/OpenSSL ja asiakaspään TLS1.2/Cryptlib eivät suostu yhteistyöhön !
Kun vielä SSL (tai TLS) -sertifikaatin yksityiskohdat voivat vaikuttaa asiaan, niin tilanne on se, että koko salausteknologia on ns. "kokeile ja rukoile" -pohjalla !
Eli johinkin osoitteisiin yhteys toimii ihan ok, toisiin ei toimi, eikä käytetty salaustoteutus (kuten esim. OpenSSL tai Cryptlib) mitenkään kerro, mikä meni pieleen, eli miksi yhteydenmuodostus joihinkin palvelimiin ei onnistunut. - parempaa_salauskoodausta
https://en.wikipedia.org/wiki/Transport_Layer_Security
Tuolta sivulta selviää ainakin YKSI tärkeä asia:
Kopioin tähän vain olennaiset asiat, todella ikivanhathan voi jokainen käydä itse lukemassa ylläolevasta URLista:
TLS 1.1 2006
TLS 1.2 2008
TLS 1.3 2018
Siis TLS 1.0 ja kaikki SSL:t ovat viime vuosituhannelta, joten ne voinee jättää huomiotta.
Salauskirjastojen osalta: Oikein olisi: TLS 1.0 ja kaikki SSL:t ovat koodin puolesta tuettuja, mutta yhteyspyynnön mukana ne pitää erikseen sallia, muuten ne on estetty tietoturvasyistä (niissä on tunnettuja haavoittuvuuksia).
Koska TLS 1.2 on julkaistu jo 2008, voisi olettaa, että KAIKKI 2009 ja sitä myöhemmin julkaistut ohjelmistot (jotka yleensäkään tukevat salattua verkkoliikennettä) tukevat myös TLS 1.2 -versiota !
Herääkin kysymys: Miksi sitten OpenSSL ja Cryptlib uusimmat versiot eivät välttämättä suostu yhteistyöhön Knoppix 7.2:n kanssa (julkaistu 2013, eli 4 vuotta tuon rajana olevan 2009 jälkeen !) ?
Onko protokollan versionumeron lisäksi vielä muitakin syitä, miksi yhteys voi epäonnistua ?
Muistaakseni menee niin, että uusimmat salauskirjastot eivät ole yhteensopivia Knoppix 7.2:n kanssa, ja jos valitsee sen verran vanhemman, että toimii Knoppix 7.2:n kanssa, niin tuollainen vanhempi salauskirjasto taas ei sitten toimi uudempien palvelinten kanssa !
Sitäpaitsi: Eikö olisi parempi AINA käyttää salauskirjaston uusinta versiota? (Tietoturvallisempaa, sekä tuettujen protokollien että mahd. bugikorjausten osalta) ?
Juuri tuosta syystä olisi parempi, että uusinkin salauskirjasto sinänsä tukisi kaikkia (vanhempiakin) salausprotokollia, silloin se, joka tukea noille vanhemmille tarvitsee (mistä tahansa syystä) voisi silti aina käyttää salauskirjaston uusinta versiota.
Jos kerran ainakin osa noista vanhemmista salausprotokollista sisältää tunnettuja haavoittuvuuksia, silloin oikein olisi se, että salauskirjasto oletuksena kieltäytyisi käyttämästä haavoittuvaa (ja vanhentunutta) salausprotokollaa, mutta että yhteyttä muodostettaessa voisi halutessaan määrittää, että haluaa yhteyden joka tapauksessa muodostuvan, vaikka vastapää olisi joku ikivanha joka ei uudempia (ja turvallisempia) protokollia tue.
Tämä pitäisi olla määriteltävissä:
a) jokaisen yhteydenmuodostuksen yhteydessä
b) domain-nimiä ja/tai IP -osoitteita sisältävä lista, johon noita vanhempia protokollia sallitaan
tai
c) sovellus voisi salauskirjaston alustuksen yhteydessä kutsua konfiguraatiofunktiota, jolle parametrina (salli myös vanhemmat protokollat, tai osa niistä).
Mutta se, että yhteydenmuodostus vain epäonnistuu, eikä syystä ole tarkkaa tietoa, eikä myöskään tietoa, mitä tehdä ongelman korjaamiseksi, se on huonoa ohjelmistosuunnittelua.
Miksi salauksista on tehty niin vaikea asia?
Tai siis salaus sinänsä on HELPPO asia, mutta se, että salaus ja siihen liittyvät muut toimet muodostavat standardin mukaisen kokonaisuuden, niin siinä on pahoja yhteensopivuusongelmia.
Eli jos pääsee itse tekemään yhteyden molempiin päihin RSA ja AES -salauksen, siinä ei ole mitään vaikeaa (joskin työtä siinäkin kyllä riittää). Mutta jos pitää toteuttaa salaus niin, että se on standardinmukainen (jolloin se on tai ainakin pitäisi olla yhteensopiva minkä tahansa muun standardia noudattavan ohjelmiston kanssa) niin tuo onkin tehtävä, joka on huomattavasti vaativampi kuin salaus sinänsä!
Herää vain kysymys: kuinka suuri osuus muistakaan ohjelmista on oikeasti 100% standardin mukaisia?
Jos vastaus olisi "kaikki" niin eipä kuvaamiani yhteensopivuusongelmia olisi olemassakaan! parempaa_salauskoodausta kirjoitti:
https://en.wikipedia.org/wiki/Transport_Layer_Security
Tuolta sivulta selviää ainakin YKSI tärkeä asia:
Kopioin tähän vain olennaiset asiat, todella ikivanhathan voi jokainen käydä itse lukemassa ylläolevasta URLista:
TLS 1.1 2006
TLS 1.2 2008
TLS 1.3 2018
Siis TLS 1.0 ja kaikki SSL:t ovat viime vuosituhannelta, joten ne voinee jättää huomiotta.
Salauskirjastojen osalta: Oikein olisi: TLS 1.0 ja kaikki SSL:t ovat koodin puolesta tuettuja, mutta yhteyspyynnön mukana ne pitää erikseen sallia, muuten ne on estetty tietoturvasyistä (niissä on tunnettuja haavoittuvuuksia).
Koska TLS 1.2 on julkaistu jo 2008, voisi olettaa, että KAIKKI 2009 ja sitä myöhemmin julkaistut ohjelmistot (jotka yleensäkään tukevat salattua verkkoliikennettä) tukevat myös TLS 1.2 -versiota !
Herääkin kysymys: Miksi sitten OpenSSL ja Cryptlib uusimmat versiot eivät välttämättä suostu yhteistyöhön Knoppix 7.2:n kanssa (julkaistu 2013, eli 4 vuotta tuon rajana olevan 2009 jälkeen !) ?
Onko protokollan versionumeron lisäksi vielä muitakin syitä, miksi yhteys voi epäonnistua ?
Muistaakseni menee niin, että uusimmat salauskirjastot eivät ole yhteensopivia Knoppix 7.2:n kanssa, ja jos valitsee sen verran vanhemman, että toimii Knoppix 7.2:n kanssa, niin tuollainen vanhempi salauskirjasto taas ei sitten toimi uudempien palvelinten kanssa !
Sitäpaitsi: Eikö olisi parempi AINA käyttää salauskirjaston uusinta versiota? (Tietoturvallisempaa, sekä tuettujen protokollien että mahd. bugikorjausten osalta) ?
Juuri tuosta syystä olisi parempi, että uusinkin salauskirjasto sinänsä tukisi kaikkia (vanhempiakin) salausprotokollia, silloin se, joka tukea noille vanhemmille tarvitsee (mistä tahansa syystä) voisi silti aina käyttää salauskirjaston uusinta versiota.
Jos kerran ainakin osa noista vanhemmista salausprotokollista sisältää tunnettuja haavoittuvuuksia, silloin oikein olisi se, että salauskirjasto oletuksena kieltäytyisi käyttämästä haavoittuvaa (ja vanhentunutta) salausprotokollaa, mutta että yhteyttä muodostettaessa voisi halutessaan määrittää, että haluaa yhteyden joka tapauksessa muodostuvan, vaikka vastapää olisi joku ikivanha joka ei uudempia (ja turvallisempia) protokollia tue.
Tämä pitäisi olla määriteltävissä:
a) jokaisen yhteydenmuodostuksen yhteydessä
b) domain-nimiä ja/tai IP -osoitteita sisältävä lista, johon noita vanhempia protokollia sallitaan
tai
c) sovellus voisi salauskirjaston alustuksen yhteydessä kutsua konfiguraatiofunktiota, jolle parametrina (salli myös vanhemmat protokollat, tai osa niistä).
Mutta se, että yhteydenmuodostus vain epäonnistuu, eikä syystä ole tarkkaa tietoa, eikä myöskään tietoa, mitä tehdä ongelman korjaamiseksi, se on huonoa ohjelmistosuunnittelua.
Miksi salauksista on tehty niin vaikea asia?
Tai siis salaus sinänsä on HELPPO asia, mutta se, että salaus ja siihen liittyvät muut toimet muodostavat standardin mukaisen kokonaisuuden, niin siinä on pahoja yhteensopivuusongelmia.
Eli jos pääsee itse tekemään yhteyden molempiin päihin RSA ja AES -salauksen, siinä ei ole mitään vaikeaa (joskin työtä siinäkin kyllä riittää). Mutta jos pitää toteuttaa salaus niin, että se on standardinmukainen (jolloin se on tai ainakin pitäisi olla yhteensopiva minkä tahansa muun standardia noudattavan ohjelmiston kanssa) niin tuo onkin tehtävä, joka on huomattavasti vaativampi kuin salaus sinänsä!
Herää vain kysymys: kuinka suuri osuus muistakaan ohjelmista on oikeasti 100% standardin mukaisia?
Jos vastaus olisi "kaikki" niin eipä kuvaamiani yhteensopivuusongelmia olisi olemassakaan!"Herääkin kysymys: Miksi sitten OpenSSL ja Cryptlib uusimmat versiot eivät välttämättä suostu yhteistyöhön Knoppix 7.2:n kanssa (julkaistu 2013, eli 4 vuotta tuon rajana olevan 2009 jälkeen !) ?"
Knoppix joku outo, jos nyt käyttäisi käyttöjärjestelmää joita yleensä on tuotannossa. Joku Red Hat Enterprise 5 vuodelta 2007 (jota CentOS 5 vastaa aika pitkälti) lienee vanhin. Mutta käyttöjärjestelmän julkaisupäivä ei varsinaisesti ratkaise, koska käyttöjärjestelmässä olevat kirjastoversiot voivat olla vuosia tätä vanhempia mutta niitä on testattu ja korjattu bugeista pitkään, että saatu varmatoiminen tuote. CentOS 5:sta löytyvä OpenSSL esimerkiksi on vuodelta 2005 oleva 0.9.8 jota on ylläpidetty vakaana ja siihen on tehty tähän samaan versioon, yhteensopivuuksia muuttamatta monia päivityksiä.
"Onko protokollan versionumeron lisäksi vielä muitakin syitä, miksi yhteys voi epäonnistua ?"
Kai siinä voi mennä lukemattomia asioita pieleen, että eihän siinä sitten muuta kuin nostamaan debuggaus leveliä ja jäljittää sen. Minulla ei ole salatun yhteyden kanssa mitään ongelmia. Käytän frameworkin vakioita katsomalla ohjeita.
"Sitäpaitsi: Eikö olisi parempi AINA käyttää salauskirjaston uusinta versiota? (Tietoturvallisempaa, sekä tuettujen protokollien että mahd. bugikorjausten osalta) ?"
Joissakin ympäristöissä halutaan vakaita komponentteja. Esimerkiksi se Red Hat Enterprise 5:n OpenSSL vuodelta 2007 jota ylläpidetään vakaana vuoteen 2020 saakka. Idea siis se, että voidaan rakentaa koodia tuon varaan ettei se mene rikki jonkun päivityksen myötä.turhautt_salauskäytäntö kirjoitti:
M-Kar :"Ei se asiakaspää voi sitä valita. Muuten hakkerit tekisi asiakasohjelman mikä käyttäisi aina sitä paskinta protokollaa mikä on murrettu. "
Ylläoleva lainaus osoittaa täydellistä ymmärtämättömyyttä salauksen ja autentikointiprotokollien olemassaolon tarkoituksesta!
Tottakai verkkorikollinen voi tehdä asiakasohjelman mikä käyttäisi aina sitä paskinta protokollaa mikä on murrettu.
Mutta niin tekemällä verkkorikollinen pääsee ITSE käyttämään huonoa salausta, jonka voi helposti murtaa.
Toki, jos verkkorikollinen saa tekemänsä huonon ohjelman jotenkin puffattua yleiseen käyttöön useammallekin taholle, silloin verkkorikollinen voisi pyrkiä murtamaan noiden kyseisten huonojen ohjelmien käyttäjien tietoturvan. Tämä toki edellyttää muutakin kuin pelkkää salauksen murtamista, mm. keinon, jolla saisi esim aikaan sen, että kun asiakas verkkorikollisen tekemällä/muokkaamalla ohjelmalla yrittää yhteyttä esim
palvelimeen:
https://www.nordea.fi/
niin verkkorikollisella täytyisi olla myös keino uudelleenohjata tämä:
https://www.rikollistenfeikkinordeasivusto.fi/
toki, jos yrittää käyttää nordean verkkopankkia verkkorikollisen tekemällä/muokkaamalla ohjelmalla, niin silloin kerjää onghelmia itselleen, sillä tekemäänsä ohjelmaan voi tosiaan tehdä muokatun funktion, joka tietyissä tapauksissa (esim. *.nordea.fi ) ohjaa kyselyn pomalle feikkipalvelimelleen, mutta muut osoitteet ratkaistaan ihan julkisen dns:n avulla.
Mutta jos rikollinen EI SAA omaa huijausohjelmistoaan levitettyä laajalti, niin sivullisten verkkopankki-istunnot nordeaan ovat täysin turvassa, jos nordean palvelin hyväksyisi minkä tahansa alunperin turvallisena pidetyn protokollan, jos asiakkkaan selain ilmoittaa, ettei tue uudempia (ja turvallisempia) protokollia.
Tässä ei siis ole tarkoitus se, että rikolliset jakavat tahallaan paskoja ohjelmia, joiden tietoturva on tahallaan väärennetty, vaan mahdollistaa esim. nordean verkkopankin käyttö vaikkapa win98 käyttöjärjestelmällä ja ikivanhalla selaimella (eipä uusista selaimista mikään toimi win98:ssa).
Sopii muuten kysyä miksei !
Eihän mikään pakota selaimen tekijää käyttämään Microsoftin salausprotokollapinoa, kyllä salausprotokollan voi toteuttaa sovellusohjelman omalla koodilla, jolloin se toimii kaikissa käyttöjärjestelmissä.
Ainoa mahdollinen tietoturvaongelma voi syntyä siitä, että vanhojen käyttisten ns. "secure random" -toiminto voi olla tietoturvaton, eli genereoidut satunnaisluvut eivät olekaan ihan niin satunnaisia kuin pitäisi.
Eikös muuten joku vanha debian kärsinyt juuri tuollaisesta ongelmasta ?
M-Karin jakama linkki EI VASTAA kysymykseen:
Miksi sekä OpenSSL että CryptLib joskus epäonnistuvat tiettyyn https -osoitteeseen yhteyden muodostuksessa, vaikka täsmälleen samalla cl32.dll tai openSSL:n vastaavalla yhteyden muodostus johonkin muuhun https -osoitteeseen toimii ihan hyvin ?
Ilmeisesti jotkut palvelimet vaativat vain uusinta tls 1.2 -versiota asiakaspäältä, ja kieltäytyvät yhteistyöstä minkä tahansa muun SSL tai TLS -version kanssa.
Ja joku toinen palvelin (jota ei ole viimeaikoina päivitetty) hyväksyy vain TLS 1.1 -version, eli pitää TLS 1.0:aa tietoturvattomana eikä kelpuuta sitä, mutta sitten itse ei tue TLS 1.2:ta lainkaan !
Tai sitten versioasia on oikein, mutta toteutuksista jompikumpi tai molemmat ei noudata standardia, jolloin esim palvelinpään TLS1.2/OpenSSL ja asiakaspään TLS1.2/Cryptlib eivät suostu yhteistyöhön !
Kun vielä SSL (tai TLS) -sertifikaatin yksityiskohdat voivat vaikuttaa asiaan, niin tilanne on se, että koko salausteknologia on ns. "kokeile ja rukoile" -pohjalla !
Eli johinkin osoitteisiin yhteys toimii ihan ok, toisiin ei toimi, eikä käytetty salaustoteutus (kuten esim. OpenSSL tai Cryptlib) mitenkään kerro, mikä meni pieleen, eli miksi yhteydenmuodostus joihinkin palvelimiin ei onnistunut."Tottakai verkkorikollinen voi tehdä asiakasohjelman mikä käyttäisi aina sitä paskinta protokollaa mikä on murrettu."
Niin, siksi ne kelvottomat protokollat kytketään pois palvelimista ja asiakasohjelmassa pitää olla jokin niistä mitä on saatavilla.
"Ilmeisesti jotkut palvelimet vaativat vain uusinta tls 1.2 -versiota asiakaspäältä, ja kieltäytyvät yhteistyöstä minkä tahansa muun SSL tai TLS -version kanssa."
Kyllä vain.
"Ja joku toinen palvelin (jota ei ole viimeaikoina päivitetty) hyväksyy vain TLS 1.1 -version, eli pitää TLS 1.0:aa tietoturvattomana eikä kelpuuta sitä, mutta sitten itse ei tue TLS 1.2:ta lainkaan !"
Kyllä, heikosti ylläpidettyjä palvelimia on myös.
"Tai sitten versioasia on oikein, mutta toteutuksista jompikumpi tai molemmat ei noudata standardia, jolloin esim palvelinpään TLS1.2/OpenSSL ja asiakaspään TLS1.2/Cryptlib eivät suostu yhteistyöhön !"
Mahdollista mutta epätodennäköistä
"Kun vielä SSL (tai TLS) -sertifikaatin yksityiskohdat voivat vaikuttaa asiaan, niin tilanne on se, että koko salausteknologia on ns. "kokeile ja rukoile" -pohjalla !"
Minulla ei ole ollut ongelmia tuon kanssa. Jos teen vaikka Reactilla asiakasohjelman niin kyllä se toimii. Annan aina jonkun frameworkin tai korkean tason rajapinnan hoitaa sotkut. Sinä tunnut yrittävän tehdä sitä itse.- klassinen_sovellusmalli
WinHTTP on se uudempi, joka muuten toimii, mutta https ja POST -yhdistelmä ei toimi.
M-Kar linkkaa toistuvasti .net -systeemin linkkejä Delphi -palstalle, jonne ne eivät kuulu, eli ovat asiatonta sisältöä.
Ainoa Delphi, joka on .net -systeemille tehty, on Delphi 8.
Ikävä kyllä, .net on systeemi, jossa Microsoft tahallaan kehittelee kokoajan uusia versioita ja tappaa vanhoja.
Joten toimiiko Delphi 8:lla tehty .net -sovellus uudemman .net -ajoympäristön kanssa?
Ja mikä on tilanne vaikkapa vuonna 2030 ?
Silloin tällä hetkellä uusin .net -systeemi (jota mikään Delphi -vesrsio ei tue nytkään) on todennäköisesti tuolloin jo vanhentunut, eli ehkä ei edes toimi, ja jos toimii, on Microsftin vanhentuneeksi merkitsemä, eli ei välttämättä toimi kauaa.
Sensijaan Windows API toimii kyllä jatkossakin, poikkeuksena vain ne API -funktiokutsut, joista MSDN:ssä on nimenomainen "deprecated" -maininta.
Ja niitä on hyvin pieni vähemmistö kaikista API -kutsuista.
M-Kar siis toistuvasti häiritsee Delphi -palstaa asiattomalla sisällöllä.
Samat API -kutsut toimivat niin Delphillä kuin C:llä tai C :lla koodatuistakin ohjelmista käsin.
M-Kar: "Jos teen vaikka Reactilla asiakasohjelman niin kyllä se toimii."
Onko React -nimistä ohjelmointikieltä tai -työvälinettä olemassakaan ?
Vai käyttikö M-Kar tässä React -sanaa ReactJS:n lyhenteenä?
Jos kyse oli ReactJS:stä, niin sitähän ajetaan selaimessa.
Ja selaimen käyttö johtaa aina moninkertaiseen RAM -muistinkulutukseen !
esim. 32 -bittisen EXEn ajo 64 -bittisessä Windows -käyttöjärjestelmässä lataa toki WoW64 -apukirjastot muistiin.
MUTTA:
1. WoW64 -apukirjastot ladataan muistiin vain kertaalleen, vaikka ajaisit 100 kpl 32 -bittisiä EXE -ohjelmia yhtäaikaa.
2. Kyseiset WoW64 -apukirjastot kuluttavat RAM -muistia tosiasiassa vain hyvin vähäisen määrän.
Sensijaan nettiselain kuluttaa RAM -muistia tuhottoman paljon, ja mitä useamman ikkunan ja välilehden avaat selaimessa, sitä pahemmaksi tilanne muodostuu.
RAM -muistinkulutuksen lisäksi nettiselain yleensä myös tuhlaa CPU -resursseja esim. siihen, että ns. vilkkuvälkky -mainokset (siis sellaiset, joissa mainossisältönä on jotakin muuta kuin staattinen, eli yksi paikallaan pysyvä kuva), niin muuttuvan mainossisällön (joko video tai javascript -ajastimella tehty härpäke, joka vaihtaa kuvaa muutaman sekunnin välein) kuluttaa CPU -resursseja silloinkin, kun se on sellaisessa ikkunassa tai välilehdessä, joka juuri nyt ei ole näkyvissä, koska jokin toinen ikkuna tai välilehti on edustalla.
Ylläolevia tosiasioita M-Kar ei halua hyväksyä eikä tunnustaa, vaan hän haluaa ajaa omaa Delphi -vastaista agendaansa.
Oikeastaan yksikään Delphillä tai edes FreePascal Lazarus -yhdistelmällä koodattu sovellus ei ole haitannut tietokoneenkäyttöäni mitenkään.
Sensijaan nettiselain haittaa jatkuvasti kuluttamalla liikaa koneen RAM -muistia sekä CPU -aikaa.
Ei toisaalta ole ihme, sillä nettiselaimet on yleensä koodattu "C " -kielellä, ja jo kieli itse on sekava, ja sen käyttäjät eivät useinkaan ole sieltä fiksuimmasta päästä.
tuo .net -systeemin jatkuva päivittäminen on Microsoftin tapa epäreiluun kilpailuun ensin Borlandia ja sittemmin Embarcaderoa vastaan.
Vain joko idiootti tai RAM -muistia valmistavan yrityksen suurosakkeenomistaja siirtää kaiken nettiselaimen avulla toimivaksi. klassinen_sovellusmalli kirjoitti:
WinHTTP on se uudempi, joka muuten toimii, mutta https ja POST -yhdistelmä ei toimi.
M-Kar linkkaa toistuvasti .net -systeemin linkkejä Delphi -palstalle, jonne ne eivät kuulu, eli ovat asiatonta sisältöä.
Ainoa Delphi, joka on .net -systeemille tehty, on Delphi 8.
Ikävä kyllä, .net on systeemi, jossa Microsoft tahallaan kehittelee kokoajan uusia versioita ja tappaa vanhoja.
Joten toimiiko Delphi 8:lla tehty .net -sovellus uudemman .net -ajoympäristön kanssa?
Ja mikä on tilanne vaikkapa vuonna 2030 ?
Silloin tällä hetkellä uusin .net -systeemi (jota mikään Delphi -vesrsio ei tue nytkään) on todennäköisesti tuolloin jo vanhentunut, eli ehkä ei edes toimi, ja jos toimii, on Microsftin vanhentuneeksi merkitsemä, eli ei välttämättä toimi kauaa.
Sensijaan Windows API toimii kyllä jatkossakin, poikkeuksena vain ne API -funktiokutsut, joista MSDN:ssä on nimenomainen "deprecated" -maininta.
Ja niitä on hyvin pieni vähemmistö kaikista API -kutsuista.
M-Kar siis toistuvasti häiritsee Delphi -palstaa asiattomalla sisällöllä.
Samat API -kutsut toimivat niin Delphillä kuin C:llä tai C :lla koodatuistakin ohjelmista käsin.
M-Kar: "Jos teen vaikka Reactilla asiakasohjelman niin kyllä se toimii."
Onko React -nimistä ohjelmointikieltä tai -työvälinettä olemassakaan ?
Vai käyttikö M-Kar tässä React -sanaa ReactJS:n lyhenteenä?
Jos kyse oli ReactJS:stä, niin sitähän ajetaan selaimessa.
Ja selaimen käyttö johtaa aina moninkertaiseen RAM -muistinkulutukseen !
esim. 32 -bittisen EXEn ajo 64 -bittisessä Windows -käyttöjärjestelmässä lataa toki WoW64 -apukirjastot muistiin.
MUTTA:
1. WoW64 -apukirjastot ladataan muistiin vain kertaalleen, vaikka ajaisit 100 kpl 32 -bittisiä EXE -ohjelmia yhtäaikaa.
2. Kyseiset WoW64 -apukirjastot kuluttavat RAM -muistia tosiasiassa vain hyvin vähäisen määrän.
Sensijaan nettiselain kuluttaa RAM -muistia tuhottoman paljon, ja mitä useamman ikkunan ja välilehden avaat selaimessa, sitä pahemmaksi tilanne muodostuu.
RAM -muistinkulutuksen lisäksi nettiselain yleensä myös tuhlaa CPU -resursseja esim. siihen, että ns. vilkkuvälkky -mainokset (siis sellaiset, joissa mainossisältönä on jotakin muuta kuin staattinen, eli yksi paikallaan pysyvä kuva), niin muuttuvan mainossisällön (joko video tai javascript -ajastimella tehty härpäke, joka vaihtaa kuvaa muutaman sekunnin välein) kuluttaa CPU -resursseja silloinkin, kun se on sellaisessa ikkunassa tai välilehdessä, joka juuri nyt ei ole näkyvissä, koska jokin toinen ikkuna tai välilehti on edustalla.
Ylläolevia tosiasioita M-Kar ei halua hyväksyä eikä tunnustaa, vaan hän haluaa ajaa omaa Delphi -vastaista agendaansa.
Oikeastaan yksikään Delphillä tai edes FreePascal Lazarus -yhdistelmällä koodattu sovellus ei ole haitannut tietokoneenkäyttöäni mitenkään.
Sensijaan nettiselain haittaa jatkuvasti kuluttamalla liikaa koneen RAM -muistia sekä CPU -aikaa.
Ei toisaalta ole ihme, sillä nettiselaimet on yleensä koodattu "C " -kielellä, ja jo kieli itse on sekava, ja sen käyttäjät eivät useinkaan ole sieltä fiksuimmasta päästä.
tuo .net -systeemin jatkuva päivittäminen on Microsoftin tapa epäreiluun kilpailuun ensin Borlandia ja sittemmin Embarcaderoa vastaan.
Vain joko idiootti tai RAM -muistia valmistavan yrityksen suurosakkeenomistaja siirtää kaiken nettiselaimen avulla toimivaksi."WinHTTP on se uudempi, joka muuten toimii, mutta https ja POST -yhdistelmä ei toimi."
WinHTTP on vanhaa kuraa. Jotain C aikaista.
"M-Kar linkkaa toistuvasti .net -systeemin linkkejä Delphi -palstalle, jonne ne eivät kuulu, eli ovat asiatonta sisältöä."
Kyse oli Windowsista. Windowsia ohjelmoidaan natiivisti .NET:llä. Älä kysy Windowsista Delphi palstalla jos et halua keskustella miten Windowsia ohjelmoidaan.
Delphi on kolmannen osapuolen viritelmä mikä ei Microsoftia kiinnosta. Saa sitä toki käyttää mutta silloin pitää ymmärtää se, että Embarcadero hoitaa ne perusjutut alustan kanssa. Koska Windows muuttuu pari kertaa vuodessa niin se on Embarcaderon asia hoitaa huolehtia tämän hetkisen Windowsin kanssa toimiva yhteensopivuus.
Tässä ohje: http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Using_an_HTTP_Client
"Ikävä kyllä, .net on systeemi, jossa Microsoft tahallaan kehittelee kokoajan uusia versioita ja tappaa vanhoja."
Microsoft tappaa tarkoituksellisesti kaikkia vanhoja virityksiä pois ja siirtää kaikki nykyaikaan ja on tehnyt näin aina.. Nykyaikaa on HTML5, WinRT (.NET Standard) ja kauas tulevaisuuteen toimii myös laajempi .NET 4.x ja Visual C Redistributable 2015
"Joten toimiiko Delphi 8:lla tehty .net -sovellus uudemman .net -ajoympäristön kanssa?"
Delphi 8 on vanha. Päivitä se nyt ensialkuun Delphi 10.2 Tokyo versioon mihin se ohjekin on. Muista että sinun pitää päivittää sitä Delphiä suunnilleen vuosittain koska Embercadero ei hyysää noita vanhoja ja Microsoft päivittää Windowsia pari kertaa vuodessa. Kuten annat ymmärtää niin Delphillä on ongelmia käyttää Windowsin vakiota .NET rajapintaa niin sinun pitää saada varmistettua se yhteentoimivuus siihen muuttuvaan Windowsiin.
"Silloin tällä hetkellä uusin .net -systeemi (jota mikään Delphi -vesrsio ei tue nytkään) on todennäköisesti tuolloin jo vanhentunut, eli ehkä ei edes toimi, ja jos toimii, on Microsftin vanhentuneeksi merkitsemä, eli ei välttämättä toimi kauaa."
Voi olla mutta epästabiilit C ja C rajapinnat voivat saada muutoksia kahdesti vuodessa ja rikkoa ohjelman. Delphillä kun on ongelmia sen .NET:n kanssa niin siinä on jotain viritelmiä tehtynä ja niiden ylläpitäminen toimivana tarkoittaa sitä, että sinä päivität sitä Delphiä vuosittain. .NET 4.x toimii muuttumattomana vähintään 10v eteenpäin, että se on iso helpotus tässä asiassa.
"Sensijaan Windows API toimii kyllä jatkossakin, poikkeuksena vain ne API -funktiokutsut, joista MSDN:ssä on nimenomainen "deprecated" -maininta."
Älä puhu paskaa, lopeta se valehtelu nyt heti. Windows API ollut AINA versioriippuvainen Windowsin version kanssa. Windowsin version muuttui ennen 3v välein, aina uuden Windowsin ilmestyessä. Nyt uusi versio Windowsista ja Windows API:n muutos on KAHDESTI VUODESSA.
Siksi kun tekee Delphillä ohjelmia, tehdään se riippuvuus siihen Delphiin ja annetaan Embercaderon hoitaa se ylläpito ja yhteentoimivuuden varmistus, eli uusitaan Delphiä kerta vuoteen.
"M-Kar siis toistuvasti häiritsee Delphi -palstaa asiattomalla sisällöllä."
Sinähän se tässä alat selittämään valheita jostain Windows API:n toimivuudesta ikuisuuksiin. Lopeta se valehtelu tai poistu palstalla häiriköimästä asiattomalla sisällöllä.
"Samat API -kutsut toimivat niin Delphillä kuin C:llä tai C :lla koodatuistakin ohjelmista käsin."
Ja ne C tai C ohjelmat rikkoutuvat niin ikään myös jos riippuvuus Windows API:ssa. Microsoft tarjoaa ABI yhteensopivuuden Visual C redistributable versioihin jokaiselle vähintään 10v ajaksi.
"Ja selaimen käyttö johtaa aina moninkertaiseen RAM -muistinkulutukseen !"
Lopeta se valehtelu. Windowsissa on nykyisin aina selainkomponentti käynnissä ja se on jaettuna kaikille sovelluksille joten todellisuudessa sovelluksen muistinkulutus on mitättömän pieni.
"esim. 32 -bittisen EXEn ajo 64 -bittisessä Windows -käyttöjärjestelmässä lataa toki WoW64 -apukirjastot muistiin."
Kunnes poistavat ne.
"1. WoW64 -apukirjastot ladataan muistiin vain kertaalleen, vaikka ajaisit 100 kpl 32 -bittisiä EXE -ohjelmia yhtäaikaa."
Tietysti. Sama pätee selaimen kanssa. Selainkomponentti sen sijaan on aina käynnissä mutta 32-bittisiä legacy juttuja yleensä ei ole.klassinen_sovellusmalli kirjoitti:
WinHTTP on se uudempi, joka muuten toimii, mutta https ja POST -yhdistelmä ei toimi.
M-Kar linkkaa toistuvasti .net -systeemin linkkejä Delphi -palstalle, jonne ne eivät kuulu, eli ovat asiatonta sisältöä.
Ainoa Delphi, joka on .net -systeemille tehty, on Delphi 8.
Ikävä kyllä, .net on systeemi, jossa Microsoft tahallaan kehittelee kokoajan uusia versioita ja tappaa vanhoja.
Joten toimiiko Delphi 8:lla tehty .net -sovellus uudemman .net -ajoympäristön kanssa?
Ja mikä on tilanne vaikkapa vuonna 2030 ?
Silloin tällä hetkellä uusin .net -systeemi (jota mikään Delphi -vesrsio ei tue nytkään) on todennäköisesti tuolloin jo vanhentunut, eli ehkä ei edes toimi, ja jos toimii, on Microsftin vanhentuneeksi merkitsemä, eli ei välttämättä toimi kauaa.
Sensijaan Windows API toimii kyllä jatkossakin, poikkeuksena vain ne API -funktiokutsut, joista MSDN:ssä on nimenomainen "deprecated" -maininta.
Ja niitä on hyvin pieni vähemmistö kaikista API -kutsuista.
M-Kar siis toistuvasti häiritsee Delphi -palstaa asiattomalla sisällöllä.
Samat API -kutsut toimivat niin Delphillä kuin C:llä tai C :lla koodatuistakin ohjelmista käsin.
M-Kar: "Jos teen vaikka Reactilla asiakasohjelman niin kyllä se toimii."
Onko React -nimistä ohjelmointikieltä tai -työvälinettä olemassakaan ?
Vai käyttikö M-Kar tässä React -sanaa ReactJS:n lyhenteenä?
Jos kyse oli ReactJS:stä, niin sitähän ajetaan selaimessa.
Ja selaimen käyttö johtaa aina moninkertaiseen RAM -muistinkulutukseen !
esim. 32 -bittisen EXEn ajo 64 -bittisessä Windows -käyttöjärjestelmässä lataa toki WoW64 -apukirjastot muistiin.
MUTTA:
1. WoW64 -apukirjastot ladataan muistiin vain kertaalleen, vaikka ajaisit 100 kpl 32 -bittisiä EXE -ohjelmia yhtäaikaa.
2. Kyseiset WoW64 -apukirjastot kuluttavat RAM -muistia tosiasiassa vain hyvin vähäisen määrän.
Sensijaan nettiselain kuluttaa RAM -muistia tuhottoman paljon, ja mitä useamman ikkunan ja välilehden avaat selaimessa, sitä pahemmaksi tilanne muodostuu.
RAM -muistinkulutuksen lisäksi nettiselain yleensä myös tuhlaa CPU -resursseja esim. siihen, että ns. vilkkuvälkky -mainokset (siis sellaiset, joissa mainossisältönä on jotakin muuta kuin staattinen, eli yksi paikallaan pysyvä kuva), niin muuttuvan mainossisällön (joko video tai javascript -ajastimella tehty härpäke, joka vaihtaa kuvaa muutaman sekunnin välein) kuluttaa CPU -resursseja silloinkin, kun se on sellaisessa ikkunassa tai välilehdessä, joka juuri nyt ei ole näkyvissä, koska jokin toinen ikkuna tai välilehti on edustalla.
Ylläolevia tosiasioita M-Kar ei halua hyväksyä eikä tunnustaa, vaan hän haluaa ajaa omaa Delphi -vastaista agendaansa.
Oikeastaan yksikään Delphillä tai edes FreePascal Lazarus -yhdistelmällä koodattu sovellus ei ole haitannut tietokoneenkäyttöäni mitenkään.
Sensijaan nettiselain haittaa jatkuvasti kuluttamalla liikaa koneen RAM -muistia sekä CPU -aikaa.
Ei toisaalta ole ihme, sillä nettiselaimet on yleensä koodattu "C " -kielellä, ja jo kieli itse on sekava, ja sen käyttäjät eivät useinkaan ole sieltä fiksuimmasta päästä.
tuo .net -systeemin jatkuva päivittäminen on Microsoftin tapa epäreiluun kilpailuun ensin Borlandia ja sittemmin Embarcaderoa vastaan.
Vain joko idiootti tai RAM -muistia valmistavan yrityksen suurosakkeenomistaja siirtää kaiken nettiselaimen avulla toimivaksi."tuo .net -systeemin jatkuva päivittäminen on Microsoftin tapa epäreiluun kilpailuun ensin Borlandia ja sittemmin Embarcaderoa vastaan."
Ei ole mitään epäreilua missään. Embarcadero saa vapaasti muuttaa työkalunsa käyttämään standardia HTML5:sta, saa vapaasti kääntää koodin .NET:lle tai saa vapaasti tehdä oman käyttöjärjestelmän. Ei kukaan estä.
Se mitä et käsitä on se, että kaikki 32-bit kura ja Windows API riippuvaisuus on tappolistalla ja Windows API on versioriippuvaista joten kun Embercaderon työkalu sisältää riippuvuuksia Windows API:n niin sitä pitää noin vuosittain että ollaan Embercaderon tuen piirissä ja Embercadero hyysää sitten tarjoamiensa rajapintojen toimivuuden jatkuvasti muuttuvan Windowsin kanssa.
Joten lopeta siis asiattomat viestit Windowsin API:n toimivuudesta ikuisesti, päivitä Delphi versioon 10.2 ja sitten tämän ohjeen mukaisesti: http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Using_an_HTTP_Client
"Vain joko idiootti tai RAM -muistia valmistavan yrityksen suurosakkeenomistaja siirtää kaiken nettiselaimen avulla toimivaksi."
HTML5 on standardi. Juuri äsken lässytät epäreilusta kilpailusta vaikka standardi on olemassa joten kaikki ovat samalla viivalla.
Se on Embarcaderon ongelma jos heidän työkalunsa ei noudata virallisia standardeja.- oikea_osaaja
M-Kar kirjoitti:
"Herääkin kysymys: Miksi sitten OpenSSL ja Cryptlib uusimmat versiot eivät välttämättä suostu yhteistyöhön Knoppix 7.2:n kanssa (julkaistu 2013, eli 4 vuotta tuon rajana olevan 2009 jälkeen !) ?"
Knoppix joku outo, jos nyt käyttäisi käyttöjärjestelmää joita yleensä on tuotannossa. Joku Red Hat Enterprise 5 vuodelta 2007 (jota CentOS 5 vastaa aika pitkälti) lienee vanhin. Mutta käyttöjärjestelmän julkaisupäivä ei varsinaisesti ratkaise, koska käyttöjärjestelmässä olevat kirjastoversiot voivat olla vuosia tätä vanhempia mutta niitä on testattu ja korjattu bugeista pitkään, että saatu varmatoiminen tuote. CentOS 5:sta löytyvä OpenSSL esimerkiksi on vuodelta 2005 oleva 0.9.8 jota on ylläpidetty vakaana ja siihen on tehty tähän samaan versioon, yhteensopivuuksia muuttamatta monia päivityksiä.
"Onko protokollan versionumeron lisäksi vielä muitakin syitä, miksi yhteys voi epäonnistua ?"
Kai siinä voi mennä lukemattomia asioita pieleen, että eihän siinä sitten muuta kuin nostamaan debuggaus leveliä ja jäljittää sen. Minulla ei ole salatun yhteyden kanssa mitään ongelmia. Käytän frameworkin vakioita katsomalla ohjeita.
"Sitäpaitsi: Eikö olisi parempi AINA käyttää salauskirjaston uusinta versiota? (Tietoturvallisempaa, sekä tuettujen protokollien että mahd. bugikorjausten osalta) ?"
Joissakin ympäristöissä halutaan vakaita komponentteja. Esimerkiksi se Red Hat Enterprise 5:n OpenSSL vuodelta 2007 jota ylläpidetään vakaana vuoteen 2020 saakka. Idea siis se, että voidaan rakentaa koodia tuon varaan ettei se mene rikki jonkun päivityksen myötä.M-Kar:"Kai siinä voi mennä lukemattomia asioita pieleen, että eihän siinä sitten muuta kuin nostamaan debuggaus leveliä ja jäljittää sen. Minulla ei ole salatun yhteyden kanssa mitään ongelmia. Käytän frameworkin vakioita katsomalla ohjeita."
Tässä viitataan debuggaus leveliin antamatta tarkempia ohjeita - ei hyvä !
Kas näin:
Linuxissa komentoriviltä:
openssl s_client -help
ja sitten:
Sitten vain komentoja, joilla testataan, tukeeko palvelinpää TLS:n versioita:
1, 1.1, 1.2, ja tulevaisuudessa 1.3:
openssl s_client -connect 192.168.0.1:443 -tls1
openssl s_client -connect 192.168.0.1:443 -tls1_1
openssl s_client -connect 192.168.0.1:443 -tls1_2
ja, jos ja kun openssl:stä ilmestyy versio, joka tukee TLS 1.3:a, niin myös:
openssl s_client -connect 192.168.0.1:443 -tls1_3
Riittävän vanhalla openssl:llä voisi ehkä testata myös, tukeeko palvelinpää SSL:n versioita.
Uudehkossa optio -help ei paljasta mitään optiota, joka yrittäisi salattua yhteyttä vanhemmalla
SSL -versiolla eli TLS:n edeltäjällä.
Toki, jos kaikki palvelimet on päivitetty niin, että tukevat uudempaa TLS:ää, silloin ei tuolle
ikivanhalle SSL:lle pitäisi olla edes tarvetta.
Mutta jos vielä jostain löytyy palvelin, joka tukee vain SSL:ää, muttei TLS:ää,
tuonkin testaaminen olisi hyvä olla mahdollista.
Mutta liian uuden openssl:n -help -optio ei paljasta, miten tuota voisi testata. Ehkä ei mitenkään?
Kun linuxin komentoriviltä on selvitetty, mitä versioita salausprotokollista palvelinpää tukee, on asiaa helpompi hallita asiakaspään osalta. - oikea_osaaja
oikea_osaaja kirjoitti:
M-Kar:"Kai siinä voi mennä lukemattomia asioita pieleen, että eihän siinä sitten muuta kuin nostamaan debuggaus leveliä ja jäljittää sen. Minulla ei ole salatun yhteyden kanssa mitään ongelmia. Käytän frameworkin vakioita katsomalla ohjeita."
Tässä viitataan debuggaus leveliin antamatta tarkempia ohjeita - ei hyvä !
Kas näin:
Linuxissa komentoriviltä:
openssl s_client -help
ja sitten:
Sitten vain komentoja, joilla testataan, tukeeko palvelinpää TLS:n versioita:
1, 1.1, 1.2, ja tulevaisuudessa 1.3:
openssl s_client -connect 192.168.0.1:443 -tls1
openssl s_client -connect 192.168.0.1:443 -tls1_1
openssl s_client -connect 192.168.0.1:443 -tls1_2
ja, jos ja kun openssl:stä ilmestyy versio, joka tukee TLS 1.3:a, niin myös:
openssl s_client -connect 192.168.0.1:443 -tls1_3
Riittävän vanhalla openssl:llä voisi ehkä testata myös, tukeeko palvelinpää SSL:n versioita.
Uudehkossa optio -help ei paljasta mitään optiota, joka yrittäisi salattua yhteyttä vanhemmalla
SSL -versiolla eli TLS:n edeltäjällä.
Toki, jos kaikki palvelimet on päivitetty niin, että tukevat uudempaa TLS:ää, silloin ei tuolle
ikivanhalle SSL:lle pitäisi olla edes tarvetta.
Mutta jos vielä jostain löytyy palvelin, joka tukee vain SSL:ää, muttei TLS:ää,
tuonkin testaaminen olisi hyvä olla mahdollista.
Mutta liian uuden openssl:n -help -optio ei paljasta, miten tuota voisi testata. Ehkä ei mitenkään?
Kun linuxin komentoriviltä on selvitetty, mitä versioita salausprotokollista palvelinpää tukee, on asiaa helpompi hallita asiakaspään osalta.vielä:
JOS testauksen kohteena onkin SSH eikä HTTPS, silloin muuten sama, mutta porttiin 22 eikä 443:
openssl s_client -connect 192.168.0.1:22 -tls1_2
- webblaster
Asian offtopic:
"Windowsissa on nykyisin aina selainkomponentti käynnissä ja se on jaettuna kaikille sovelluksille joten todellisuudessa sovelluksen muistinkulutus on mitättömän pieni."
Tämän kyllä huomaa työpaikan koneessa jotenkin (Windows 10 Enterprise), olen aina epäillyt tätä. Esim. Outlook on täysin juntturassa jos sattuu tulemaan vähänkään isompi viesti sähköpostiin. Työpaikalla on monia sähköposti-tilejä käytössä ja niihin tulee joskus massiivisesti viestejä. Kyllä se vain jotenkin wanhaan hyvään aikaan, kun muistelee vaikka Windows 98/XP aikaa, niin sovellukset oli paljon ripeämpiä tuntumaltaan."Tämän kyllä huomaa työpaikan koneessa jotenkin (Windows 10 Enterprise), olen aina epäillyt tätä. Esim. Outlook on täysin juntturassa jos sattuu tulemaan vähänkään isompi viesti sähköpostiin. Työpaikalla on monia sähköposti-tilejä käytössä ja niihin tulee joskus massiivisesti viestejä. Kyllä se vain jotenkin wanhaan hyvään aikaan, kun muistelee vaikka Windows 98/XP aikaa, niin sovellukset oli paljon ripeämpiä tuntumaltaan."
Ei tuo liity mitenkään selainkomponenttiin. Jos jokin jumittaa niin varmaan kannattaa selvittää miksi jumittaa ja jos jotain dataa siirtyy jossain niin laskee mitä sen pitäisi viedä aikaa. Sovellukset ovat toimineet ripeästi kaiken aikaa.
Outlook on muuten käyttänyt selainkomponenttia vuodesta 1998 lähtien. Oli siis kaiken aikaa niissä Windows 98 ja XP koneissa.- webblaster
Kyse lähinnä siitä ettei Outlook (ja vastaavat) Windows sovellukset säikeisty hyvin, koko Outlook jumittaa jos sattuu klikkaamaan viestiä missä massiivisesti tavaraa, sama homma Excelissä (isot tiedostot ja tietyt toiminnot jumittaa, esim. etsi) jne.. Eli varmasti samaa JavaScript tekniikkaa niissä on nykyään taustalla kuin web-sovelluksissa. Toki sen ymmärrä että vanhassa Outlookissa täytyy olla selain-tekniikkaa jos html-muodossa viestit halutaan esitettävän.
- webblaster
Lienekkö uusi Windows 10 itsessään jo pelkkä "selain", siinä se käyttöliittymän UI?
webblaster kirjoitti:
Kyse lähinnä siitä ettei Outlook (ja vastaavat) Windows sovellukset säikeisty hyvin, koko Outlook jumittaa jos sattuu klikkaamaan viestiä missä massiivisesti tavaraa, sama homma Excelissä (isot tiedostot ja tietyt toiminnot jumittaa, esim. etsi) jne.. Eli varmasti samaa JavaScript tekniikkaa niissä on nykyään taustalla kuin web-sovelluksissa. Toki sen ymmärrä että vanhassa Outlookissa täytyy olla selain-tekniikkaa jos html-muodossa viestit halutaan esitettävän.
"Kyse lähinnä siitä ettei Outlook (ja vastaavat) Windows sovellukset säikeisty hyvin, koko Outlook jumittaa jos sattuu klikkaamaan viestiä missä massiivisesti tavaraa, sama homma Excelissä (isot tiedostot ja tietyt toiminnot jumittaa, esim. etsi) jne."
Ei ole havaintoja minulla jumittamisessa Outlookissa. Excelin saa ainakin jumittamaan väärinkäytettynä. Pitää ymmärtää sen olevan taulukkolaskin ja käytännössä se laskettava asia näkyy ruudulla. Sitä ei varmaankaan ole edes mahdollista säikeistää kun se on sellainen yksi matriisi missä laskenta tehdään.
Outlookin jumittaminen voi myös liittyä väärinkäyttöön. Joissakin yritysten postipalvelimissa on väännetty liitetiedostojen koko johonkin 200 megaan ja sitten on jotain kymmenien gigojen laatikoita ja porukka käyttää sähköpostia tiedostojen lähettämiseen.
Sähköpostia ei ole tarkoitettu isojen tiedostojen lähettämiseen. Yleisesti ottaen yhden sähköpostiviestin kaikkien liitteiden koko pitäisi mennä alle kymmeneen megatavuun nykypäivänä. Ei siinä pitäisi mitään jumittamista olla.
90-luvulla oli tiukemmat rajoitteet, että liitetiedostot oli tavallisesti maksimissaan 250kt yhteensä. Tyypillisesti sähköpostit olivat tekstiä ja kuva oli esim. 30kt.
Siinä on melkoinen ero siihen jos jossain käytetään sähköpostia johonkin 200 megan tiedostojen siirtoon.
Eli siis käyttämällä tekniikkaa kuten on tarkoitettu, ei ole mitään jumittamisia missään. Ei ollut ennen eikä nyt.webblaster kirjoitti:
Lienekkö uusi Windows 10 itsessään jo pelkkä "selain", siinä se käyttöliittymän UI?
Selainkomponentti ja sitten myös natiivirajapinta, WinRT.
Taaksepäinyhteensopivuus syistä johtuen on myös Visual C redistributable 2010 ja uudemmat, DirectX 10 ja uudemmat, .NET 4.x toimivat erittäin hyvin.
Visual C redistributable 2008 ja .NET 2.0-3.5 yhteensopivuuslupaukset umpeutuvat tänä kesänä, mikä tarkoittaa sitä että ne voi aikaisintaan poistua ensi syksyn Windowsissa. Windows 10 1803 on mahdollista jäädyttää ensi syksyllä vuodeksi eteenpäin, että worst case scenaariossa ensi vuoden keväällä nuo voi olla pysyvästi rikki. Riippuu nyt ihan Microsoftista että onko niistä miten paljon harmia kun siivoilevat sotkuja.
Mutta se Delphi sitten, Embarcadero hoitaa sen, joka vuosi uusi Delphi niin he sitten nysväilevät sitä yhteensopivaksi ja siinä tavallaan ulkoistetaan se framework ylläpito Embarcaderolle jos ei halua käyttää näitä Microsoftin vakaita rajapintoja kuten .NET 4.x:ää tai standardia HTML5:sta.- webblaster
Tarkoitan tilannetta kun vasemmalla puolen näkymässä on viestilistaus, niin jos siitä listauksesta klikkaa viestiä auki, miksei siinä viesti-näkymässä (ja vaikka otsikossa) voisi pyöriä jonkin näköinen lataus-rinkula, ettei koko Outlook mene lukkoon? Eli miksi ei voi säikeistää paremmin, luulisi tuon olevan teknisesti mahollista kun ennenkin ollut mahollista.
Outlook on jumissa esim. siinä tapauksessa että viesti on html-muodossa noin megan kokoisena, sisältäen vaikka raportin taulukkona html-muodossa. Varsinaisesti liitteenä se ei jumita Outlookia. Saman raportin avaamalla mihin tahansa selaimeen on täysin kevyttä kauraa.
Minusta vaan outoa että kun tekniikka kehittyy, ei tämmöisen tietomäärien pitäisi jumiuttaa ohjelmia ihan täysin, ammattikäytössä tietomäärät on joskus vaan aika isoja. - taso_vaihtelee
Jollain isoilla tekijöillä varmaan onkin toimipisteiden välillä kuitua ja gigatavun tiedosto liikahtaa vielä reilusti alta minuutissa. Pienemmillä firmoilla ei tällaisia kaistoja ole edes sisäverkossa välttämättä käytössä, jolloin homma ei pelitä. Asian huomaa siirtymällä isosta firmasta pienempään tai pienestä firmasta isompaan: Käytännöt vaihtelee, miten asiaan suhtaudutaan ja mikä on se oikea tapa toimia.
Ketjusta on poistettu 0 sääntöjenvastaista viestiä.
Luetuimmat keskustelut
Poliisitehtävä alkuviikosta Maisan kotona
Iltasanomat: Helsingin poliisilaitos vahvistaa, että Vantaalla on ollut poliisitehtävä kyseisenä ajankohtana. Poliisin862048Tämä on sinulle vaikka kaikki lukee
Vaikka kuinka olet viisas ja kaikin puolin velho, niin et tiedä tilanteestani. Senkin takia menetät mielenkiinnon. Eikä111662- 1021152
Lulu selvityttää Elokapinan lakkautusta
Persukannattajien mielistely otti Lulu Ranteella aika tavalla runtua, kun hän aikoo selvityttää mahdollisuuksia Elokapin3501126Ensitreffit Matti joutuu "ulkoruokintaan" - Väärinymmärrysten suossa Taina-vaimon kanssa: "Oli..."
No nyt on kyllä väärinymmärrystä kerrakseen… Mitä luulet, pysyykö Taina ja Matti yhdessä vai onko tulevaisuudessa ero ed31113Harmi, kun sillä nousi
kaikki huomio päähän. Vaikutti aluksi niin mukavalta ja vaatimattomalta 😔53851Täytyy sanoa
Että olit kyllä mielenkiintoisin ja omaperäisin nainen mitä olen koskaan tavannut. Aivan kuin joku olisi tiputtanut sinu21839Miten saisin
Hurmattua sinut uudelleen,? Pissin omiin muroihini ensinmäisellä kerralla koska olin tyhmä ja liiaksi kiinni menneess31777Persu Meri Valkama kadehtii Sanna Marinin menestystä
Taas yksi persu tuli nolaamaan itsensä kadehtiessaan menestynyttä Suomen kansan supertähteä Sanna Marinia. https://demo237737Raamatun tärkein lause
Ja Mooses tuli alas vuorilta missä jumala oli, Mooseksen mukaan, ilmoittanut hänelle, että hän ja koko juutalainen väki,367719