|
Hinnavaatlus
:: Foorum
:: Uudised
:: Ärifoorumid
:: HV F1 ennustusvõistlus
:: Pangalink
:: Telekavad
:: HV toote otsing
|
|
| autor |
sõnum   |
|
Tanel
HV Guru
liitunud: 01.10.2001
|
|
| Kommentaarid: 461 loe/lisa |
Kasutajad arvavad: |
   |
:: |
12 :: |
7 :: |
356 |
|
| tagasi üles |
|
 |
DVDRW
HV Guru
liitunud: 13.10.2003
|
21.02.2015 13:24:46
|
|
|
| Esimene asi uue arvutiga on alati format c: anyway. Asutuses imaged peale.
|
|
| Kommentaarid: 27 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
26 |
|
| tagasi üles |
|
|
Andrus Luht
itimees.ee
liitunud: 11.06.2002
|
|
| Kommentaarid: 377 loe/lisa |
Kasutajad arvavad: |
|
:: |
5 :: |
1 :: |
318 |
|
| tagasi üles |
|
|
Renka
HV Guru
liitunud: 01.04.2002
|
|
| Kommentaarid: 71 loe/lisa |
Kasutajad arvavad: |
|
:: |
2 :: |
1 :: |
61 |
|
| tagasi üles |
|
|
Dogbert
HV Guru
liitunud: 03.05.2004
|
|
21.02.2015 14:29:51
|
|
|
Ahah, nüüd lendas kaka ventikasse - man-in-the-middle rünne krüpteeritud ühendusele otse kasutaja arvutis.
Sellest ma üritasin paaril korral rääkida, kui pushiti mobiil-ID kasutamist ja kinnitati, et see on täpselt sama turvaline kui ID-kaart.
Minu vastuväide oli, et ID-kaart tekitab turvalise saidiga ühendust luues kahepoolselt sertifikaatide abil autenditud krüpteeritud tunneli, samas kui mobiil-ID puhul on tunnel küll saidipoolselt autenditud, kliendi pooleks aga võib olla niihästi brauser kui brauseri ühendust "vahendav" MITM tarkvara, sest kliendilt sel juhul sertifikaati ei nõuta.
Siis muidugi väideti mulle vastu, et sellist MITM rünnet on võimatu korraldada, samas kui minupoolselt oli näiteks toodud juba sellist süsteemi kasutavad antiviirused, nagu ESET NOD32 ja Avast, mis kliendi soovi korral kontrollivad ka krüpteeritud kanalite kaudu liikuvat datat, kasutades selleks oma CA sertifikaati.
Sarnase ründe puhul turvalise saidiga ühendust luues kuulab ühendust pealt masinas istuv tarkvara - varemalt siis antiviirus, nüüd superfish.
Nüüd siin tulebki välja ID-kaardi erinevus ja eelis mobiil-ID ees - ID-kaardiga sellisel juhul turvalise saidiga ühendust luua ei saa, tegevus lõpeb veateatega, sest serverist saadetud, kliendi avaliku võtmega krüpteeritud datat on võimalik avada vaid kliendi ID-kaardil asuva salajase võtme abil - kui kliendil seda võtit ei ole, sessioon katkeb ja krüpteeritud kanalit ei looda.
Mobiil-ID kasutamisel ei erine aga brauseri seanss turvalise serveriga millegi poolest sinna parooli või paroolikaardi või PIN-generaatoriga sisselogimisest - ühendus töötab vaatamata sellele, et krüpteeritud data vahepeal lahti krüpteeritakse, sest sait ei oota kliendilt sertifikaati ega saada kliendile kliendi sertifikaadis sisalduva avaliku võtmega krüpteeritud datat, kontrollimaks, kas ta seda isikliku salajase võtmega avada suudab, siin piisab serverile pärast krüpteeritud kanali loomist ainult klaviatuurilt sisestatava koodi klappimisest. Server ei suuda seejuures aga kuidagi eristada, kas ta "räägib" otse kliendi brauseriga või brauseri ühendust vahendava MITM ründetarkvaraga.
Ainus võimalus sarnase ründe avastamiseks on tähelepanelik klient ise, sest sarnase ründe korral näeb ta brauseri aadressireal mitte turvalise serveri sertifikaati, vaid rünnet teostava tarkvara oma. NOD32 ja Avasti puhul see nii ongi - klient näeb saidi serdi asemel antiviiruse oma. Kui ta ise aga krüpteeritud kanalite kontrolli sisse lülitas, ei ole see talle probleemiks. Ma oletan, et just nii ka Superfishi nuhkimine avastati - tähelepanelik kasutaja nägi aadressireal saidi serdi asemel Superfishi oma.
Sellist tüüpi rünnet muidugi ei pea teostama otse arvutis, piisab pealtkuulamisest kusagil vahepeal - pealkuulajal on vaid vaja brauseri poolt tunnustatud juurserdiga genereeritud CA-d.
Muidugi, kui otseselt arvutisse on juba selline ligipääs olemas, et sinna MITM tarkvara saab paigaldada, pole suuremaks probleemiks ka brauseri CA juursertide kogu asendada pärissertide asemel libasertidega, mis kõik kuuluvad MITM rünnet teostavale tarkvarale, ainult serdi omaniku nimi on igaühel erinev. Ja sel juhul ei märka klient enam üldse mingit erinevust turvalise ja pealtkuulatava ühenduse vahel - rünnet teostav tarkvara esitab kliendile igale saidile vastava nimega libaserdi, brauser võrdleb seda oma juursertide kogus oleva liba-juurserdiga ning tunnistab autentseks - aadressireal on "autentne" sert õige nimega. Problem solved - mobiil-ID tegutseb edasi, ID-kaardiga ühendus ei toimi.
Muide - sama mis kehtib mobiil-ID puhul, kehtib ka kõikvõimalike muude mobla või muu sekundaarse kanali abil "kahepoolseks" muudetud autentimiste puhul nagu Google ja Microsoft jms - tehniliselt on need pealtkuulatavad turvalist saiti pakkuvasse serverisse sisse murdmata - piisab kliendipoolse turbe kompromiteerimisest.
ID-kaardi vm krüptoseadmega kahepoolselt krüpteeritud kanali pealtkuulamiseks peab aga ründe teostajal olema koopia serveri salajasest privaatvõtmest. Seda on juba tunduvalt raskem hankida. (nt Lavabit vs FBI).
Wikist kopeeritud tekst tavalisest TLS handshake'ist ja kliendi autentimisega TLS handshake'ist:
(Autentimiseks loetakse siin ikkagi krüptograafilist autentimist, mitte brauserist paroolide või koodide sisestamist - ei maksa neid segi ajada. Paroolikaardi, PIN-generaatori, Mobiil-ID, Google Authenticatori või postituviga saadetud koodi sisestamise ajaks on brauseri sessioon juba kompromiteeritud - krüptograafilises mõttes ei erine need üksteisest mitte millegi poolest)
| Wikipedia: TLS Handshake kirjutas: |
 Spoiler
