Miksi ammattilaisten nettisivut ovat niin paskoja?

Sinä olet tässä ihan toisen käyttäjän mutuilun varassa. Tuosta toimimattomuudesta ei ole tehty mitään tarkkaa analyysiä. Se voi johtua ihan vaan jostain yksittäisestä bugista selaimessa ja olla täysin tuon selaimen ja sen nykyisen version vika.
Totta. Olen kuitenkin törmännyt vastaaviin ongelmiin ajantasaisen Firefox ESR:n kanssa, kun jokin sivusto on nyt vain päättänyt ettei niille pääse kuin "uusimmilla" selainversioilla. ESR on LTS, eli ei sitä uusinta uutta bugeineen, mutta tietoturvapäivitykset pitäisi olla kunnossa.

Ihan jo palvelinten TLS-versio käytännössä rajaa pois museolaitteet ja -selaimet. Organisaatioiden pitäisi näitä varten rakentaa jotain HTTPS:n pois riisuvia MITM-proxyjä, jotta voisi testata myös vaikkapa 8-bittiset kotimikrot, jotka on kytketty proxyyn sarjalinkin yli.
Se on selaimen ongelma tukeeko se näitä rajapintoja tai muita kilkkeitä. En vaadi, että sivustojen pitäisi tarjota salaamatonta http:tä tai ottaa Lynxin käyttäjät huomioon. Kunhan niitä ei etukäteen estetä.

Olisihan se toivottavaa, että viranomaisten sivut toimisivat myös 16-bittisellä lynx 1.0:lla, jota ajetaan OS/2 Warpilla DOS-ikkunassa ja merkistönä on koodisivu 1004. Protokollina voisi olla Gopher ja FTP. Nämä ovat kuitenkin täysin päteviä viranomaisasiointiin.
Mielestäni viranomaissivuja pitäisi todella voida lukea vaikka OS/2 Warpin selaimella. Kuten tässäkin ketjussa joku kirjoitti, Trafin sivut ovat nykyään täynnä JS-valikkoja, ettei hakukoneetkaan osaa indeksoida niitä. Se on kansalaisten tiedonsaannin kannalta melko surkeaa toimintaa. Varsinainen asiointi tietysti vaatii salattua yhteyttä.
 
Totta. Olen kuitenkin törmännyt vastaaviin ongelmiin ajantasaisen Firefox ESR:n kanssa, kun jokin sivusto on nyt vain päättänyt ettei niille pääse kuin "uusimmilla" selainversioilla. ESR on LTS, eli ei sitä uusinta uutta bugeineen, mutta tietoturvapäivitykset pitäisi olla kunnossa.
Joo, tämä on iso epäkohta, koska tuo ESR on monessa paikassa käytössä ja käyttäjillä ei ole mahdollisuutta välttämättä tehdä asialle mitään.

Mielestäni viranomaissivuja pitäisi todella voida lukea vaikka OS/2 Warpin selaimella. Kuten tässäkin ketjussa joku kirjoitti, Trafin sivut ovat nykyään täynnä JS-valikkoja, ettei hakukoneetkaan osaa indeksoida niitä. Se on kansalaisten tiedonsaannin kannalta melko surkeaa toimintaa. Varsinainen asiointi tietysti vaatii salattua yhteyttä.
On se ideana ihan ok, mutta tuossa on se ongelma, että noihin implementaatioihin voi liittyä rajoitteita, jotka kuitenkin tekevät asian mahdottomaksi käytännössä, koska niin monta teknologiapinon tasoa on mennyt uusiksi. Haluat ehkä, että OS/2:lle olisi teoriassa mahdollista toteuttaa selain, joka toimisi, mutta jotta ylipäänsä pääsisi siihen pisteeseen, on monta alemman tason ongelmaa ratkottavana.

