webhosting by: WebSupport.sk                                             UnlimitedHosting | CustomHosting | FreeWeb.sk

2. dil brutalniho blogoveho serialu o brutalnich IT vydobytcich - Brutalne bezpecne, brutalni webove aplikace :-D

Guys premysleli jste nekdy o tom ze spojeni pres SSL nemusi byt zrovna bezpecne? Ze vlastne staci ukrast SSL certifikat, nasadit na klienta (zejmena) nejaky spyware, nebo vyuzit jedne z nemalo der SSL?

Ja taky, tak sem skocil na google a nasel velmi zajimavou vec, jmenuje se JavaScrypt (ne vazne to neni gramaticka chyba, jen je to nikoliv nahodna podobnost s nastrojem Vam vsem kdo mate co docineni s tvorbou www dobre znamym).

No ono ...crypt uz asi napovida sve, ale pojdme se na to podivat bliz ...

Nejaka nudna fakta k historii a tak:
Tuto vec dali dohromady panove z Fourmilab, v techto laboratorich take napr. vznikl AutoCAD a jeste par dalsich slavnych "hracek". Protoze to neni cilem tohohle clanku nebudu tady historii rozebirat... jiste Vam koho to zajima postaci uz uvedenej odkaz a google.com :-).

Takze k veci...
Tahle vec je vlastne tak trochu splneny sen kazdyho solidniho programatora bezpecnych webovych aplikaci.
Kdyz to reknu ve zkratce je to kompletni AES sifrovani napsane v cistem JavaScriptu, teda jedina vec ktera je na strane klienta potreba je standartni podpora JavaScriptu. Takze uz se nemusite spolehat na nespolehlive a na strane klienta casto dost blbe fungujici SSL.

Cely balicek, ma v zazipovane forme sice nejakych 350 KB, ale nelekejte se, je tam vsechno mozne vcetne dokumentace a dalsich vychytavek jako napriklad Steganograficke knihovny napsane taktez v JavaScriptu!!! (taky se mi tomu nechtelo verit)...
O prikladech a dalsi dokumentaci samozrejme nemluve...
Stezejni soubory, ktere budete skutecne potrebovat maji asi 30 KB.
Jo a jeste jedna perlicka ... nepodporuje to nic jineho nez 256 bitu dlouhe AES klice (diky za upozorneni v komentarich, puvodne tu bylo 2048 bitu, coz je samozrejme chyba, nejvyssi delka je dle standartu AES prave 256 bitu) .

Co se tyce praktickeho pouziti v praxi:
-Bezpecni webmailovi klienti
-Bezpecny online document sharing
-Informacni systemy
-A tak podobne

Je to stale sice ponekud narocne na "systemove zdroje" (na mojem komplu - Sempron 2300, 512 MB RAM to chodi skvele, zdrzeni je asi tak velke jako u kalkulacky v JavaScriptu - tj. zadne :-)), ale pri vykonu dnesnich pocitacu bych se toho az tak nebal (neni to zadna novinka bylo to napsano uz pred par lety). Jedine co by mohl byt problem jsou nekvalitni prohlizece (at zije M$ Exploder).
Implementujeme tuhle vec do naseho weboveho IS takze jakmile budeme mit nejaky funkcni a zajimavy kod samozrejme se ve stylu OpenSource pochlubim :-).

nautiluZ

Odkazy:
Hlavni stranka projektu JavaScrypt

Balíček (zip) ke stazeni

Tutorial

Steganograficka hracka :-)

Ukazkova utilitka na sifrovani textu

Dalsi viz. stranky...

Average rating
(0 votes)

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

haluzny clanok

uz len kvoli tomuto som sa tu registroval, takze:
1. AES je symetricka sifra, a ak vam hovori nieco key agreement tak nebudete pisat bludy o tom ze riesi problemy ktore ma SSL (ak ste narazali na Man In The Middle a veci s tym suvisiace)
2. v tom ze SSL je problemove v porovnani iba s AES uz z principu nemozem suhlsit - pretoze porovnavat SSL a AES sa jednoducho neda.
3. AES je efektivne iba do urcitej velkosti kluca (je na to matematicky dokaz) potom je to uz iba o spomaleni kodovania, a zrejme si to pletiete s RSA. A 2048 bit. kluc (symetricky) je iba neprakticka haluz. Prirovnal by som to k tomu ze mate k vasmu trezoru namiesto standardneho kluca, kluc o dlzke 1.5 metra a budete tvrdit ze je podstatne bezpecnejsi :)

