http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf

"Our main conclusion is that SSL certificate validation is completely broken in many
critical software applications and libraries."

Wniosek: dywagacje n/t wyzszosci jednej metodologii produkcji oprogramowania nad

druga nie maja sensu w kontekscie bezpieczenstwa, bo tak czy inaczej
oprogramowanie pisza ludzie, a ludzie nie potrafia pisac bezpiecznego
oprogramowania.

RW

do góry

Ponurą porą Thu, 25 Oct 2012 14:00:17 -0700, Roman W wyszeptał:

> http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf
>
> "Our main conclusion is that SSL certificate validation is completely
> broken in many critical software applications and libraries."
>
> Wniosek: dywagacje n/t wyzszosci jednej metodologii produkcji
> oprogramowania nad
>
> druga nie maja sensu w kontekscie bezpieczenstwa, bo tak czy inaczej
> oprogramowanie pisza ludzie, a ludzie nie potrafia pisac bezpiecznego
> oprogramowania.

Niezła kolekcja, ale na tym poziomie to jednak niektórzy potrafią.

--
Edek

do góry

W dniu czwartek, 25 października 2012 22:41:05 UTC+1 użytkownik Edek Pienkowski
napisał:
> Ponurą porą Thu, 25 Oct 2012 14:00:17 -0700, Roman W wyszeptał:
>
>
>
> > http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf
>
> >
>
> > "Our main conclusion is that SSL certificate validation is completely
>
> > broken in many critical software applications and libraries."
>
> >
>
> > Wniosek: dywagacje n/t wyzszosci jednej metodologii produkcji
>
> > oprogramowania nad
>
> >
>
> > druga nie maja sensu w kontekscie bezpieczenstwa, bo tak czy inaczej
>
> > oprogramowanie pisza ludzie, a ludzie nie potrafia pisac bezpiecznego
>
> > oprogramowania.
>
>
>
> Niezła kolekcja, ale na tym poziomie to jednak niektórzy potrafią.

Cynik by powiedzial, ze "niektorzy nie zostali jeszcze sprawdzeni".

RW

do góry

Ponurą porą Thu, 25 Oct 2012 14:00:17 -0700, Roman W wyszeptał:

> http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf
>
> "Our main conclusion is that SSL certificate validation is completely
> broken in many critical software applications and libraries."
>
> Wniosek: dywagacje n/t wyzszosci jednej metodologii produkcji
> oprogramowania nad
>
> druga nie maja sensu w kontekscie bezpieczenstwa, bo tak czy inaczej
> oprogramowanie pisza ludzie, a ludzie nie potrafia pisac bezpiecznego
> oprogramowania.

Stwierdziłem jednak, że to jest dość ciekawa sprawa, chyba organizacyjna.

Zacząć trzeba od tego, że ktoś do kryptografii musi mieć i wiedzę i
umiejętności. Zwłaszcza to drugie: w kryptografii (_użyciu_, nie
wymyślaniu) trzeba w 100% myśleć logicznie, z czym zastanawiająco wielu
programistów ma tak naprawdę spory problem. Potem, trzeba wybrać kogoś,
kto jednak ma wiedzę, ale to jest proste, wystarczy kazać skonstruować
odpowiedni chain-of-trust i zadać parę pytań typu "co to jest perfect
forward secrecy" albo "jak wymienić symetryczny klucz".

Tyle, że powyższe zazwyczaj nie ma żadnego znaczenia, bo tego nie wie
zarządzający projektem. Nawet jak ktoś będzie chciał i będzie miał okazję
wytłumaczyć, że to specjalna rola, większość nie zrozumie i oleje, a jak
się jeszcze powie, że "ta biblioteka zajmie 2-3 razy tyle czasu co
normalnie, a w zasadzie będzie kiedy robiący stwierdzi, że jest ok" to w
większości przypadków ktoś taki zostanie uznany za lekko niegroźnego
fanatyka i nic innego z tego nie wyniknie.

A potem jakiś truteń napisze sprawdzanie hmac(userStr+emailStr) czy
coś podobnie durnego.

--
Edek

do góry

