|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
titulok
Od: komunista
|
Pridané:
11.4.2014 12:12
I riekol pán: "Veru veru hovorím Vám, blahoslavení nezašifrovaní, lebo ich je kráľovstvo nebeské. Lebo neviete dňa ani hodiny ajhľa príde pán domu a rozšifruje všetko!"
|
|
Re: titulok
Od: balada
|
Pridané:
11.4.2014 12:19
Amen
Ako sa dajú odstrániť z Windowsu tie hlášky o nebezpečnosti šifrovaného spojenia po vyťukani https?
|
|
Re: titulok
Od: hmghmgh
|
Pridané:
11.4.2014 12:28
neviem presne co mas na mysli, ale odporuca sa vymazanie vsetkych klucov (keyring). neviem ako sa to robi vo windowse, v linuxe je to jeden adresar.
za druhe, niektore stranky tiez menili certifikaty (napriklad websupport) a teraz si prehliadac vyhadzuje hlasky na import nveho kluca (hoci nechapem co vo websupporte treba manualne importovat ked by mali byt podpisany CA ktoru browser akceptuje).
za tretie, mozes mat len nejake spojenia na https strank co idu cez http (pludiny, iframy, reklamy atd) a vtedy hazde hlasku, ze niektore info je nezabezpecene
|
|
Re: titulok
Od: balada
|
Pridané:
11.4.2014 12:42
Do prehliadača napíšeš adresu s https, napríklad https://www.microsoft.com/ . Vo Windowse naskočí okno, že ide o nebezpečnú stránku a či chceš pokračovať. Treba tri krát kliknúť aby sa stránka zobrazila. Mnohých to odradí túto stránku navštevovať. Ako sa dá to dialógové okno vypnúť? Asi niekde v ovládacích paneloch.
|
|
Re: titulok
Od: Stanley83
|
Pridané:
11.4.2014 14:59
Nemas nahodou zly datum na pc? Skus nastavit aktualny datum
|
|
Re: titulok
Od: jozinzbazin256
|
Pridané:
11.4.2014 20:44
tiez si myslim, ze to to bude zlym datumom na PC. Na zmenu certifikatu prehliadac neupozrnuje (iba na neplatnost), bezne certifikaty exspiruju a su vydavane nove a menene na serveroch... to by bolo zybytocne kedze tak ci tak certifikat je platny.
Ine je potrebe upozornovat pri pripajani na ssh tunel ze certifikat (verejne kluce) cieloveho servera boli zmenene... tam to ma vyznam... poss. MITM attack
|
|
Re: titulok
Od: VYSVETLENIE
|
Pridané:
14.4.2014 22:39
tu
http://dopice.sk/99d
|
|
Kto nepozna heartbleed
Od: asdasdfasdf
|
Pridané:
11.4.2014 12:22
Toto je vysvetlenie, ktore pochopi aj vasa stara mama: http://xkcd.com/1354/
|
|
Re: Kto nepozna heartbleed
Od: Babicka
|
Pridané:
11.4.2014 12:43
Ďakujem, Janíčko môj.
|
|
Re: Kto nepozna heartbleed
Od: bfgbfbf
|
Pridané:
12.4.2014 13:19
tazko ked nevie po anglicky
|
|
open source
Od: linux hero
|
Pridané:
11.4.2014 13:41
a hla! krasy a vyhody otvoreneho kodu!
kde sa hrabe zly, uzavrety kod, do ktoreho ma pristup len par vyvolenych ludi, kde je vsetko dokonale preverene a kde vsetko funguje tak ako ma...
|
|
Re: open source
Od: XMen
|
Pridané:
11.4.2014 14:00
heh pan je optimista
|
|
Re: open source
Od: Hroch_asd
|
Pridané:
11.4.2014 22:42
A poriadny optimista :). Podla jeho zmyslania su Windows updaty nepotrebne.
|
|
robil to vôbec
Od reg.: Fresco
|
Pridané:
11.4.2014 14:28
niekto kto tomu rozumel ??... ako môže aplikácia bez vedomia programátora robiť toto :
"zraniteľná verzia nakopírovala do odpovedacieho paketu 64 KB dát z pamäte susediacej s umiestnením spracovávanej správy s požiadavkou."
aspoň to mala XORnúť a bol by pokoj
|
|
Re: robil to vôbec
Od reg.: Marki555
|
Pridané:
11.4.2014 14:36
jednoducho...
prijmes paket, ulozis si ho do pamate. Zostavujes paket s odpovedou, z povodneho si precitas velkost dat, ktore mas poslat naspat a zacnes ich kopirovat z povodneho paketu do noveho.
No a co ze v povodnom tych dat tolko nebolo :) skopiruje sa to co v pamati nasleduje za nim.
Chyba je samozrejme v tom, ze si si na zaciatku neskontroloval, ci udavana velkost dat suhlasi so skutocne prijatym paketom.
|
|
Re: robil to vôbec
Od: suxi
|
Pridané:
15.4.2014 7:40
preco by bol po xorovani pokoj? a vobec, co to trepes za nezmysly? ak tomu nerozumies, pekne ticho suchaj nohami a nestrapnuj sa...
|
|
beat vs. bleed
Od: gandy
|
Pridané:
11.4.2014 14:43
Ak by to bolo spomenute iba raz, tak to zoberiem ako pekny pokus o ironiu, ale takto to skor beriem ako diletanstvo zo strany autora spravicky. (HINT: heartbeat vs. heartbleed)
|
|
Re: beat vs. bleed
Od reg.: Fresco
|
Pridané:
11.4.2014 14:52
heart beat je tá odpoved či spojenie žije
|
|
Re: beat vs. bleed
Od: kekeket
|
Pridané:
11.4.2014 20:16
heartbeat je extension pre openssl
heartbleed je zranitelnost v nom.
|
|
Re: beat vs. bleed
Od: heartbeat... heartbleed
|
Pridané:
11.4.2014 21:08
ano, a kedy a zacnu predavat tie tricka z krvacajucim srdcom? dobra ironia heartbeat... heartbleed
|
|
Kolega
Od: MisoMM
|
Pridané:
11.4.2014 16:05
Hehehe, to je moj kolega :) Pozeram jak puk, ze co to :)
|
|
Výmena hesiel
Od: Bubuntu
|
Pridané:
11.4.2014 17:48
Takže by som mal asi vymeniť zopár hesiel..
|
|
Re: Výmena hesiel
Od: lal
|
Pridané:
11.4.2014 20:02
len si daj pozor odkial ich budes menit, aby nechytali prave tieto :-P
|
|
Re: Výmena hesiel
Od: Bubuntu
|
Pridané:
12.4.2014 9:04
Tak hádam som použil zabezpečené pripojenie.
Inak je to celkom fuška, všetko pomeniť, otestovať, potriediť v keepassx, vymazať dávno zabudnuté účty...
|
|
openssl heartbeat
Od: developer1024
|
Pridané:
11.4.2014 21:06
1) Ja len nerozumiem tomu poreco rozsirenie heartbeat bolo implementovane ako bolo... teda este je. V principe ide o keep-alive. Preco moze klient poslat cokolvek do 65kB a to iste ma dostat spat? Nestacilo pre overenie ci spojenie existuje odoslat len jeden bajt a ten isty dostat spat? Nemohlo by sa stat to co sa stalo.
2) Pripajam zaujimave veci
- autorom commitu s rozsirenim aj fixom je Dr. Stephen Henson
- osudny commit zo dna (a pozor kedy!) 1.1.2012 o 00:59 (ano, na silvestra!): http://goo.gl/8tZNxU
- commit s fixom zo dna 7.4.2014: http://goo.gl/zyx9wB
V podstate cely fix je v par riadkoch kodu (overenie hranic):
if (1 + 2 + payload + 16 > s->s3->rrec.length)
return 0; /* silently discard per RFC 6520 sec. 4 */
|
|
Re: openssl heartbeat
Od: developer1024
|
Pridané:
11.4.2014 21:18
este RFC pre heartbeat:
https://tools.ietf.org/html/rfc6520#section-4
|
|
Re: openssl heartbeat
Od: asdfsdfasdfff
|
Pridané:
12.4.2014 1:25
Lubovolny paket do 65kB je tam na MTU discovery. Na tejto vrstve by to nemalo byt treba, ale dali tam tu moznost.
Malokto pocita pri navrhu s tym, ze bude v implementacii diera. Keby sa malo navrhovat s tym, ze to niekto zle naimplementuje, tak sa nemoze navrhnut nic.
|
|
Re: openssl heartbeat
Od reg.: Trovaricon
|
Pridané:
12.4.2014 12:53
Na tejto vrstve sa nema co zistovat MTU. "Pingovat" 65k by som nedovolil ani po lokalnej sieti a nie to cez internet. Vsade su statistiky ako rastie z roka na rok vytazenie uzlov / chrbticovych sieti - nikto ale neuvadza kolko z toho je realny narast informacneho toku a kolko je komunikacny overhead.
napr. cloveka co prisiel v minulosti s napadom posielat binarne data zakodovane ako base64 string by som dal lyncovat na namesti.
|
|
Re: openssl heartbeat
Od: asdfsdfasdfff
|
Pridané:
12.4.2014 14:28
> Na tejto vrstve sa nema co zistovat MTU
To je prave otazka. Vyssie som pisal, ze by to nemalo byt treba. Ina vec je, ze ked je program schopny to zistit, tak dokaze komunikovat efektivnejsie uz len tym, ze pripravuje pakety, ktore nemusia byt fragmentovane. A pri "vrstve naviac", akou je SSL, sa usporeny cas vzdy hodi.
Vo vseobecnosti - vrstvy su dobra vec, ale niekedy sa hodi ich obchadzat. Clovek si povie, ze by aplikacnu vrstvu nemalo zaujimat nic mimo vrstvu pod nou. Ale potom si uvedomi, ze uzivatel by sa od OS rad dozvedel, ze si vykopol kabel (fyzicka vrstva). Alebo niekedy sa aplikacii hodi vediet svoju IP, aby podla nej vybrala najlepsiu "druhu stranu".
> "Pingovat" 65k by som nedovolil ani po lokalnej sieti a nie to cez internet.
Ak myslis "take domace pinganie", tak tam to velmi nedava vyznam. Ak to posles s priznakom DNF (alebo pingas na IPv6), potom to uz moze davat vyznam. Napr: pri uvahe "preco miestami pada spojenie?" alebo na vacsej sieti "nestoji jumbo ramcom nieco v ceste?"
|
|
Re: openssl heartbeat
Od reg.: Trovaricon
|
Pridané:
12.4.2014 15:25
Ja velmi dobre viem ako je to s tym zistovanim MTU myslene.
Noze, pripojenie akou technologiou pre koncovych pouzivatelov pouzivanou DNES podoruje MTU aspon radovo porovnatelne so spominanym limitok 65k?
Inak... kto povedal, ze 2 po sebe nasledujuce TCP pakety pojdu rovnakou cestou k cielu? "Jaj, no hej to je vlastne pravda" by pravdepodobne znela odpoved predkladatela keby bo konfrontovany takou otazkou - a uz je nasa "optimalizacia" v p***.
Uz som mal "tu cest" neveriaco krutit hlavou pri implementacii nejedneho protokolu "podla specifikacie niecieho mokreho sna". Dych mi vyrazilo vsak az kodovanie binarnych dat ako ascii hexa kod > t.j. 100% overhead
|
|
Re: openssl heartbeat
Od: som to zase ja
|
Pridané:
12.4.2014 15:56
Na tom, ci su alebo nie su take technologie az tak velmi nezalezi. Ak je MTU navrhom obmedzene na 65k, tak mi nedava zmysel vymyslat si iny limit specialne pre tento ucel, ktort by neskor nemusel stacit. To su zbytocne starosti naviac.
Spominany limit je nie nahodou zapisatelny ako 2B, takze sa nikto o nic nestara, len to precita. 1B by dal limit 255, co je na dnesne siete malo.
Takze navrhujes pridelit nieco ako 11b a zlozito to odtial vytahovat, byt umyselne nekompatibilny s novsimi technologiami a v podstate nic neziskat? (na zapis 11b budu stale treba 2B)
|
|
Re: openssl heartbeat
Od reg.: Trovaricon
|
Pridané:
12.4.2014 16:30
Ze "zlozito" vytahovat... Ok zasmiali sme sa. Kto neovlada bitove operacie tak nech radsej nestrka ruky do navrhu ani implementacie komunikacnych protokolov.
Cele je to ale o tej istej veci ako nedavny problem s goto v overovani SSL v Apple systemoch. Nieco taketo nemohlo prejst serioznym code review. odliadnuc od toho ze staticka analyza kodu nieco take nedovoli (unreachable code pri goto)
Zaradit memcpy operaciu pri spracovani poziadavky klienta s parametrom size (count) KTORY MI ON POSLAL > tak to je vazne na zamyslenie. Totalne diletantska robota pri implementacii. Ak sa niekomu nechce explicitne kontrolovat kazdu takuto spravu, tak nech si laskavo napise 2 kilobajtovu kniznicu na "safe array" a vsetky datove operacie ktore bude dana trieda vystavovat vnutri osetri.
Po code reviews a tyzdnovom opakovanom odmietani commitu lebo dotycny nebol v stave vsade posunut hodnotu o jeden bit vsak viem, ze o takychto programatorov nie je nudza.
|
|
Re: openssl heartbeat
Od: stale som to ja
|
Pridané:
12.4.2014 17:36
"Nieco taketo nemohlo prejst serioznym code review."
Clovek nie je pocitac a vela chyb prehliadne (naviac je ho mozne peniazmi alebo silou prinutit, aby sa az tak dobre nepozeral).
"Zaradit memcpy operaciu pri spracovani poziadavky klienta s parametrom size (count) KTORY MI ON POSLAL [...] Totalne diletantska robota pri implementacii."
Mohla to byt aj klasicka chyba. Este stale ide aj o vykon a duplicitne kontroly sa zvyknu v niektorych projektoch vyhadzovat (inde sa menia na asserty, co by tu nic nezmenilo). A ked tam nahodou bola povodne kontrola 2x, 1 vyhodil jeden clovek, druhu druhy, neskontrolovany merge a mame to.
"nech si laskavo napise 2 kilobajtovu kniznicu na "safe array" a vsetky datove operacie ktore bude dana trieda vystavovat vnutri osetri."
Myslim, ze toto nemaju prave kvoli tomu vykonu. A ostatne, keby si uvedomili, ze tam je chyba, tak by si to osetrili aj tak.
|
|
Re: openssl heartbeat
Od reg.: Trovaricon
|
Pridané:
12.4.2014 18:54
Koli vykonu? Tak moment.
Bavime sa o sifrovanom spojeni, cez ktore sa najcastejsie posielaju informacie v textovej podobe a niekto tu ide riesit "vykonovy dopad" primitivneho volania (ne)virtualnej fukcie v ktorej je podmieneny skok?
Som jediny komu to pripada trochu postavene na hlavu? Je to nemeratelny rozdiel.
"Clovek nie je pocitac a vela chyb prehliadne (naviac je ho mozne peniazmi alebo silou prinutit, aby sa az tak dobre nepozeral)."
A preto tu mame take nepotrebne hluposti, ktore su len pre amaterov - Unit testy & Integracne testy.
Prave ma napadlo, ze (Microsoftacky) C++ AMP, na ktory robi vlastnu implementaciu tolko ludi / skupin, ze ich mozes zratat na jednej ruke ma Conformance test suite.
Ak je to vsak pripad s peniazmi, ktory spominas, tak s tym sa vela robit neda - len "zaliezt na stromy". A vlastne preco tu stracame cas lamentovanim nad profesijnou neschonostou alebo az prilis dobrou schopnostou odrbavat druhych, ked my sme ti poskodeni.
|
|
Re: openssl heartbeat
Od: zase iba ja
|
Pridané:
12.4.2014 19:15
"Som jediny komu to pripada trochu postavene na hlavu? Je to nemeratelny rozdiel."
Deje sa to viackrat, takze je rozdiel sice maly, ale zanedbatelny.
Ked sa ale pozries na zdrojaky OpenSSL, tak uvidis, ze tam lovia aj velmi drobne casy. Pozri sa na ich nahradu malloc a free (tiez za cenu bezpecnosti).
"Unit testy & Integracne testy."
To u najcastejsieho opensource modelu vyvoja velmi nefunguje a asi ani nemoze fungovat. Ked si unittesty robi sam vyvojar, tak je to zle a nebude to dobre fungovat (uz len preto, ze kod pozna). A druhy to asi robit nebude...
Pri TDD je to este horsie - spravia sa testy, podla nich sa to naprogramuje, ale coverage sa uz vacsinou neriesi.
Pre vetu o C++ AMP sa mi v hlave nepodarilo postavit syntakticky strom, takze neviem, ako na nu reagovat.
|
|
Re: openssl heartbeat
Od reg.: Trovaricon
|
Pridané:
12.4.2014 19:45
C++ AMP je rozsirenie jazyka C++ o podporu vykonavania paralelizovatelneho kodu na GPU. Existuje k nemu otvorena specifikacia a Test suite na overenie, ci "dotycny docital specifikaciu do konca a a aj spravne pochopil" - a to sa nejedna o nijak kriticku funkcionality, ktoru rozsirenie poskytuje. Je to tak specificka vec, ze vlastnu implementaciu robi "dva a pol" cloveka. Preco nieco take nemoze existovat aj pre ine specifikacie, ktore su navyse nasadene tak globalne, ze len malokto s nimi neprisiel do kontaktu?
|
|
Re: openssl heartbeat
Od: zase iba ja
|
Pridané:
12.4.2014 20:49
"Ci spravne pochopil" sa principialne neda otestovat. Da sa otestovat, ci tam nie su pouzivane nejake explicitne zakazane postupy - pri Turingovsky uplnych programovacich jazykoch sa dost neda otestovat, ci to bude spravne fungovat.
Nech ideme lubovolne hlboko, mozeme sa dostat k formalnej verifikacii, ale tam je zase ten problem, ze velmi formalny zapis je v podstate uz len ine naprogramovanie programu, kde sa daju rovnako spravit chyby.
|
|
Re: openssl heartbeat
Od reg.: Trovaricon
|
Pridané:
12.4.2014 16:46
AD byt nekompatibilny - ziadna nekompatibilita by sa nekonala, len optimalizacia by koncila pri nizsej hodnote.
Aka ze to technologia bude v domacnostiach dominantna napr. v roku 2020 ze budeme potrebovat "optimalizovat" po 65k framy? Ak ma mat nieco dominanciu v sietovych prvkoch pre koncakov o 6 rokov, musi sa jednat uz o existujucu technologiu. Do toho roku vyjde minimalne jedna revizia TLS - tam nech si to potom pridaju do specky.
|
|
Re: openssl heartbeat
Od: znova som to ja
|
Pridané:
12.4.2014 17:51
"AD byt nekompatibilny - ziadna nekompatibilita by sa nekonala, len optimalizacia by koncila pri nizsej hodnote."
To zase zavadza overhead, ktoremu si sa chcel vyhnut. Takze usetrime 5 bitov v parkrat poslanom pingu (teda uspora v praxi ziadna, lebo 3 bity sa prenasaju dost zle same), ale vdaka tejto "optimalizacii" budeme niekedy pri beznej a ovela castejsej komunikacii posielat o 64 bajtov hlaviciek naviac.
Aby toho nebolo malo, tak to zavedieme s tym, ze v dalsej revizii to bude mozno len s usetrenim 4 bitov a bude pre to treba dalsia implementacia. A potom mozno dalsia spec s usetrenim 3 bitov.
Ako vidim, tak to ma same vyhody ;-).
|
|
Re: openssl heartbeat
Od reg.: Trovaricon
|
Pridané:
12.4.2014 18:35
o akom setreni bitov pises? Normalne by sa pouzivalo napr 12 bitov zo 16 s tym ze zbytok (4) je v tejto verzii protokolu oznaceny ako RESERVED - a uz mas zabezpecenu strukturalnu kompatibilitu s buducou verziou kde mozes expandovat az do hodnoty 65k. Aby bola keepalive paketu umoznena payload velkost 65k je trochu odveci, nemyslis?
Len tak mimochodom, "setrenie" o ktorom sa tu pise na zaklade vyhodnocovania MTU je mozny len ak je vypnuty Nagle algoritmus. Z ktorej strany tecie viac dat? Od klienta alebo ku klientovi? Zrejme ku klientovi, nie? To web servery / web services bezne mavaju Nagle vypnuty?
|
|
Re: openssl heartbeat
Od: stale iba ja
|
Pridané:
12.4.2014 19:01
Ok, mas strukturalnu kompatibilitu, ale prakticky nic neusetris; normalne by sa este hodilo naviac robit nejaky bitand podla verzie protokolu. Naviac si musis vycucat z prstu nejaky pocet bitov, ktory bude stacit.
A potom pridu jumbo packety, kompletna podpora novej verzie TLS nedohladne (kto by kvoli podpore uplne inej vrstvy aktualizoval nieco uplne mimo?) a mame problem. A preco? No lebo sa niekto chcel poistit, aby aplikacia nepodpovedala na paket o velkosti 65k...
Toto mi skor pride ako optimalizacia "v nasej firme mame prvy oktet IP adries vzdy rovnaky, tak si implementujme siet tak, aby to bolo "reserved" (alebo aby sa vobec neposielal)."
Mozno sa tym usetri zanedbatelne mnozstvo dat od utocnikov, ale vyrazne sa znarocni vsetko ostatne.
|
|
Re: openssl heartbeat
Od: asdfsdfasdfff
|
Pridané:
12.4.2014 14:29
> napr. cloveka co prisiel v minulosti s napadom posielat binarne data zakodovane ako base64 string by som dal lyncovat na namesti.
Nesuvisi s temou, ale aj tak: ak protokol podporuje len text, tak je base64 asi najjednoduchsia cesta, ako ho rozsirit na binarky a byt pri tom spatne kompatibilny. Alebo co lepsie by si navrhol ty?
|
|
Re: openssl heartbeat
Od reg.: Trovaricon
|
Pridané:
12.4.2014 15:47
v prvom rade sa nemaju co binarne subory posielat textovym protokolom. Ja mam dost ked vidim boolean posielat ako 4 bajtovy integer a nie to este ako poondiaty text.
|
|
Re: openssl heartbeat
Od: to som zase ja
|
Pridané:
12.4.2014 16:01
Niekto hlada dovody, preco to uzivatelom nedovolit a niekto najde hack, ako to moze fungovat na niecom funkcnom a overenom.
Uzivatelia si vybrali...
|
|
Re: openssl heartbeat
Od reg.: Trovaricon
|
Pridané:
12.4.2014 16:09
ano a potom znacna cast trafficu internetom ma overhead 30 - 40%. Patrim medzi osoby, ktore by sa neuspokojili s takym navrhom - proste "nemohol by som spavat"
|
|
Re: openssl heartbeat
Od: zase ja
|
Pridané:
12.4.2014 16:58
Znacna cast? Toho 0,00nic%?
Unicode ta nestve? Tiez velmi neefektivny, ked mame narodne znakove sady. A aj tie su neefektivne, kedze cast z nich nepouziva vacsina ludi. A co vetna konsteukcia? Keby sme pouzivali slovnik, tak sme schopni zapisat kazde slovo v zakl. tvare na nieco ako 2B. A keby sme zaviedli substituciu pre cele myslienky, tak by asi ziadny text neprekrocil jednotky bajtov.
Mas moznost robit prenosy inak, ako to robi kazdy rozumny clovek. Naviac mas moznost bouncnut maily s prilohami... He to na tebe.
|
|
Re: openssl heartbeat
Od reg.: Trovaricon
|
Pridané:
12.4.2014 18:58
AD slovnik - ale ved to sa prave pouziva hovori sa tomu bezstratova kompresia - v pripade textu referuj priamo na Deflate.
Skusal si vsak uz pakovat base64?
|
|
Re: openssl heartbeat
Od: stale iba ja
|
Pridané:
12.4.2014 19:27
Prakticky vsetka bezstratova kompresia textu dneska si so sebou nesie zbytocny overhead - nejaka tabulka s prefixami / "slovami" / textom. Preco ju nemat vsade spolocnu? (Myslim len pre zrozumitelny text)
Base64 sa da pakovat, aj ked to nie je ako textovy original (co dava zmysel). Skusal som to na jednom paperi (pdf text s par obrazkami), ktory by mal byt aspon nejak komprimovatelny. Original velkost 756458 B, po spakovani (7z) 694911 B.
Base64 velkost 1021884 B, po spakovani 718785 B.
Takze to vyzera tak, ze ovela vacsi problem ako base64 je prenos nepakovanych dat.
|
|
Re: openssl heartbeat
Od reg.: Trovaricon
|
Pridané:
12.4.2014 19:56
Ale to co si popisal nema hlavu a patu. Ako base64 sa prenasaju binarne subory preto lebo su "binarneho" charakteru nie preto, ze niekto si robi srandu a koduje text do base64.
Ako base64 "tecu" zip-y a framy videa.
Skus to takto:
1 MB textu > kompresia
vs.
0.75MB random dat > base64 (1MB) > kompresia
|
|
Re: openssl heartbeat
Od: zase iba ja
|
Pridané:
12.4.2014 21:05
Neviem, co tym chces povedat.
Kedze bolo pisanych 0.75MB a nie MiB, tak pouzivam zaklad jednotiek 1000.
1MB (1000000 B) nahodneho textu > kompresia (763371 B)
vs.
750000 B nahodnych dat > base64 (1013158 B) > kompresia (779014 B)
Kompresia nahodnych dat bez base64 > 760396 B.
Stale to vyzera tak, ze to nezabija base64...
|
|
Re: openssl heartbeat
Od: dasfsadf
|
Pridané:
13.4.2014 0:03
vam tu nejebe ???
|
|
VYSVETLENIE
Od: VYSVETLENIE
|
Pridané:
14.4.2014 22:38
tu
http://dopice.sk/99d
|