Basic TLS handshake
A simple connection example follows, illustrating a handshake where the server (but not the client) is authenticated by its certificate:
Negotiation phase:
A client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number, a list of suggested cipher suites and suggested compression methods. If the client is attempting to perform a resumed handshake, it may send a session ID.
The server responds with a ServerHello message, containing the chosen protocol version, a random number, CipherSuite and compression method from the choices offered by the client. To confirm or allow resumed handshakes the server may send a session ID. The chosen protocol version should be the highest that both the client and server support. For example, if the client supports version 1.1 and the server supports version 1.2, version 1.1 should be selected; 1.0 should not be selected.
The server sends its Certificate message (depending on the selected cipher suite, this may be omitted by the server).[203]
The server sends its ServerKeyExchange message (depending on the selected cipher suite, this may be omitted by the server). This message is sent for all DHE and DH_anon ciphersuites.[2]
The server sends a ServerHelloDone message, indicating it is done with handshake negotiation.
The client responds with a ClientKeyExchange message, which may contain a PreMasterSecret, public key, or nothing. (Again, this depends on the selected cipher.) This PreMasterSecret is encrypted using the public key of the server certificate.
The client and server then use the random numbers and PreMasterSecret to compute a common secret, called the "master secret". All other key data for this connection is derived from this master secret (and the client- and server-generated random values), which is passed through a carefully designed pseudorandom function.
The client now sends a ChangeCipherSpec record, essentially telling the server, "Everything I tell you from now on will be authenticated (and encrypted if encryption parameters were present in the server certificate)." The ChangeCipherSpec is itself a record-level protocol with content type of 20.
Finally, the client sends an authenticated and encrypted Finished message, containing a hash and MAC over the previous handshake messages.
The server will attempt to decrypt the client's Finished message and verify the hash and MAC. If the decryption or verification fails, the handshake is considered to have failed and the connection should be torn down.
Finally, the server sends a ChangeCipherSpec, telling the client, "Everything I tell you from now on will be authenticated (and encrypted, if encryption was negotiated)."
The server sends its authenticated and encrypted Finished message.
The client performs the same decryption and verification.
Application phase: at this point, the "handshake" is complete and the application protocol is enabled, with content type of 23. Application messages exchanged between client and server will also be authenticated and optionally encrypted exactly like in their Finished message. Otherwise, the content type will return 25 and the client will not authenticate.
Client-authenticated TLS handshake
The following full example shows a client being authenticated (in addition to the server like above) via TLS using certificates exchanged between both peers.
Negotiation Phase:
A client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number, a list of suggested cipher suites and compression methods.
The server responds with a ServerHello message, containing the chosen protocol version, a random number, cipher suite and compression method from the choices offered by the client. The server may also send a session id as part of the message to perform a resumed handshake.
The server sends its Certificate message (depending on the selected cipher suite, this may be omitted by the server).[203]
The server sends its ServerKeyExchange message (depending on the selected cipher suite, this may be omitted by the server). This message is sent for all DHE and DH_anon ciphersuites.[2]
The server requests a certificate from the client, so that the connection can be mutually authenticated, using a CertificateRequest message.
The server sends a ServerHelloDone message, indicating it is done with handshake negotiation.
The client responds with a Certificate message, which contains the client's certificate.
The client sends a ClientKeyExchange message, which may contain a PreMasterSecret, public key, or nothing. (Again, this depends on the selected cipher.) This PreMasterSecret is encrypted using the public key of the server certificate.
The client sends a CertificateVerify message, which is a signature over the previous handshake messages using the client's certificate's private key. This signature can be verified by using the client's certificate's public key. This lets the server know that the client has access to the private key of the certificate and thus owns the certificate.
The client and server then use the random numbers and PreMasterSecret to compute a common secret, called the "master secret". All other key data for this connection is derived from this master secret (and the client- and server-generated random values), which is passed through a carefully designed pseudorandom function.
The client now sends a ChangeCipherSpec record, essentially telling the server, "Everything I tell you from now on will be authenticated (and encrypted if encryption was negotiated). " The ChangeCipherSpec is itself a record-level protocol and has type 20 and not 22.
Finally, the client sends an encrypted Finished message, containing a hash and MAC over the previous handshake messages.
The server will attempt to decrypt the client's Finished message and verify the hash and MAC. If the decryption or verification fails, the handshake is considered to have failed and the connection should be torn down.
Finally, the server sends a ChangeCipherSpec, telling the client, "Everything I tell you from now on will be authenticated (and encrypted if encryption was negotiated). "
The server sends its own encrypted Finished message.
The client performs the same decryption and verification.
Application phase: at this point, the "handshake" is complete and the application protocol is enabled, with content type of 23. Application messages exchanged between client and server will also be encrypted exactly like in their Finished message. |
|
Muu lugemismaterjal:
http://security.stackexchange.com/questions/23880/why-a-client-authentication-is-not-commonly-performed-in-the-tls-protocol
http://security.stackexchange.com/questions/20803/how-does-ssl-tls-work
_____________________
Parandus pärast väikest mälu värskendamist asümmeetrilise krüpteeringu ja brauseri krüpteeritud seansside loomise kohta. Jutu point jääb samaks, pisidetailid erinevad - mobiil-ID ei ole MITM ründe puhul turvaline, ID-kaart on.
Lisatud soovituslik lugemismaterjal.
_________________
Tee inimesele lõke ja tal on soe üheks päevaks, pista ta põlema ja tal on soe elu lõpuni. (Terry Pratchett)
e.k spikker: muhk on kumer, lohk on nõgus.
viimati muutis Dogbert 21.02.2015 18:54:44, muudetud 9 korda |
|
| Kommentaarid: 33 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
32 |
|
| tagasi üles |
|
|
Forss
HV kasutaja
liitunud: 11.04.2004
|
|
| Kommentaarid: 1 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
1 |
|
| tagasi üles |
|
|
ebardkonn
HV kasutaja
liitunud: 12.12.2002
|
|
| Kommentaarid: 6 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
5 |
|
| tagasi üles |
|
|
mikk36
HV Guru
liitunud: 21.02.2004
|
|
21.02.2015 17:20:25
|
|
|
Analoog Androiditelefonide Google Play Editionitele 
|
|
| Kommentaarid: 85 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
2 :: |
78 |
|
| tagasi üles |
|
|
enigma
Kreisi kasutaja
liitunud: 13.05.2004
|
|
21.02.2015 19:30:17
|
|
|
Kas siis Lenovo arvuteid müüakse poole hinnaga?
Peaks olema ju loogiline et reklaamide pealt teenib Lenovo hiljem raha tagasi.
|
|
| Kommentaarid: 33 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
32 |
|
| tagasi üles |
|
|
Tanel
HV Guru
liitunud: 01.10.2001
|
|
| Kommentaarid: 461 loe/lisa |
Kasutajad arvavad: |
|
:: |
12 :: |
7 :: |
356 |
|
| tagasi üles |
|
|
jägaja
HV Guru
liitunud: 06.08.2004
|
|
22.02.2015 21:52:02
|
|
|
| DVDRW kirjutas: |
| Esimene asi uue arvutiga on alati format c: anyway. Asutuses imaged peale. |
Seda ainult juhul, kui sisepoliitika seda ette näeb.
Suures osas ettevõtted ostavad arvuti koos tarkvaraga ja kõige kaasatulevaga. Enamus eraisikuid ei hakka ka miskit ümbert installima.
_________________
" Maailm on täis kõikvõimalike külatarkade kogukondi, kelle ühine joon on teadus- ja tõenduspõhisele elukäsitusele vastandumine." |
|
| Kommentaarid: 133 loe/lisa |
Kasutajad arvavad: |
|
:: |
1 :: |
0 :: |
120 |
|
| tagasi üles |
|
|
rex
HV Guru
liitunud: 09.01.2002
|
|
23.02.2015 01:18:09
|
|
|
| Suuremates asutustes on corp litsentsid ja kõik arvutid käivad enne kasutajateni jõudmist riistakambrist läbi. Pannakse domeeni ja võetakse kasutajalt õigused oma peaga midagi soperdada.
|
|
| Kommentaarid: 247 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
226 |
|
| tagasi üles |
|
|
DVDRW
HV Guru
liitunud: 13.10.2003
|
|
23.02.2015 12:06:13
|
|
|
Meie puhul pikendaks see tarneaega ~3n + midagi on kindlasti puudu/valesti/ununenud/vahepealuut jne. Kindlam kui arvutid kohal ja ise uptodate image panna. Kui alla 300tk.
Windows litsents on BIOSi põletatud niiet mingit jama koodidega ka pole
|
|
| Kommentaarid: 27 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
26 |
|
| tagasi üles |
|
|
d3t
HV Guru
liitunud: 14.05.2004
|
|
25.02.2015 10:44:14
|
|
|
Via: NISTs National Vulnerability Database 2014
_________________
next.Insiders - koht mängijatele ja tehnikahuvilistele toredaks ajaveetmiseks.
PT: Sony XE90 & LG C1 värvi kalibreerimine
Lecktor - 3D printerid ja lisatarvikud, Voron, Prusa jne |
|
| Kommentaarid: 85 loe/lisa |
Kasutajad arvavad: |
|
:: |
1 :: |
0 :: |
72 |
|
| tagasi üles |
|
|
enigma
Kreisi kasutaja
liitunud: 13.05.2004
|
|
28.02.2015 19:48:56
|
|
|
AVG viirustõrje tunnistas Lenovo Superfishi väga ohtlikuks.
http://bit.ly/1N2QeFM
viimati muutis enigma 28.02.2015 20:00:36, muudetud 1 kord |
|
| Kommentaarid: 33 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
32 |
|
| tagasi üles |
|
|
rex
HV Guru
liitunud: 09.01.2002
|
|
28.02.2015 20:00:04
|
|
|
| Paistab, et Thinkpad'idega ei julgenud seda mängu mängida.
|
|
| Kommentaarid: 247 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
226 |
|
| tagasi üles |
|
|
DVDRW
HV Guru
liitunud: 13.10.2003
|
|
01.03.2015 07:09:09
|
|
|
| Äriklassiläpakates seda pole jah.
|
|
| Kommentaarid: 27 loe/lisa |
Kasutajad arvavad: |
|
:: |
0 :: |
0 :: |
26 |
|
| tagasi üles |
|
|
Tanel
HV Guru
liitunud: 01.10.2001
|
|
| Kommentaarid: 461 loe/lisa |
Kasutajad arvavad: |
|
:: |
12 :: |
7 :: |
356 |
|
| tagasi üles |
|
|
Betamax
HV Guru
liitunud: 29.05.2003
|
|
| Kommentaarid: 690 loe/lisa |
Kasutajad arvavad: |
|
:: |
1 :: |
1 :: |
532 |
|
| tagasi üles |
|
|
|
:: KKK
:: otsing 
:: statistika
:: kasutajate nimekiri
:: kasutajate grupid
:: registreeri