W dniu czwartek, 25 października 2012 23:12:56 UTC+1 użytkownik Edek Pienkowski
napisał:
> Ponurą porą Thu, 25 Oct 2012 14:59:51 -0700, Roman W wyszeptał:
>
>
>
> >> Niezła kolekcja, ale na tym poziomie to jednak niektórzy potrafią.
>
> >
>
> > Cynik by powiedzial, ze "niektorzy nie zostali jeszcze sprawdzeni".
>
>
>
> A ja bym powiedział, że nawet jak sprawdzeni, to co z tego: wystarczy
> jeden łepek dotykający się takiego kodu.

Ci hakerzy z MIT czasow Stallmana mieli racje: po co to wszystko. Skasujmy
hasla i otworzmy szeroko drzwi naszych serwerow ;-)

Ludzie sa lepsi w lamaniu zabezpieczen niz w projektowaniu zabezpieczen. W
pewnym sensie to dobrze o nas swiadczy jako gatunku, ale sprawia ze cala ta
zabawa nie ma sensu.

RW

do góry

Ponurą porą Thu, 25 Oct 2012 14:59:51 -0700, Roman W wyszeptał:

>> Niezła kolekcja, ale na tym poziomie to jednak niektórzy potrafią.
>
> Cynik by powiedzial, ze "niektorzy nie zostali jeszcze sprawdzeni".

A ja bym powiedział, że nawet jak sprawdzeni, to co z tego: wystarczy
jeden łepek dotykający się takiego kodu.

--
Edek

do góry

On 2012-10-26 00:16, Roman W wrote:
> W dniu czwartek, 25 października 2012 23:12:56 UTC+1 użytkownik Edek Pienkowski
napisał:
>> Ponurą porą Thu, 25 Oct 2012 14:59:51 -0700, Roman W wyszeptał:
>>
>>
>>
>>>> Niezła kolekcja, ale na tym poziomie to jednak niektórzy potrafią.
>>
>>>
>>
>>> Cynik by powiedzial, ze "niektorzy nie zostali jeszcze sprawdzeni".
>>
>>
>>
>> A ja bym powiedział, że nawet jak sprawdzeni, to co z tego: wystarczy
>> jeden łepek dotykający się takiego kodu.
>
> Ci hakerzy z MIT czasow Stallmana mieli racje: po co to wszystko. Skasujmy
> hasla i otworzmy szeroko drzwi naszych serwerow ;-)
>
> Ludzie sa lepsi w lamaniu zabezpieczen niz w projektowaniu zabezpieczen. W
> pewnym sensie to dobrze o nas swiadczy jako gatunku, ale sprawia ze cala ta
> zabawa nie ma sensu.
>
Doprawdy ? Transmisja szyformwana podatna na atak man in the middle jest
mimo wszystko lepsza o transmisji otwartym tekstem.

Pozdrawiam

Marek

do góry

Dnia 25.10.2012 Roman W <r...@g...com> napisał/a:
[...]
> Ludzie sa lepsi w lamaniu zabezpieczen niz w projektowaniu zabezpieczen. W
> pewnym sensie to dobrze o nas swiadczy jako gatunku, ale sprawia ze cala ta
> zabawa nie ma sensu.

To jest kwestia niewiedzy (lub braku staranności) w korzystaniu z
bibliotek a nie sama dziura jako taka w technologii :D Można też się
czepić, że twórcy OpenSSL nie zapewnili "idiotoodpornego" API przez co
zbyt łatwo popełnić jest błąd, niemniej jednak samo SSL jako takie (na
poziomie protokołu) jest bezpieczne :D

do góry

Dnia 25.10.2012 Roman W <r...@g...com> napisał/a:
[...]
> Ludzie sa lepsi w lamaniu zabezpieczen niz w projektowaniu zabezpieczen. W
> pewnym sensie to dobrze o nas swiadczy jako gatunku, ale sprawia ze cala ta
> zabawa nie ma sensu.

To jest kwestia niewiedzy (lub braku staranności) w korzystaniu z
bibliotek a nie sama dziura jako taka w technologii :D Można też się
czepić, że twórcy OpenSSL nie zapewnili "idiotoodpornego" API przez co
zbyt łatwo jest popełnić błąd, niemniej jednak samo SSL jako takie (na
poziomie protokołu) jest bezpieczne :D

do góry