Temat: SSL - mity i fakty

Zastanawiamy sie w firmie jakie realne implikacje niesie za soba hostowanie strony bez SSL i z SSL.

Brak SSL:
- strona dziala zauwazalnie szybciej
- mozliwosc wykorzystania szybkich, geo-zlokalizowanych hostow (np. jQuery na google)
- teoretyczna mozliwosc wykradzenia hasel/danych

Jest SSL:
- bezpieczenstwo transmisji danych
- wolne dzialanie strony

Analizujac potencjalny atak na haslo (bez SSL) dochodzimy do wniosku, ze skuteczny sniffing mozesz przeprowadzic wg taktyki man-in-the-middle. Doszlismy do takiego wniosku poniewaz:
- kazde biuro ma teraz switcha a nie huba, a ten kieruje pakiety tylko do adresu MAC docelowego (zapobiega wykryciu pakietu przez promiscuous sniffera)
- pierwszy hop to lokalny router, pozniej routery ISP i na koncu lokalny router serwera, zakladamy, ze ISP nie sniffuje ;)
- z lokalnego routera/firewalla pakiet przechodzi do DMZ, skoro DMZ jest "compromised" to nie ma wlasciwie czego bronic ;)

No tak, ale skoro masz kontrole nad routerem to SSL mozna sobie w d* wsadzic, bo przechwycisz wszystkie DNSy i skierujesz przegladarke na wlasna strone, ktora poprawnie zweryfikuje sie oryginalnym SSLem (potwierdzone w IE7/8 i FF3). Tylko jest to bardzo wyszukany i ciezki do przeprowadzenia atak. Jakie REALNE zagrozenia i potencjalne ataki widzicie przy braku SSL? Czy SSL jest bardziej psychologiczna rzecza (oh ah, szyfrujemy to nic nam nie bedzie i nikt nie zastanawia sie co to szyfrowanie daje) czy realnie wplywa na bezpieczenstwo?

Temat: SSL - mity i fakty

Weź pod uwage jeszcze jeden problem.
Puszczając np. logowanie po SSLu pojawi sie problem certyfikatu. Albo wykupisz certyfikat uznawany przez Microsoft albo userzy otrzymaja komunikat o podejrzanej i niebezpiecznej stronie.
Wiem z doświadczenia że duzo osób rezygnuje wtedy z logowania.

Temat: SSL - mity i fakty

Wiesiek J.:
Albo wykupisz certyfikat uznawany przez Microsoft

Aby uściślić to M$ uznaje (czyli standardowo są one w IE jako rooty) certyfikaty wystawców Entrust, GlobalSigna, VeriSign, AOL, GTE

Natomiast zgadzam się, że userzy widząc informację o nie znanym certyfikacie mogą stronę opuścić. Ale dla mnie osobiście to nie ma znaczenia, gdyż w tym wypadku liczy się samo szyfrowanie i gwarancja, że żaden Cezary-podsłuchiwacz mi nie odczyta hasła z POSTa.

Temat: SSL - mity i fakty

a czy nie wystarczy zamiast hasła przesłać odpowiednią sumę kontrolną wygenerowaną z hasła, a nazwę użytkownika zahaszować przy przesyłaniu ?

Temat: SSL - mity i fakty

Marcin MaW W.:
a czy nie wystarczy zamiast hasła przesłać odpowiednią sumę kontrolną wygenerowaną z hasła, a nazwę użytkownika zahaszować przy przesyłaniu ?

masz na myśli, żeby zahaszować w JS zaraz przed wysłaniem?
bo inaczej chyba nie da się tego zrobić.

Temat: SSL - mity i fakty

maciek kański:
Natomiast zgadzam się, że userzy widząc informację o nie znanym certyfikacie mogą stronę opuścić. Ale dla mnie osobiście to nie ma znaczenia, gdyż w tym wypadku liczy się samo szyfrowanie i gwarancja, że żaden Cezary-podsłuchiwacz mi
nie odczyta hasła z POSTa.