Esim. jos vaikka sillä OS/2-koneella on token ring -verkko koaksiaalilla ja sinulla ei ole mitään, mihin kytkeä konetta, kaikki nämä tasot pitää rakentaa uudestaan ja laittaa väliin joku proxy. Pian voi IPv6:n takia jo kommunikointi muuttua haasteelliseksi. Sinun pitää jotenkin osata manuaalisesti päivittää sertifikaatit koneelle, jos selain ylipäänsä tukee yhtään kryptoalgoritmia, mitä palvelinpuoli vielä kelpuuttaa. Esim. Traficomin sivuilta en saa itse luettua edes yhtään "staattista" tietosivua ilman https:ää. Ja jos selain ei tue TLS:ää vaan pelkästään SSL:ää, edelleen mitään ei saa tehtyä. TLS 1.0 vaikuttaisi yhä toimivan. Tarvitaan siis se MITM-proxy, jos laite ja ohjelmisto ovat 80- tai 90-luvuilta. Ja nyt kun TLS 1.0 ja 1.1 ovat myös jo vanhentuneet ja tuki poistumassa, se nostaa minimitason vuoteen 2008. Verkkopankkien ja viranomaisten kanssa asioitaessa haluat luultavasti, että tietoturva on kunnossa, joten tuo rajoite on aika tiukka ja käytännössä ohjaa noihin muihinkin teknologiavalintoihin.
 
Niin mistä rajapinnoista on kyse? Firefoxiin tuli esim. versiossa 25 tuki Web Audio API:lle. Tämä on siis standarditapa käsitellä audiota. Sitä ennen Firefoxilla oli oma ei-standardi tapa käsitellä audiota. Ymmärrätkö tahallaan väärin mistä on kyse. Web Audio API toimii kaikilla selaimilla ja aiemmin jokaiselle tarvi oman, mahdollisesti erilaisen API:n. Kyse on taas yli 10 vuotta vanhasta standardista, joten tuki lienee tässä kohtaa kaikissa selaimissa. Ehkä ei Seamonkeyssä, mutta noissa mitä 99% ihmisistä käyttää.


Niin no koita nyt tehdä itsellesi ensin selväksi, mitä niistä API-versioista kannatat. Normaalisti kun porukka käyttää noita kirjastojen kautta, se kirjasto voi toteuttaa polyfillit niin, että sekä uusi että vanha API ovat samaan aikaan tuettuja. Onhan tässä selkeä etu. Se standardi-API on toiminut 2013 asti, mutta jos haluat tukea myös vuosien 2011-12 Firefoxia, onnistuu sen kirjaston kautta samalla kun uudemmat ovat tuettuja.

Siihen Web Audio APIin on jälkeenpäin lisätty uusia rajapintoja (siis funktioita ja luokkia) jotka tekevät samat asiat kuin ne jo aiemmin olemassa olleet rajapinnat, ja usein hankalammin ja monimutkaisemmin. Ihmettelen vain, miksi jotain ohjelmointikieltä kehitetään tuolla tavalla.

Joo, tämä on iso epäkohta, koska tuo ESR on monessa paikassa käytössä ja käyttäjillä ei ole mahdollisuutta välttämättä tehdä asialle mitään.


On se ideana ihan ok, mutta tuossa on se ongelma, että noihin implementaatioihin voi liittyä rajoitteita, jotka kuitenkin tekevät asian mahdottomaksi käytännössä, koska niin monta teknologiapinon tasoa on mennyt uusiksi. Haluat ehkä, että OS/2:lle olisi teoriassa mahdollista toteuttaa selain, joka toimisi, mutta jotta ylipäänsä pääsisi siihen pisteeseen, on monta alemman tason ongelmaa ratkottavana.

Esim. jos vaikka sillä OS/2-koneella on token ring -verkko koaksiaalilla ja sinulla ei ole mitään, mihin kytkeä konetta, kaikki nämä tasot pitää rakentaa uudestaan ja laittaa väliin joku proxy. Pian voi IPv6:n takia jo kommunikointi muuttua haasteelliseksi. Sinun pitää jotenkin osata manuaalisesti päivittää sertifikaatit koneelle, jos selain ylipäänsä tukee yhtään kryptoalgoritmia, mitä palvelinpuoli vielä kelpuuttaa. Esim. Traficomin sivuilta en saa itse luettua edes yhtään "staattista" tietosivua ilman https:ää. Ja jos selain ei tue TLS:ää vaan pelkästään SSL:ää, edelleen mitään ei saa tehtyä. TLS 1.0 vaikuttaisi yhä toimivan. Tarvitaan siis se MITM-proxy, jos laite ja ohjelmisto ovat 80- tai 90-luvuilta. Ja nyt kun TLS 1.0 ja 1.1 ovat myös jo vanhentuneet ja tuki poistumassa, se nostaa minimitason vuoteen 2008. Verkkopankkien ja viranomaisten kanssa asioitaessa haluat luultavasti, että tietoturva on kunnossa, joten tuo rajoite on aika tiukka ja käytännössä ohjaa noihin muihinkin teknologiavalintoihin.

