Posiljanje osebnih podatkov (imena, priimki, naslov, rojstni podatki, mobitel št., ...)

Znanec sprašuje, koliko je varno pošiljanje imen, priimkov,
naslovov, rojstnih podatkov, mobitel številk, ... zdravljenih oseb
na strežnik v tujino, ki pripada tuji medicinski ustanovi (preveril s whois),
ki se pošiljajo preko SI zdravstvene inštitucije.
Podatki se pošiljajo preko http povezave,
logično bi bilo, da bi se pošiljali preko https povezave.
Ali sem v zmoti?

Preko stare http povezave mozilla firefox ni odreagirala, ko so se pošiljali podatki. Preko nove http povezave mozilla firefox izpiše tole:

"Ta povezava je nepreverjena
Firefox ste zaprosili za varno
povezavo z http:... xxx.xxx.xxx.81 ...,
vendar ne moremo zagotoviti,
da je vaša povezava res varna.
Ko se poskušate varno povezati, se spletne strani
običajno predstavijo in tako dokažejo, da ste prišli na pravo mesto.
Toda istovetnosti te strani žal ni mogoče overiti.
Kaj naj storim?
Če se na to stran
ponavadi povezujete brez težav, jo morda kdo poskuša oponašati,
zato vam nadaljevanje odsvetujemo."

"Prepisali boste način, kako Firefox prepoznava to stran. Uveljavljene banke, trgovine in druge javne strani vas ne bodo prosile za to.
Stanje certifikata:
Ta stran se poskuša predstaviti z neveljavnimi podatki.
Napačna stran:
Certifikat pripada drugi strani, kar lahko nakazuje na krajo identitete."

! Gre za http, ne za https povezavo, ki jo zazna mozilla firefox
v zgornjem opozorilu.

Na prejšnji http povezavi so se podatki prenašali kako leto.
V namene mednarodne statistike, ...

Ali bi bilo za predlagat https povezavo, kako drugo rešitev za
bolj varen prenos osebnih podatkov. ...

Hvala za odgovor.

Dodajam še tele informacije iz Mozilla Firefox:

Zdaj delujoč URL za dostop na zgoraj omenjeno http povezavo je drugač tale:
http:... xxx.xxx.xxx.81 ...