Myslę że tutaj wiele zalezy od rodzaju strony i priorytetów.
Co ważniejsze, liczba userów czy duże bezpieczeństwo.
Przy niektórych grupach userów to dosyć złudny wybór bo co Ci daje SSL i najlepsze zabezpieczenia jak user potrafi zostawić w kafejce stronę na której jest zalogowany, wystarczy kilka razy "wstecz" w przegladarce i już ktoś ma jego konto.

Temat: SSL - mity i fakty

Adam W.:
masz na myśli, żeby zahaszować w JS zaraz przed wysłaniem?
bo inaczej chyba nie da się tego zrobić.

W jednym systemie miałem coś takiego:
1) ze stroną logowania wysyłany był słaby klucz publiczny (jednorazowy)
2) w JS hasło kodowane było tym kluczem (przed postbackiem) i wysyłane w tej postaci
3) serwer odkodował dane kluczem prywatnym po czym unieważniał parę
4) jeżeli user nie wykorzystał klucza to był on unieważniany po 2óch minutach

Do tego SSL nie jest potrzebny...

Temat: SSL - mity i fakty

maciek kański:
Ale dla mnie osobiście to nie ma znaczenia, gdyż w tym wypadku liczy się samo szyfrowanie i gwarancja, że żaden Cezary-podsłuchiwacz mi nie odczyta hasła z POSTa.

No właśnie, a jak szyfrowania SSL nie będzie to jakie realne szanse na sniffing ma Cezary?

Temat: SSL - mity i fakty

Sebastian Pienio:
W jednym systemie miałem coś takiego:
1) ze stroną logowania wysyłany był słaby klucz publiczny (jednorazowy)
2) w JS hasło kodowane było tym kluczem (przed postbackiem) i wysyłane w tej postaci
3) serwer odkodował dane kluczem prywatnym po czym unieważniał parę
4) jeżeli user nie wykorzystał klucza to był on unieważniany po 2óch minutach

Do tego SSL nie jest potrzebny...

jak się sprawdza takie coś? jest to cały czas gdzieś dostępne? chciałbym przetestować:)

Temat: SSL - mity i fakty

Sebastian Pienio:

maciek kański:
Ale dla mnie osobiście to nie ma znaczenia, gdyż w tym wypadku liczy się samo szyfrowanie i gwarancja, że żaden Cezary-podsłuchiwacz mi nie odczyta hasła z POSTa.

No właśnie, a jak szyfrowania SSL nie będzie to jakie realne szanse na sniffing ma Cezary?

Ja sie spotkalem juz z podkradaniem hasel, danych, podsluchiwaniem korespondencji - przez adminow w wiekszych sieciach osiedlowych, firmowych. Podsluchanie przez zwykla osobe jest niemal nierealne.

Temat: SSL - mity i fakty

Adam W.:
jak się sprawdza takie coś? jest to cały czas gdzieś dostępne? chciałbym przetestować:)

Coz, sprawdzalo sie bardzo dobrze przez prawie trzy lata. Przez ten czas przetoczylo sie przez aplikacje ok. 550tys. unikalnych uzytkownikow. Strona (http://seib.co.uk) zostala zdjeta doslownie miesiac temu (byla juz dosyc leciwa technicznie, napisana w ASP). Na nowej (przez SSL) wieszane sa psy, ze "wolno dziala", bo stara dzialala blyskawicznie (ah ten http cache)...

Temat: SSL - mity i fakty

Adam W.:

Sebastian Pienio:
W jednym systemie miałem coś takiego:
1) ze stroną logowania wysyłany był słaby klucz publiczny (jednorazowy)
2) w JS hasło kodowane było tym kluczem (przed postbackiem) i wysyłane w tej postaci
3) serwer odkodował dane kluczem prywatnym po czym unieważniał parę
4) jeżeli user nie wykorzystał klucza to był on unieważniany po 2óch minutach