Nythän Finlexiäkin ollaan uudistamassa niin, että uudistuksen jälkeen sitä ei enää pääse lukemaan oikein muilla selaimilla kuin Chromella ja uusimmilla Firefoxeilla, koska sisältö ei näy enää ollenkaan ilman uusimpien JavaScript-rajapintojen tukea. Vanha Finlex toimii aivan hyvin vaikka lynxillä, kuten pitääkin toimia. Valtakunnan laki on sen verran tärkeä asia, että mahdollisuus sen lukemiseen pitäisi olla kaikilla tavoin mahdollisimman hyvin kaikkien saavutettavissa.

Ja kaiken lisäksi tuota uudistusta vielä perustellaan sillä, että uusi on muka jotenkin saavutettavampi, vaikka toimiikin murto-osalla siitä määrästä selaimia, joilla vanhaa versiota voi selata.

Koska nykyinen vanha Finlexin versio toimii sillä lynxilläkin, niin asia ei selvästikään ole mahdotonta implementoida käytännössä.
 
Esim. jos vaikka sillä OS/2-koneella on token ring -verkko koaksiaalilla ja sinulla ei ole mitään, mihin kytkeä konetta, kaikki nämä tasot pitää rakentaa uudestaan ja laittaa väliin joku proxy. Pian voi IPv6:n takia jo kommunikointi muuttua haasteelliseksi.
Tuo on asiakkaan pään ongelma, ei sivuston ylläpitäjän. Ajurit löytyy kyllä yleisimpiin Ethernet-verkkokortteihin.

Sinun pitää jotenkin osata manuaalisesti päivittää sertifikaatit koneelle, jos selain ylipäänsä tukee yhtään kryptoalgoritmia, mitä palvelinpuoli vielä kelpuuttaa. Esim. Traficomin sivuilta en saa itse luettua edes yhtään "staattista" tietosivua ilman https:ää. Ja jos selain ei tue TLS:ää vaan pelkästään SSL:ää, edelleen mitään ei saa tehtyä. TLS 1.0 vaikuttaisi yhä toimivan. Tarvitaan siis se MITM-proxy, jos laite ja ohjelmisto ovat 80- tai 90-luvuilta. Ja nyt kun TLS 1.0 ja 1.1 ovat myös jo vanhentuneet ja tuki poistumassa, se nostaa minimitason vuoteen 2008. Verkkopankkien ja viranomaisten kanssa asioitaessa haluat luultavasti, että tietoturva on kunnossa, joten tuo rajoite on aika tiukka ja käytännössä ohjaa noihin muihinkin teknologiavalintoihin.
Salaus on tässä se isoin ongelma. Asia jäi mietityttämään, joten kokeilin piruuttani avata Finlexiä OS/2 Warpin mukana tulleella Netscape 2.02 selaimella ja sain vain virhekoodin 1010. Kokeilin myös Netscape 4.61:lla ja se ilmoitti ettei ole yhteensopivia salausalgoritmeja.
Tuohon on kyllä saatavilla tuoreempiakin selaimia, mutta en tällä erää alkanut selvittelemään niiden asennusrumbaa. Kyseisen koneen Pentium II prosessori aiheuttanee myös yhteensopivuusongelmia, kun se ei tue modernien selainten tarvitsemia käskykantoja.

Ydinkysymys on se, että tarvitseeko lakipykälien lukeminen välttämättä salattua yhteyttä? Kirjautumista vaativat asiat ovat tietysti asia erikseen, mutta jos vain haluaa lukea staattista tekstiä? Miksi siihen ei voi jättää porttia 80 auki, vaan uudelleenohjataan väkisin salattuun porttiin? Tuomari tekee väärän päätöksen, kun lukee vahingossa sertitöntä versiota ja syytetty tekee samalla MITM-hyökkäystä peukaloiden itselleen mieluisempia pykäliä?

