Witam!

Czy korzystanie z w3cache wplywa w jakikolwiek sposob na bezpieczenstwo
podczas kozystania z uslug e-bankow (SSL 128 bitow)

Pozdrawiam,
Piotr

=======================
wyprawy, trekkingi, wspinaczka
www.pamir.biz
7000 m za 498$! Elbrus za 347$!
=======================

do góry

"Pamir" <i...@p...biz> napisal w <3c6c9747$1@news.vogel.pl>:

>Czy korzystanie z w3cache wplywa w jakikolwiek sposob na bezpieczenstwo
>podczas kozystania z uslug e-bankow (SSL 128 bitow)

wydaje mi sie, ze typowy w3cache nie proxuje polaczen https, a tylko http.
Http i https to 2 oddzielne protokoły, w sensie, że używaja różnych portów
(80 i 443 na docelowym serwerze, defaultowo).

Jesli nawet by jednak w3cache posredniczyl w takim polaczeniu, to po to masz
szyfrowanie, zeby informacja ew. dostepna dla hackerow (po wlamaniu na serwer
w3cache, zakladajac, ze w3cache zapisuje takie informacje u siebie) wymagala
jednak pewnego czasu na rozkodowanie /niestety nie jest to wcale szybkie :-)

--
<xml-sig>
<header> Adam
</xml-sig>

do góry

Adam_mb <m...@i...pl> napisał(a):
> "Pamir" <i...@p...biz> napisal w <3c6c9747$1@news.vogel.pl>:

>>Czy korzystanie z w3cache wplywa w jakikolwiek sposob na bezpieczenstwo
>>podczas kozystania z uslug e-bankow (SSL 128 bitow)

Korzystanie z w3cache _może_ mieć wpływ na jeden z aspektów bezpieczeństwa,
a konkretnie na DOSTĘPNOŚĆ. Administrator w3cache'a może zablokować konkretne
URL'e, choćby właśnie URL do serwisu transakcyjnego Twojego banku.
Jeśli dodatkowo w3cache jest jedyną metodą uzyskania dostępu do WWW (typowym
przykładem mogą tu być sieci korporacyjne) to taka blokada może być dotkliwa.

> wydaje mi sie, ze typowy w3cache nie proxuje polaczen https, a tylko http.
> Http i https to 2 oddzielne protokoły, w sensie, że używaja różnych portów
> (80 i 443 na docelowym serwerze, defaultowo).

Większość znanych mi http proxies obsłguje HTTPS, rzecz jasna bez cache'owania.
To po prostu zwykły connect - czyste pośrednictwo bez zachowywania kopii ruchu.

Wojtek
--
|___ Wojciech "Gooch" Kus ______ email: w...@c...waw.pl ___|
|__ Nieustraszony Lowca Dzwiekow (w stanie chwilowego spoczynku ;-> ) __|
|_____________ Odpowadajac, usun -SPAMAWAY z mojego adresu! _____________|

do góry

>> wydaje mi sie, ze typowy w3cache nie proxuje polaczen https, a tylko
>> http. Http i https to 2 oddzielne protokoły, w sensie, że używaja
>> różnych portów (80 i 443 na docelowym serwerze, defaultowo).
>
>Większość znanych mi http proxies obsłguje HTTPS, rzecz jasna bez
>cache'owania. To po prostu zwykły connect - czyste pośrednictwo bez
>zachowywania kopii ruchu.

Typowy w3cache raczej nie powinien, a gdy działa bez zapisu i pozostawiania
kopii, to nie jest w3cachem i nie można używać wtedy słowa "cache" ;-)

Oczywiscie zawsze pozostaje jeszcze snifery w sieci lokalnej, wychwytujace
nasze pakiety kierujace sie po https do banku.

--
<xml-sig>
<header> Adam
</xml-sig>

do góry

Adam_mb <m...@i...pl> napisał(a):
>>> wydaje mi sie, ze typowy w3cache nie proxuje polaczen https, a tylko
>>> http. Http i https to 2 oddzielne protokoły, w sensie, że używaja
>>> różnych portów (80 i 443 na docelowym serwerze, defaultowo).
>>
>>Większość znanych mi http proxies obsłguje HTTPS, rzecz jasna bez
>>cache'owania. To po prostu zwykły connect - czyste pośrednictwo bez
>>zachowywania kopii ruchu.

> Typowy w3cache raczej nie powinien, a gdy działa bez zapisu i pozostawiania
> kopii, to nie jest w3cachem i nie można używać wtedy słowa "cache" ;-)

OK, może wyraziłem się nieprecyzyjnie. "Typowy" (o ile można mówić o typowości)
w3cache pośredniczy w ruchu HTTP _i_ HTTPS, ale cache'uje tylko HTTP.
Alles klar ?

> Oczywiscie zawsze pozostaje jeszcze snifery w sieci lokalnej, wychwytujace
> nasze pakiety kierujace sie po https do banku.

Proszę ???? Obawiam się, że nie dostrzegam sensownego wykorzystania danych
zesniffowanych z sesji HTTPS... no chyba, że jako zamiennik /dev/random ;)

Wojtek
--
|___ Wojciech "Gooch" Kus ______ email: w...@c...waw.pl ___|
|__ Nieustraszony Lowca Dzwiekow (w stanie chwilowego spoczynku ;-> ) __|
|_____________ Odpowadajac, usun -SPAMAWAY z mojego adresu! _____________|

do góry

>> Oczywiscie zawsze pozostaje jeszcze snifery w sieci lokalnej,
>> wychwytujace nasze pakiety kierujace sie po https do banku.
>
>Proszę ???? Obawiam się, że nie dostrzegam sensownego wykorzystania danych
>zesniffowanych z sesji HTTPS... no chyba, że jako zamiennik /dev/random ;)

a jak wykorzystasz zapisane dane https z proxy/w3cache, gdyby zapisywał?
Szyfrowanie odbywa sie w przegladarce i każdy kolejny etap idzie już
zakodowany. I tu i tam potrzeba ok. 80 lat na dostepnym ogólnie sprzecie ;-)
Czyli /dev/random ;)

Zagrożeniem natomiast sa różnego rodzaju ztrojanowane czesci systemu
(wprowadzone przez różne wirusy i inna faune), które np. przechwytuja
wklepywane przez użytkownika dane.

To duuużo skuteczniejsze niż rozkodowywac 128-bit ssl, a takie programy,
ogólnodostepne w sieci, zainstalować może nawet złosliwy kolega z pracy... no
i użytkownicy *najpopularniejszego systemu dla stacji roboczych* niestety
niewiele sa w stanie temu zaradzić.

--
<xml-sig>
<header> Adam
</xml-sig>

do góry