Do tego SSL nie jest potrzebny...

jak się sprawdza takie coś? jest to cały czas gdzieś dostępne? chciałbym przetestować:)

Lepiej jak "kodowanie kluczem" jest jednokierunkowe (SHA-1, MD5).
Dzięki temu można całkowicie uniemożliwić odkodowanie hasła po drodze.

Zobacz:
http://pajhome.org.uk/crypt/md5/auth.html

Najlepiej smakuje z solą i HMAC-iem.Piotr Likus edytował(a) ten post dnia 10.05.09 o godzinie 12:26

Temat: SSL - mity i fakty

Jeżeli będę chciał wysnifować z sieci interesujące mnie dane - to zwykle przeboleje fakt, że nie uda mi się rozszyfrować hasła - skoro ściągnę na dysk wszystko inne co biegnie po sieci. I to mogą być informacje ciekawsze niż jakieś hasło, które na dobrą sprawę nie jest hackerowi do niczego potrzebne.

Na swoich serwerach nie zauważyłem znaczącego spowolnienia po przejściu na ssl.

Temat: SSL - mity i fakty

Maciej Filipiak:
Jeżeli będę chciał wysnifować z sieci interesujące mnie dane - to zwykle przeboleje fakt, że nie uda mi się rozszyfrować hasła - skoro ściągnę na dysk wszystko inne co biegnie po sieci. I to mogą być informacje ciekawsze niż jakieś hasło, które na dobrą sprawę nie jest hackerowi do niczego potrzebne.

Na swoich serwerach nie zauważyłem znaczącego spowolnienia po przejściu na ssl.

SSL jest wolne nie przy transferze ruchu, ale w strefie "user responsiveness" czyli subiektywne odczucie uzytkownika jest duzo gorsze niz przy cache z HTTP. Jest to zauwazalne przez praktycznie wszystkich, niezalezenie od wielkosci HTMLa wygenerowanego jak i serwera (sprawdzalem na Apache, Tomcat, IIS).

Ponowie pytanie - jak przeprowadzic skuteczny REALNY atak na strone bez SSL?

Poczytalem tez troche o tym i latwiej jest napisac key-loggera i sprzedac mu jako "fajna gierke" na pendrivie niz bawic sie w podsluchiwanie i sniffowanie.

Skoro nikt nie ma innych pomyslow niz przejecie routera/serwera to mozna powiedziec, ze bezpieczenstwo SSL to "zabezpieczenie przed adminem"?

Temat: SSL - mity i fakty

http://pl.wikipedia.org/wiki/Transport_Layer_Security#...
Zasadniczo SSL nie jest bezpieczne w 100%. Każdy algorytm można złamać, a jak wiadomo są ludzie, dla których to sprawa honoru.

"Lepiej jak "kodowanie kluczem" jest jednokierunkowe (SHA-1, MD5)."

Jak widzę MD5 to mi się śmiać chce. Obecnie Tęczowe Tablice zawierają praktycznie wszystkie możliwe kombinacje skrótów niezależnie od ilości przesyłanych bitów. Samo SSL korzysta z szyfrowania algorytmami, które są dostępne publicznie, stąd też można postawić tezę, że znając algorytm, jego słaby punkt (kolizja), można wykorzystać zupełnie inny ciąg znaków, aby podszyć się pod hasło. Jeżeli chodzi o szyfrowanie asymetryczne, to też nie jest z tym zbyt trudno. Wystarczy, ze posiadamy klucz publiczny (podobno nie da się tego tak zrobić), znamy zaszyfrowany ciąg i powiedzmy jego postać jawną. Zabieramy ze sobą cierpliwość, dobrą maszynę, może jakieś przetwarzanie równoległe i bez problemu znajdziemy klucz prywatny. Problem w tym, że to zabierze bardzo dużo czasu, ale jak ktoś będzie zmuszony, aby coś takiego zrobić to na pewno to zrobi.