Ehkä niin. Mutta yllätyin, että myös Wikipedia pakottaa https:n. Luulin sen edes toimivan millä tahansa perunalla.

Ja niin, tätä postausta ei kannata ottaa turhan vakavasti. Sainpahan hyvän syyn käynnistää vanhaa konetta.

20241217_032026.jpg20241217_032244.jpg20241217_032309.jpg



20241217_032351.jpg
 
Ydinkysymys on se, että tarvitseeko lakipykälien lukeminen välttämättä salattua yhteyttä? Kirjautumista vaativat asiat ovat tietysti asia erikseen, mutta jos vain haluaa lukea staattista tekstiä? Miksi siihen ei voi jättää porttia 80 auki, vaan uudelleenohjataan väkisin salattuun porttiin? Tuomari tekee väärän päätöksen, kun lukee vahingossa sertitöntä versiota ja syytetty tekee samalla MITM-hyökkäystä peukaloiden itselleen mieluisempia pykäliä?

Ehkä niin. Mutta yllätyin, että myös Wikipedia pakottaa https:n. Luulin sen edes toimivan millä tahansa perunalla.
Eikö nuo nyt olisi mitä otollisimpia väärennetyn informaation syöttökohteita mitm-hyökkäyksille?
 
Eikö nuo nyt olisi mitä otollisimpia väärennetyn informaation syöttökohteita mitm-hyökkäyksille?
Voi olla. Pidän kuitenkin riskiä kovin teoreettisena. Tuomarin pitäisi huolehtia siitä, että käyttää https-yhteyttä.
 
Ydinkysymys on se, että tarvitseeko lakipykälien lukeminen välttämättä salattua yhteyttä? Kirjautumista vaativat asiat ovat tietysti asia erikseen, mutta jos vain haluaa lukea staattista tekstiä? Miksi siihen ei voi jättää porttia 80 auki, vaan uudelleenohjataan väkisin salattuun porttiin? Tuomari tekee väärän päätöksen, kun lukee vahingossa sertitöntä versiota ja syytetty tekee samalla MITM-hyökkäystä peukaloiden itselleen mieluisempia pykäliä?

Ehkä niin. Mutta yllätyin, että myös Wikipedia pakottaa https:n. Luulin sen edes toimivan millä tahansa perunalla.
Ihan hyvää pohdintaa ja tässä lienee yleinen paradigman muutos. Joitain vuosia sittenhän https oli niin harvinaista herkkua, että jossain kauppasivuillakin kaikki muut vaiheet oli ilman, paitsi se maksuvaihe ja siitäkin ihan kriittinen viimeinen osuus. Veikkaan että nykyään voi olla ihan sekin, että osa kehittäjistä ei ymmärrä oikein tuota yhteysmuodon vaihtelua, frameworkit voi edellyttää http/2 + tls-komboa eri tavoin ja arvostetaan yksityisyyttä enemmän, joten asia on yksinkertaisempi näin. Ja asiakaskoneilta odotetaan suht. uutta selainohjelmistoa. Tätä helpottaa se, että selaimet ja käyttikset päivittävät itseään automaattisestikin. Ei salaus varmastikaan ole pakollinen tällaisiin.
 
Voi olla. Pidän kuitenkin riskiä kovin teoreettisena. Tuomarin pitäisi huolehtia siitä, että käyttää https-yhteyttä.
Maailma on paljon muuttunut, mutta vielä kun roaming on paikoin kallista, tuo salaus oletuksena on ihan mukava niille, jotka surffaavat kahviloissa, lentokentillä yms. wifin varassa. Vpn-firmat tietysti ovat eri mieltä, mutta moni loppukäyttäjä arvostaa, kun liikenne toimii käyttäjää kunnioittavalla tavalla lähtökohtaisesti. Ja kyllähän operaattoreitakin voi kiinnostaa liiketaloudellisista syistä seuloa, mitä liikennettä asiakkaat tuottavat. Joissain maissa poliisit ovat vähän yliaktiivisia jne.
 