! Mozilla FF pa prikaže/ opozarja v zvezi z varnostnim certifikatom na tale drug IP:
Secure Connection Failed
https:... xxx.xxx.xxx.110 ... uses an invalid security certificate
(! Vendar pa Ni vzpostavljene prav nobene https povezave.
Temveč le http povezava na: http://xxx.xxx.xxx.81 ).

The certificate is only valid for
...a id="cert_domain_link ...
title= ...

(Error code: ssl_error_bad_cert_domain)

This could be a problem with the server's configuration,
or it could be someone trying to impersonate the server.

If you have connected to this server successfully in the past,
the error may be temporary, and you can try again later."

Znanec sprašuje, koliko je varno pošiljanje imen, priimkov,
naslovov, rojstnih podatkov, mobitel številk, ... zdravljenih oseb
na strežnik v tujino, ki pripada tuji medicinski ustanovi...
Na prejšnji http povezavi so se podatki prenašali kako leto.
V namene mednarodne statistike, ...

Vse, kar bi od tega utegnilo služiti statističnim namenom, so rojstni podatki, pa še to najbrž le letnica in morda mesec rojstva. Vse ostalo je nesmisel in vsaj podpiranje zlorabe, če že ne zloraba.

bo treba zgleda,za mnenje povprašat informacijsko pooblaščenko. ...

Ne le da zgleda, ampak kar vpije po prijavi.

Pristojni bodo informirani. ...

Potem pa ima star Firefox, če še nima vseh podjetji, ki izdajajo certifikate vpisanih.

[bilo treba dodat certifikat pod izjeme
v Mozilla Firefoxu]. ...

To ni dovolj dobro. Kdo jamči, da certifikat pripada ustanovi, za katero piše, da ji?

Naj preveri, kdo je podpisal certifikat in kje se konča veriga zaupanja.

Tako je.
Vsakdo ki ima strežnik in 3 minute časa, lahko generira tak certifikat.
Vsaka resna firma ali ustanova, ima podpisane certifikate preko verisign, thawte ali podobnih.
najbolje, da informirate pristojne, da oni to rešijo.
lp

Tudi v Mozilli Firefox, Version 3.0.13 (Ubuntu 8.04 LTS Hardy)
je znanec moral dati certifikat pod izjeme.

Certifikat je podpisan od Thawte, issued by :
"... Common Name (CN): Thawte Premium Server CA
Organization (O): Thawte Consulting cc
Organizational Unit (OU): Certification Services Division
Validity
Issued On: 02/28/2008
Expires On: 05/21/2010 ..."

Issued To:
"Common Name (CN): www.xxxxxxxxx.com
Organization (O): Institute for Evaluative Research in xxxxxxxxxxx xxxxxxx
Organizational Unit (OU): University of xxxx (CH)"

Ima pa zdaj znanec težave pri logiranju na https
(prvi link)
http://tinyurl.com/mb3ldl
http://tinyurl.com/nhzrmg
(seveda ne dostopa na stran preko online tinyurl
storitve, temveč direktno na stran).
Uporabniško ime, geslo naj ne bi bilo pravilno (piškoti, java script so omogočeni).

Pri http://xxx.xxx.xxx.xxx/... (http protokolu) se lahko logira b.p.
Delo od doma (gre za povečan obseg dela na delovnem mestu) mu zdaj stoji.

Bi pa rad pri delu na daljavo, ko so "konice", uporabljal https protokol,
tako kot na delovnem mestu. ...

O težavah z logiranjem po https protokolu bi mu bilo
po emailu za obvestit admina strežnika (spletne strani). Moj predlog, ki mu ga bom predlagal.

Certifikat je bil izdan za www.memdoc.com
University of Bern
Institute for Evaluative Research in Orthopaedic Surgery

Https stran se nahaja na 195.176.223.110
RIPE pravi tole:
inetnum: 195.176.223.64 - 195.176.223.127
netname: UNIBERN-NET
descr: Universitaet Bern
descr: 3014 Bern
country: CH
admin-c: IG975-RIPE
tech-c: IG975-RIPE
status: ASSIGNED PA
mnt-by: CH-UNISOURCE-MNT
source: RIPE # Filtered

person: Ives Gerber
address: MEMcenter -IEFO
address: Stauffacherstrasse 78
address: CH-3014 Bern
phone: +41 31 631 59 66
fax-no: +41 31 631 59 31
nic-hdl: IG975-RIPE
source: RIPE # Filtered

Glede na vse skupaj, bi se admin moral ustreliti v koleno.

lp

Pristojni bodo informirani. ...

Če me spomin ni popolnoma zapustil, se je tule še včeraj dalo brati nekaj o pritiskih šefov na omenjenega znanca. Kam pa je to izginilo?
In kaj je zdaj z informiranjem pristojnih, skratka, ne kako se pošilja, ampak kaj se pošilja?

*... Https stran se nahaja na 195.176.223.110 ...*

https je na tej strani edino pod linkom za documentation
(na ostalih linkih je only http dostop).

knesz, lahko preciziraš pomankljivosti ...
Oz. kaj bi se dalo/ bi bilo bolje izboljšat. ...

Hvala

Admin naj za ip 195.176.223.110 naredi A ter mogoče še PTR zapis, ter za to stran nabavi veljaven certifikat pri thawte, verisign...
Pri http dostopu ti pa noben browser ne bo zajamral, ker je to pač navadna ne-varna povezava. Toliko ka kratko z tehnične strani, v varstvo osebnih podatkov se pa ne bom spuščal, ker tega področja ne poznam dovolj dobro.
lp

*... Https stran se nahaja na 195.176.223.110 ...*

https je na tej strani edino pod linkom za documentation
(na ostalih linkih je only http dostop).

knesz, lahko preciziraš pomankljivosti ...
Oz. kaj bi se dalo/ bi bilo bolje izboljšat. ...

Hvala

Admin naj za ip 195.176.223.110 naredi A ter mogoče še PTR zapis, ter za to stran nabavi veljaven certifikat pri thawte, verisign...
Pri http dostopu ti pa noben browser ne bo zajamral, ker je to pač navadna ne-varna povezava. Toliko ka kratko z tehnične strani, v varstvo osebnih podatkov se pa ne bom spuščal, ker tega področja ne poznam dovolj dobro.
lp

Tudi samopodpisani certifikat je lahko dovolj. VeriSign pa samo denar pobira.

Res je, da malo bolj pogledajo firmo, ampak cena za green bar je veliko preveč.

Upam, da veš kaj certifikat je. In se je že zgodilo, da so kakšne phishing fore imeli najvišji certifikat (green bar).

Samopodpisan certifikat ti zagotavlja toliko kot podpisan by VeriSign. Razlika je samo v tem, da pri VeriSign-u malo preverijo podjetje.

Digitalno potrdilo je lahko tak[no, ki ga je podpisala tretja oseba, ki ji zaupata obe strani (strežnik in odjemalec). To je praktično za vse primere, kjer vnaprej ne veš s kom boš komuniciral.

Če pa se gre za neposredno komunikacije, kjer obe strani vnaprej vesta, da bosta komunicirali, potem pa lahko uporabiš kakršno koli digitalno potrdilo, ki omogoča zahtevano stopnjo varnosti. Potrdilo pa se pred začetkom komunikacije izmenja na varen način, ali pa se pred posredovanjem podatkov na varen način preveri njegovo verodostojnost. Zagotovo pa se to pri prenosu osebnih podatkov, še posebej pa ne občutljivih osebnih podatkov ne počne malo "na pamet".

Primer varnega prenosa potrdila je, da vam skrbnik strežnika posreduje kopijo digitalnega potrdila preko navadne pošte (USB ključek, USB token, CD, ...) nato pa se ga vnese v profile/brkljalnike/aplikacije uporabnikov, ki bodo do strežnika dostopali.

Primer varne preverbe verodostojnosti je, da preko SSL pobereš digitalno potrdilo strežnika, vendar pa preko npr. telefonskega klica in pogovar s skrbnikom strežnika preveriš, da si prejel pravo potrdilo (primerjava zgostitvenih kod in ostalih podatkov).

"Na pamet" pa je, da digitalno potrdilo samo pobereš in potem upaš/verjameš, da ti ni nihče po poti podtaknil napačnega. Pri pošiljanju občutljivih osebnih podatkov s pomočjo takšnega digitalnega potrdila, je takšna napača že dovolj, da se pridobi opozorilo in zahtevo za uskladitev s strani IP-RS.

Digitalna potrdila, ki jih izdajajo Thawte/Verisign/Entrust/... se za takšne primere po verodostojnosti ne razlikujejo od doma ustvarjenih. Še vedno mora uporabnik pred njihovo uporabo za ta namen preveriti njihovo verodostojnost oziroma dejansko identiteto lastnika/skrbnika strežnika. Izjema so pri nas le kvalificirana digitalna potrdila, kjer je odgovornost preverjanja identitete prepuščena s strani države kvalificiranemu overitelju (SI-GEN CA, Halcom, Post@rCA).

DejanL15> Samopodpisan certifikat ti zagotavlja toliko kot podpisan by VeriSign. Razlika je samo v tem, da pri VeriSign-u malo preverijo podjetje.

And that's precisely the point.

Raje imam ne-preverjen certifikat kot pa, da ga sploh ni.

Poleg tega je še vseeno možnost, da je nekdo vdrl na strežnik in namestil zlonamerno kodo in mu ta koda pošilja informacije o kreditnih karticah na drug strežnik.

Pa da te malo citiram:

Upam, da veš kaj certifikat je. In se je že zgodilo, da so kakšne phishing fore imeli najvišji certifikat (green bar).

Samopodpisan certifikat ti zagotavlja toliko kot podpisan by VeriSign. Razlika je samo v tem, da pri VeriSign-u malo preverijo podjetje.

Kot so ti že povedali pred mano, pri samopodpisanem certifikatu ti meni verjameš na besedo, da sem jaz jaz in da je spletna stran, kamor pošiljaš zaupne podatke, res moja.
Pri podpisanem certifikatu ti pa jaz povem, da sem jaz jaz, da je spletna stran res moja in da to potrjuje tudi Verisign, Thawte oz. nekdo drug, ki me je preveril. In, če prideš na neko drugo stran, za katerega lastnik pravi da je moja, pa če ni podpisanega certifikata, boš lepo zaprl browser, ali pa, če si prijazen, boš obvestil mene, da nekaj ni v redu.
Pri samopodpisanem certifikatu pa lahko vsakdo trdi, da sem to jaz.
Res pa je, da v obeh primerih poteka promet preko varne povezave.
Certifikati pa nimajo prav nobene veze z vdori na strežnik in nameščanjem zlonamerne kode ter pošiljanjem podatkov preko te kode. V tej fazi debate, tebe zanima samo to, da podatki varno pridejo do mene.
lp

Tole meni hudo smrdi po zlorabi.

Predvsem dvomim, da so sploh pridobili ustrezna soglasja.

Nadalje. Podatki se smejo posredovati le v šifrirani obliki! Bi rekel, da celo https ni dovolj, pač pa da mora biti cela datoteka šifrirana.

http://www.ip-rs.si/zakonodaja/zakon-o-...

Zavarovanje občutljivih osebnih podatkov
14. člen
(1) Občutljivi osebni podatki morajo biti pri obdelavi posebej označeni in zavarovani tako, da se nepooblaščenim osebam onemogoči dostop do njih, razen v primeru iz 5. točke 13. člena tega zakona.
(2) Pri prenosu občutljivih osebnih podatkov preko telekomunikacijskih omrežij se šteje, da so podatki ustrezno zavarovani, če se posredujejo z uporabo kriptografskih metod in elektronskega podpisa tako, da je zagotovljena njihova nečitljivost oziroma neprepoznavnost med prenosom.

in seveda:

6. člen
19. Občutljivi osebni podatki – so podatki o rasnem, narodnem ali narodnostnem poreklu, političnem, verskem ali filozofskem prepričanju, članstvu v sindikatu, zdravstvenem stanju, spolnem življenju, vpisu ali izbrisu v ali iz kazenske evidence ali evidenc, ki se vodijo na podlagi zakona, ki ureja prekrške (v nadaljnjem besedilu: prekrškovne evidence); občutljivi osebni podatki so tudi biometrične značilnosti, če je z njihovo uporabo mogoče določiti posameznika v zvezi s kakšno od prej navedenih okoliščin.

Kar se pa tiče certifikatov je pa stvar taka, da je mogoče ustvariti tudi s strani trusted CA podpisane fake certifikate. One word: Comodo.

Rešitev je preverjanje SHA odtisa certifikata (po varnem kanalu seveda). In v tem primeru je popolnoma vseeno če je certifikat samopodpisan.