Ponadto, nie wiem jak obecnie, ale dawniej pojawiało się wiele błędów w implementacjach SSL, które umożliwiały bez znajomości klucza prywatnego odszyfrowanie informacji. Wiadomo, że na jednego specjalistę od bezpieczeństwa IT znajdzie się 100, który będą potrafić złamać owe zabezpieczenia.

"Ponowie pytanie - jak przeprowadzic skuteczny REALNY atak na strone bez SSL?"
Zarówno bez jak i z SSL można użyć DNS spoofing (zwłaszcza przy wykradaniu haseł do banków), ewentualnie czegoś bliskiego. Chciałbym tez zauważyć, że sam atak na stronę może nie być wykonany, jeżeli uda się przeprowadzić atak na serwer, wykorzystując jakieś błędy.

"Poczytalem tez troche o tym i latwiej jest napisac key-loggera i sprzedac mu jako "fajna gierke" na pendrivie niz bawic sie w podsluchiwanie i sniffowanie."

Prawdę mówiąc łatwiej nie znaczy lepiej. Sam podsłuch pakietów mówi bardzo dużo i niektórym daje kopa adrenaliny. Gdyby ludzie z poza IT wiedzieli jakie dany wysyłają bez szyfrowania to przestali by korzystać z sieci.Dominik Ł. edytował(a) ten post dnia 11.05.09 o godzinie 17:24

Temat: SSL - mity i fakty

Dominik Ł.:
"Lepiej jak "kodowanie kluczem" jest jednokierunkowe (SHA-1, MD5)."

Jak widzę MD5 to mi się śmiać chce. Obecnie Tęczowe Tablice zawierają praktycznie wszystkie możliwe kombinacje skrótów niezależnie od ilości przesyłanych bitów.

Miło, że ktoś wie co to jest Tęczowa Tablica. Szkoda tylko że nie przeczytałeś do końca:

Defense against rainbow tables

Temat: SSL - mity i fakty

Piotr Likus:

Dominik Ł.:
"Lepiej jak "kodowanie kluczem" jest jednokierunkowe (SHA-1, MD5)."

Jak widzę MD5 to mi się śmiać chce. Obecnie Tęczowe Tablice zawierają praktycznie wszystkie możliwe kombinacje skrótów niezależnie od ilości przesyłanych bitów.

Miło, że ktoś wie co to jest Tęczowa Tablica. Szkoda tylko że nie przeczytałeś do końca:

Defense against rainbow tables

Ech, szkoda, że nie czytasz tego co podsyłasz. Tęczowe tablice to nic innego jak baza kolizji. Obecnie Tęczówki mają po kilka, kilkanaście TB i wydaje mi się, że znalezienie kolizji nie jest zbyt trudne. A co do soli i reszty... weź pod uwagę, że kolizja nie widzi żadnych soli. Wystarczy, że wygenerujesz taki ciąg,. który da ten sam hash.

Jak nie rozumiesz o czym mówię to proszę..

Defense against rainbow tables:
hash = MD5 (password . salt)
Or
hash = MD5 (MD5 (password) . salt)

skrót jest ten sam, znalezienie kolizji jest zbyt łatwe. Pamiętaj, że md5 to tylko 128 bitów. Polecam lekturę http://www.mscs.dal.ca/~selinger/md5collision/

Temat: SSL - mity i fakty

Dominik Ł.:

Piotr Likus:

Dominik Ł.:
"Lepiej jak "kodowanie kluczem" jest jednokierunkowe (SHA-1, MD5)."

Jak widzę MD5 to mi się śmiać chce. Obecnie Tęczowe Tablice zawierają praktycznie wszystkie możliwe kombinacje skrótów niezależnie od ilości przesyłanych bitów.

Miło, że ktoś wie co to jest Tęczowa Tablica. Szkoda tylko że nie przeczytałeś do końca:

Defense against rainbow tables

Ech, szkoda, że nie czytasz tego co podsyłasz. Tęczowe tablice to nic innego jak baza kolizji. Obecnie Tęczówki mają po kilka, kilkanaście TB i wydaje mi się, że znalezienie kolizji nie jest zbyt trudne. A co do soli i reszty... weź pod uwagę, że kolizja nie widzi żadnych soli. Wystarczy, że wygenerujesz taki ciąg,. który da ten sam hash.

Jak nie rozumiesz o czym mówię to proszę..

Defense against rainbow tables:
hash = MD5 (password . salt)
Or
hash = MD5 (MD5 (password) . salt)

skrót jest ten sam, znalezienie kolizji jest zbyt łatwe. Pamiętaj, że md5 to tylko 128 bitów. Polecam lekturę http://www.mscs.dal.ca/~selinger/md5collision/

We wstępie do wskazanego przeze mnie artykułu można to przeczytać:
Wikipedia: A rainbow table is a lookup table offering a time-memory tradeoff used in recovering the plaintext password from a password hash generated by a hash function, often a cryptographic hash function. A common application is to make attacks against hashed passwords feasible. A salt is often employed with hashed passwords to make this attack more difficult, often infeasible..

Znasz jakąś metodę na odszukanie hasła zahashowanego z sesyjną solą? Chętnie poczytam o tym. Oczywiście metody która umożliwia odszukanie tego hasła w ciągu jednego dnia na dzisiejszym komputerze przy założeniu że sól jest dłuższa niż 16 bitów.Piotr Likus edytował(a) ten post dnia 12.05.09 o godzinie 09:13

Temat: SSL - mity i fakty

Dominik Ł.:
http://pl.wikipedia.org/wiki/Transport_Layer_Security#...
Zasadniczo SSL nie jest bezpieczne w 100%. Każdy algorytm można złamać, a jak wiadomo są ludzie, dla których to sprawa honoru. Samo SSL korzysta z szyfrowania algorytmami, które są dostępne publicznie, stąd też można postawić tezę, że znając algorytm, jego słaby punkt (kolizja), można wykorzystać zupełnie inny ciąg znaków, aby podszyć się pod hasło.

Moja watpliwosc dotyczy nie bezpieczenstwa SSL tylko roznicy w bezpieczenstwie strony htpps a http.

Zarówno bez jak i z SSL można użyć DNS spoofing (zwłaszcza przy wykradaniu haseł do banków), ewentualnie czegoś bliskiego.

Czyli rowniez w tym przypadku SSL nie podnosi bezpieczenstwa.

Prawdę mówiąc łatwiej nie znaczy lepiej. Sam podsłuch pakietów mówi bardzo dużo i niektórym daje kopa adrenaliny. Gdyby ludzie z poza IT wiedzieli jakie dany wysyłają bez szyfrowania to przestali by korzystać z sieci.

No swietnie, tylko w czasach switchy i routerow z tablicami MAC podsluchanie pakietu to nie taka prosta sprawa. Nie wystarczy nawet byc w tej samej sieci, trzeba miec albo kontrole nad maszyna albo ktoryms routerem. A skoro masz router to dns-spoof'em go i po zabawie - niewazne czy masz ssl czy nie.

To gdzie to nasze "zwiekszone bezpieczenstwo" przez zastosowanie SSL? Chwyt marketingowy czy co?

Temat: SSL - mity i fakty

Sebastian Pienio:
To gdzie to nasze "zwiekszone bezpieczenstwo" przez zastosowanie SSL? Chwyt marketingowy czy co?

A SSL nie zabezpiecza przed phishingiem? Mówię tu o poważnych instytucjach, które mają wykupione certyfikaty SSL wydane przez np. VeriSignWojciech Sznapka edytował(a) ten post dnia 12.05.09 o godzinie 14:24