Maailma on paljon muuttunut, mutta vielä kun roaming on paikoin kallista, tuo salaus oletuksena on ihan mukava niille, jotka surffaavat kahviloissa, lentokentillä yms. wifin varassa. Vpn-firmat tietysti ovat eri mieltä, mutta moni loppukäyttäjä arvostaa, kun liikenne toimii käyttäjää kunnioittavalla tavalla lähtökohtaisesti. Ja kyllähän operaattoreitakin voi kiinnostaa liiketaloudellisista syistä seuloa, mitä liikennettä asiakkaat tuottavat. Joissain maissa poliisit ovat vähän yliaktiivisia jne.
Pidän salauksen yleistymistä lähtökohtaisesti ihan hyvänä asiana. Sen automaattista uudelleenohjausta voisi kuitenkin enemmän harkita tapauskohtaisesti.

Kävi tuossa taannoin itsellekin kämmi, kun menin eräälle foorumille hakukoneen kautta ekaa linkkiä klikaten, joka vei sen salaamattomalle versiolle. Huomasin tilanteen vasta kirjautumisen jälkeen. Eli salasana meni salaamattomana. Vahinkoja siis sattuu jos siihen annetaan mahdollisuus.
 
TLS on vähän huono protokolla webbiin. Parempi olisi olla TCP:n ja HTTP:n välissä jokin sellainen salausprotokolla, jossa ei joka ikisen soketin salausta tarvitse aina kätellä uudestaan. Oikeastihan HTTP/1.x on huomattavasti nopeampi protokolla kuin nuo Googlen suunnittelemat paskaprotokollat, mutta TLS on se, joka hidastaa.
 
Parempi olisi olla TCP:n ja HTTP:n välissä jokin sellainen salausprotokolla, jossa ei joka ikisen soketin salausta tarvitse aina kätellä uudestaan.
Se on pakko tehdä noin, koska yksi palvelin (tai ehkä pitäisi puhua IP-osoitteen omaavasta palvelusta) voi tarjota useamman eri sivuston sisältöä asiakkaalle. Eli TCP:n lähde- ja kohdetiedot eivät noissa tapauksisa riitä yksilöimään sitä miltä sivustolta asiakas haluaa dataa ladata.
 
Se on pakko tehdä noin, koska yksi palvelin (tai ehkä pitäisi puhua IP-osoitteen omaavasta palvelusta) voi tarjota useamman eri sivuston sisältöä asiakkaalle. Eli TCP:n lähde- ja kohdetiedot eivät noissa tapauksisa riitä yksilöimään sitä miltä sivustolta asiakas haluaa dataa ladata.
Mikään pakko ei ole tehdä niin. Enkä tietenkään tarkoittanut, että se istunto perustuisi TCP:n lähde- ja kohdetietoihin, ja sellainenhan olisi muutenkin valtava tietoturvariski. Sen sijaan siinä protokollassa voisi olla vaikka joku token, jonka asiakas voi antaa palvelimelle ja ohittaa sillä monimutkaisen kättelyn, joka TLS-protokollassa nykyään on. Tiedonsiirto jatkuisi siitä eteenpäin sitten salattuna käyttäen samoja salausavaimia kuin siinä aiemmassakin soketissa.

DuckDuckGo on jo pitkään, siis ainakin useiden kuukausien ajan, ollut sillä tavalla rikki, että jos selaimen user-agent-string on jotain muuta kuin uusinta Firefoxia tai Chromea, niin hakutulosten klikkaaminen johtaa jollekin rikkinäiselle redirector-sivulle, jolla avautuu vain nginxin HTTP 400-virhesivu. "Vika" korjautuu vaihtamalla UA-merkkijono samaksi kuin uusimmassa Firefoxissa. Kummallista, että yksi maailman käytetyimmistä hakukoneista voi olla tuolla tavalla rikki noin pitkään. Tuota ei tapahdu kaikilla DuckDuckGo-instansseilla, mutta useimmilla kyllä. Riippuu vähän tuurista, mille instanssille joku kuormanjakopalvelin on ohjannut.
 

Statistiikka

Viestiketjuista
265 761
Viestejä
4 599 947
Jäsenet
75 696
Uusin jäsen
Kimm0Kuu

Hinta.fi

Back
Ylös Bottom