a) nepsal sem ze resi

a) nepsal sem ze resi problemy SSL, ale ze muze byt v nekterych pripadech vhodnejsi nez SSL.

b) Ne tak to mysleno nebylo, vetsina problemu SSL nesouvisi s siframi ale z jeho architekturou a mizerne napsanym kodem.

c) Z toho vychazi, ze neporovnavam "sifrovaci schopnosti" obou systemu. Nicmene mi slo o to predstavit i rozdilnou moznost zabezpeceni prenosu dat...
Uvedomte si ze se jedna pouze o knihovnnu, ktera navic neni vhodna na proudove sifrovani dat. Rozhodne neslo o porovnavani cehokoliv

d) AES ma sice prokazane slabiny ale o problemu spojenem s delkou klice o kterem tady mluvite sem nenasel ani zminku.

e) Take by me velmi zajimalo jak jste prisel na to ze AES je symetricka sifra... on je to totiz v prve rade standart, jako ktery byla adoptovana puvodni sifra Rijndael.

f) Doporucuju prostudovat stranky projektu

rtfm

a. vhodnejsie v ziadnom pripade nie je. Pretoze v kazdom pripade musite ku klientovi dostat sifrovaci kluc. A kedze AES NIE JE ! asymetricka sifra tak uz trivialny sniffer degraduje cely tento system.

b. niekdy v roku 1998 som zaznamenal prvu opensource verziu ssl (ssleay). Navyse implementacii je hned niekolko a staci si vybrat. Ak narazate na parcialne problemy s SSL tak vzdy to bolo o nejako pretecenom buffri a.p a vzdy iba pre nejaku platformu a implementaciu. Nikdy sa vsak neobjavil architektonicky problem. Tu vazne odporucam RTFM skor nez zacnete robit taketo zavery.
c. AES je pouzivane pre prudove sifry ! Niekolko sat digi vysielani sifruje prenos prave pomocou AES, tu tiez odporucam najskor citat a potom pisat !
d,e. RTFM ! nic ine k tomu nemozem napisat.
f. projekov kde aj samotny autor nepochopil riesenu problemtiku som uz videl mrte, a toto je zrejme dalsi z nich.

tato implementace neni

tato implementace neni vhodna pro proudove sifrovani, netvrdim ze AES
O tom ze se pomoci ni sifruje nejen tv vysilani vim.

Vymena klice se da konkretne V TOMTO pripade zajistit napr, vymenou pres obrazkove logo (steganografie).
Opet zdurazuji ze tu nesrovnavam dva sifrovaci systemy, ale dve mozna reseni a d zduraznil sem ze to jedno je v podstate pokusna zalezitost (JavaScrypt)

bhole's picture

zaujimave

zaujimava haluz. toto by ma nikdy nenapadlo. aj ked stale mam dojem, ze bezpecnejsi je normal default ssl :).

je a neni...

V prve rade SSL je vse-unvierzalni zalezitost coz je sice na jednu stranu skvela vec, ale na strane druhe to prinasi pomerne velkou spoustu zranitelnosti...

Jasne ze tohle je spis zatim porad tak trochu pokusna zalezitost, ale myslim ze se to da vyuzit najma pro sifrovani hesel. Jako nejvetsi bolest vidim asi vymenu klice... No nicmene ve spojeni ze steganografickou knihovnou by se to dalo pouzit k overeni sessionu mezi klientem a serverem... Asi takto na strane serveru se do stranky prida logo do loga se schova nejaka sekvence, napr. pri odesilani formulare se tento obrazek odesle spolu s nim (jasne musi byt soucasti formu... ). Server overi obrazek a hotovka :-)

Druha moznost skryvat takto Cookie v nezabezpecene relaci, vymenovat klice atd. (tady se narozdil od prvniho prikladu pouzije i client side...).

No i me to zni celkem psyxo ale kdo vi co bude za par let bezne pri dnesni situace co se bezpecnosti na webu tyce :-)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
webhosting by: WebSupport.sk UnlimitedHosting | CustomHosting | FreeWeb.sk