FURS in Telemach priporočata uporabo starih luknjičastih brskalnikov

Mavrik je 7. mar 2017 ob 22:09 izjavil:

- eDavki pa uporabljajo Java vtičnik da podpiše dokument. V HTML standardu podpore za kaj takega ni, tako da niti nimajo druge alternative kot pa sčasoma preseliti podpisovanje na njihove strežnike.

jype je 8. mar 2017 ob 01:12 izjavil:

PaX_MaN> Še dobro, da NOBEN DRUG VELIK POSODABLJAN ODPRTOKODEN BRSKALNIK NE PODPIRA NPAPI.

Še dobro, da si nepismen.

techfreak :) je 9. mar 2017 ob 07:45 izjavil:

Safari ima NPAPI podporo in je zaprtokodni brskalnik.

PaX_MaN je 8. mar 2017 ob 23:19 izjavil:

jype je 8. mar 2017 ob 01:12 izjavil:

PaX_MaN> Še dobro, da NOBEN DRUG VELIK POSODABLJAN ODPRTOKODEN BRSKALNIK NE PODPIRA NPAPI.

Še dobro, da si nepismen.

Št. zaprtokodnih brskalnikov, ki podpirajo NPAPI: 1
Št. odprtokodnih brskalnikov, ki podpirajo NPAPI: 0, nič, nula, zero, niente
Ena je pa vedno in povsod in več od nič.

Imam občutek, da v IT/Računalništvu na splošno primanjkuje takšnih "hi-level" pregledov; ampak načeloma nas stvari zanimajo, pa dejansko prežvečimo tehnikalije in si "from bottom-up" ustvarjamo sliko. Sploh pri programiranju je po navadi tako - običajen nasvet začetniku je: začni programirat in ne sprašuj preveč, boš že razumel. Zdaj, včasih je to res upravičeno reči, nisem pa prepričan, da je takšen pristop dober kot načelo.

Mavrik je 7. mar 2017 ob 22:09 izjavil:

pa sčasoma preseliti podpisovanje na njihove strežnike.

Mavrik je 8. mar 2017 ob 14:52 izjavil:

Tvoj privatni ključ ostane v tvoji lasti (in ni nikoli prenešen preko linije) in se potem komot uporabi za verifikacijo tega podpisa.

jype je 9. mar 2017 ob 07:54 izjavil:

V resnici ne, ker imaš znotraj APIjev za WebExtension že dostop do vsega, kar potrebuješ (vsaj v Firefox in Chrome, kjer obstaja tudi web crypto API, s katerim lahko podpišeš dokument in generiraš vse potrebne elektronske žige).

Spura je 10. mar 2017 ob 12:30 izjavil:

Tvoj privatni ključ ostane v tvoji lasti (in ni nikoli prenešen preko linije) in se potem komot uporabi za verifikacijo tega podpisa.
A si ti na glavo padu? Holy shit!

To je povsem narobe. Podpis, ki ga lahko verificira samo imetnik privatnega kljuca je povsem neuporaben. In kar je se hujse, ce je tak podpis veljaven, potem ga lahko ponaredi vsak imetnik tvojega javnega kljuca, ki je javen! Kaj ti pomaga, da tvoj privatni kljuc ni prenesen preko linije, ko pa lahko vsak podpise v tvojem imenu karkoli hoce?!?!?

Zato se tudi ne da podpisovat na serverju. Kako ti to lahko sploh na misel pade?!?! Zarad takih kot ti mamo v drzavni upravi tudi sisteme, ki kar na serverju hranijo privatni kljuc uporabnika in z njim podpisujejo.

Spura je 10. mar 2017 ob 12:30 izjavil:

Oh komaj cakam naslednji javascript zmazek pristop, kjer bom spet podpisoval dokumente, ki jih ne vidim, in kjer bom pri podpisovanju prepuscen na milost in nemilost designerja webstrani, in kjer bo spet pravilnost komplet prepuscena vsakemu programerju posebi.

Mavrik je 10. mar 2017 ob 12:46 izjavil:

Ne vidim pa nekega razloga zakaj točno moraš podpisovati s svojim ključem ko je strežnik od države (kateri ti oddajaš ta obrazec in v končni fazi moraš zaupati) že ugotovil tvojo istovetnost in integriteto podatkov. Podobno kot pač uradniki na upravni enoti poklikajo stvari ko sediš pred njimi in preverijo tvojo osebno. Če je dovolj dobro za nakazovanje 50.000EUR na bankah, bo dost dobro za PODO-OPSVZ a ne? :P

Mavrik je 10. mar 2017 ob 13:16 izjavil:

Da morda jaz razložim kaj mislim s podpisovanjem na strežniku:

Trenutno se podpisovanje dogaja na mojem računalniku z mojim privatnim ključem. To podpisovanje dela neka zaprtokodna komponenta ki mi jo porine država in vsebine, ki se podpisuje dejansko nikoli ne vidim (vsebina obrazca se najprej prepošlje preko POST pa še kaj, ne spomnim se podrobnosti). Prisiljen sem zaupati državi, da je podpisna komponenta kompetentno napisana, počne to kar pravijo da počne in da bo dejansko podpisala tisto kar vidim v brskalniku. Te komponente ne morem zamenjati.

Tako da je IMO popolnoma vseeno če namesto tega podpis v mojem imenu napravi server s svojim privatnim ključem. Strežnik itak najprej verificira mene z mojim certifikatom in vzpostavi zavarovano TLS sejo. Zatem lahko komot vzame vsebino, jo podpiše s svojim ključem (certifikat je pač edavki1.durs.si namesto SIGEN-CA Mavrik), v podpisano vsebino pa doda potrdilo da me je avtenticiral z mojim SIGEN-CA ključem (lah je tud hash in drugi podatki). S stališča zaupanja je to popolnoma identično - še vedno jaz moram državi zaupati da podpisuje to kar jaz vidim na ekranu, ampak tokrat ne rabim ene crappy komponente. Zatem mi pač pusti prenesti podpisan dokument da ga imam kot arhiv/dokaz/karkoli. Podpis zagotovi integriteto, avtentikacija pa je bila narejena že na nivoju TLSja.

--

Seveda idealneje bi bilo če bi uporabljali enega od standardov za podpisovanje (recimo XML ima vsaj enega) in bi lahko sam poljubno pri sebi izbiral implementacijo, oz. po možnosti bi bilo še boljše če bi se WebCrypto počasi standardiziral. Na žalost pa ta pristop ne zgleda da bo realističen kaj hitro.

perci je 10. mar 2017 ob 20:51 izjavil:

Sej točno to zdej pripravlja MJU - zadevi so poimenovali SICES - https://nio.gov.si/nio/asset/centralni+...

Mavrik je 10. mar 2017 ob 13:16 izjavil:

Trenutno se podpisovanje dogaja na mojem računalniku z mojim privatnim ključem. To podpisovanje dela neka zaprtokodna komponenta ki mi jo porine država in vsebine, ki se podpisuje dejansko nikoli ne vidim. Prisiljen sem zaupati državi, da je podpisna komponenta kompetentno napisana, počne to kar pravijo da počne in da bo dejansko podpisala tisto kar vidim v brskalniku. Te komponente ne morem zamenjati.

Tako da je IMO popolnoma vseeno če namesto tega podpis v mojem imenu napravi server s svojim privatnim ključem. Strežnik itak najprej verificira mene z mojim certifikatom in vzpostavi zavarovano TLS sejo.