🚀 go-pugleaf

epsilon$ while read LINE; do echo \>"$LINE"; done < "Artur Frydel"
>Witam.
>
>Czy wysłanie tak skonstruowanego linka;
>https://username:password@jakis.serwer.com jest bezpieczne?
>Chodzi mi o to czy ustawienie szyfrowania transmisji odbywa sie jeszcze
>przed wysłaniem tego zapytania, czy tez link wyjdzie "czystym" tekstem?

Wysyłanie takiego linka otwartym tekstem jest durne samo w sobie ;-)
Natomiast jeśli chodzi o HTTPS, to działa to z grubsza tak, że najpierw
następuje połączenie z serwerem, negocjacja SSL, a dopiero potem, po
szyfrowanym połączeniu, działa HTTPS.

-- 
d'`'`'`'`'`'`'`'`'`'`'`'`'Yb 
`b  Kruk@epsilon.eu.org   d' 
d' http://epsilon.eu.org/ Yb 
`b,-,.,-,.,-,.,-,.,-,.,-,.d' 

On 25.11.2009, Artur Frydel wrote:
> Witam.
>
> Czy wysłanie tak skonstruowanego linka;
> https://username:password@jakis.serwer.com jest bezpieczne?
> Chodzi mi o to czy ustawienie szyfrowania transmisji odbywa sie jeszcze
> przed wysłaniem tego zapytania, czy tez link wyjdzie "czystym" tekstem?

HTTPs, zgodnie z nazwą, to HTTP over SSL. Znaczy najpierw jest
ustanawiany SSL/TLS, a dopiero potem zaczyna się normalny HTTP.

-- 
Stanislaw Klekot

Day Wed, 25 Nov 2009 11:40:10 +0100, Mariusz Kruk wrote:

> epsilon$ while read LINE; do echo \>"$LINE"; done < "Artur Frydel"
>>Witam.
>>
>>Czy wysłanie tak skonstruowanego linka;
>>https://username:password@jakis.serwer.com jest bezpieczne?
>>Chodzi mi o to czy ustawienie szyfrowania transmisji odbywa sie jeszcze
>>przed wysłaniem tego zapytania, czy tez link wyjdzie "czystym" tekstem?
> 
> Wysyłanie takiego linka otwartym tekstem jest durne samo w sobie ;-)

Dlaczego? A ftps://user:pass@ftp.com tez jest evil?

-- 
Artur 'bzyk' Frydel 
Kto rano wstaje ten leje jak z cebra

Day Wed, 25 Nov 2009 10:47:49 +0000 (UTC), Stachu 'Dozzie' K. wrote:

> On 25.11.2009, Artur Frydel wrote:
>> Witam.
>>
>> Czy wysłanie tak skonstruowanego linka;
>> https://username:password@jakis.serwer.com jest bezpieczne?
>> Chodzi mi o to czy ustawienie szyfrowania transmisji odbywa sie jeszcze
>> przed wysłaniem tego zapytania, czy tez link wyjdzie "czystym" tekstem?
> 
> HTTPs, zgodnie z nazwą, to HTTP over SSL. Znaczy najpierw jest
> ustanawiany SSL/TLS, a dopiero potem zaczyna się normalny HTTP.


Tak mi sie tez wydawalo, i na "zdrowy rozum" tak ma byc. Tyle ze nie mialem
pod reka narzedzi i nie bylo jak sprawdzic, a sprawa dla mnie istotna wiec
wolalem sie upewnic.
Dzieki za wyjasnienie sprawy.

-- 
Artur 'bzyk' Frydel 
If you're too open minded, your brains will fall out.

epsilon$ while read LINE; do echo \>"$LINE"; done < "Artur Frydel"
>>>Czy wysłanie tak skonstruowanego linka;
>>>https://username:password@jakis.serwer.com jest bezpieczne?
>>>Chodzi mi o to czy ustawienie szyfrowania transmisji odbywa sie jeszcze
>>>przed wysłaniem tego zapytania, czy tez link wyjdzie "czystym" tekstem?
>> Wysyłanie takiego linka otwartym tekstem jest durne samo w sobie ;-)
>Dlaczego? A ftps://user:pass@ftp.com tez jest evil?

Skoro używasz transmisji szyfrowanej, zakładasz, że ktoś mógłby ją
podsłuchiwać. Dlaczego zatem przesyłasz otwartym tekstem dane konieczne
do zalogowania się do zasobu? Je też można podsłuchać.

-- 
[------------------------] 
[  Kruk@epsilon.eu.org   ] 
[ http://epsilon.eu.org/ ] 
[------------------------] 

Mariusz Kruk wrote:

> Skoro używasz transmisji szyfrowanej, zakładasz, że ktoś mógłby ją
> podsłuchiwać. Dlaczego zatem przesyłasz otwartym tekstem dane konieczne
> do zalogowania się do zasobu? Je też można podsłuchać.

co masz na mysli ? sugerujesz ze te dane sa przesylane bez szyfrowania ?

On Fri, 27 Nov 2009 19:14:01 +0100, MarcinF <marfi@interia.pl> wrote:

> > Skoro używasz transmisji szyfrowanej, zakładasz, że ktoś mógłby ją
> > podsłuchiwać. Dlaczego zatem przesyłasz otwartym tekstem dane konieczne
> > do zalogowania się do zasobu? Je też można podsłuchać.
> 
> co masz na mysli ? sugerujesz ze te dane sa przesylane bez szyfrowania ?

Kolega sugeruje, że jeśli preparujesz linka w sposób:
https://user:pass@domena
to robisz to po to, żeby komuś go dać do kliknięcia.
A jeśli wysyłasz go mailem albo innym GG, to ta transmisja może zostać
podsłuchana (zakładając, że nie będzie szyfrowana), co spowoduje
przechwycenie loginu i hasła.

-- 
Pozdrawiam
  Bartek

Moje poglądy prezentowane w Usenecie są całkowicie prywatne.

Bartosz Kiziukiewicz wrote:

> Kolega sugeruje, że jeśli preparujesz linka w sposób:
> https://user:pass@domena
> to robisz to po to, żeby komuś go dać do kliknięcia.

no to wydaje mi sie ze nastapilo male nieporozumienie jesli chodzi
o to wysylane...

slowo "wysylanie" jakie padlo w pytaniu dotyczylo raczej polaczenia
klienta z serwerem po szyfrowanym protokole, interpretowanie go jako
przesylanie tego linka innym kanalem pozbawialoby przeciez sensu to pytanie

>> HTTPs, zgodnie z nazwą, to HTTP over SSL. Znaczy najpierw jest
>> ustanawiany SSL/TLS, a dopiero potem zaczyna się normalny HTTP.
> 
> 
> Tak mi sie tez wydawalo, i na "zdrowy rozum" tak ma byc. Tyle ze nie
> mialem pod reka narzedzi i nie bylo jak sprawdzic, a sprawa dla mnie
> istotna wiec wolalem sie upewnic.
> Dzieki za wyjasnienie sprawy.

Ale sama nazwa jest przesylana na tyle prosto, ze da sie ja przeczytac 
chyba. Wyobrażmy sobie taka informacje
Przesylam komus link w formie zaszyfrowanej albo daje na kartce 
https://wklej.to/PLLr/text on go otwiera. Po za logami na serwerze moim 
zdaniem da sie odczytac tez to, jaki zasob ktos odczytal. Jesli dane nie sa 
kasowane da sie odczytac tez tresc.

Jesli jest inaczej prosze o odpowiedź. Oczywiscie bardziej zaawansowane 
rzeczy jak chinski mur NA PEWNO moga odczytac pelen adres. Ale najlatwiej 
zrobic to na routerze.

-- 
^^

"Piotr J. Kolanok" <kolano0123@m0.mx.poczta.tlen.pl> writes:

> Ale sama nazwa jest przesylana na tyle prosto, ze da sie ja przeczytac 
> chyba. Wyobrażmy sobie taka informacje
> Przesylam komus link w formie zaszyfrowanej albo daje na kartce 
> https://wklej.to/PLLr/text on go otwiera. Po za logami na serwerze moim 
> zdaniem da sie odczytac tez to, jaki zasob ktos odczytal. Jesli dane nie sa 
> kasowane da sie odczytac tez tresc.

Tzn. kto moze to zrobic, np. admin tamtego serwera? No jasne, SSL nie
chroni przeciez przed druga strona, a tylko przed posluchem itp.
w srodku.


> Jesli jest inaczej prosze o odpowiedź. Oczywiscie bardziej zaawansowane 
> rzeczy jak chinski mur NA PEWNO moga odczytac pelen adres.

???

> Ale najlatwiej zrobic to na routerze.

Nie wiem co. Odczytac adres IP i byc moze nazwe domeny? Jasne, SSL przed
tym nie chroni. Odczytac "PLLr/text"? Nie, o ile nie uda sie nam atak
np. MITM.
-- 
Krzysztof Halasa

Dnia 28-11-2009 o 13:01:59 Piotr J. Kolanok  
<kolano0123@m0.mx.poczta.tlen.pl> napisał(a):

>>> HTTPs, zgodnie z nazwą, to HTTP over SSL. Znaczy najpierw jest
>>> ustanawiany SSL/TLS, a dopiero potem zaczyna się normalny HTTP.
>>
>>
>> Tak mi sie tez wydawalo, i na "zdrowy rozum" tak ma byc. Tyle ze nie
>> mialem pod reka narzedzi i nie bylo jak sprawdzic, a sprawa dla mnie
>> istotna wiec wolalem sie upewnic.
>> Dzieki za wyjasnienie sprawy.
>
> Ale sama nazwa jest przesylana na tyle prosto, ze da sie ja przeczytac
> chyba. Wyobrażmy sobie taka informacje
> Przesylam komus link w formie zaszyfrowanej albo daje na kartce
> https://wklej.to/PLLr/text on go otwiera. Po za logami na serwerze moim
> zdaniem da sie odczytac tez to, jaki zasob ktos odczytal. Jesli dane nie  
> sa
> kasowane da sie odczytac tez tresc.
>
> Jesli jest inaczej prosze o odpowiedź. Oczywiscie bardziej zaawansowane
> rzeczy jak chinski mur NA PEWNO moga odczytac pelen adres. Ale najlatwiej
> zrobic to na routerze.

pobieranie https://wklej.to/PLLr/text wygląda AFAIK tak:
1) klient odpytuje DNS o wklej.to bez szyfrowania (chyba ze ma IP w  
cache'u)
2) klient łączy się z tym IP:443
3) zestawia się kanał szyfrowany
4) zaszyfrowanym kanałem podaje jaki adres chce
5) odpowiedz leci zaszyfrowanym kanałem

-- 
http://joru.olewales.ath.cx/

Krzysztof Halasa wrote:

> "Piotr J. Kolanok" <kolano0123@m0.mx.poczta.tlen.pl> writes:
> 
>> Ale sama nazwa jest przesylana na tyle prosto, ze da sie ja przeczytac
>> chyba. Wyobrażmy sobie taka informacje
>> Przesylam komus link w formie zaszyfrowanej albo daje na kartce
>> https://wklej.to/PLLr/text on go otwiera. Po za logami na serwerze moim
>> zdaniem da sie odczytac tez to, jaki zasob ktos odczytal. Jesli dane nie
>> sa kasowane da sie odczytac tez tresc.
> 
> Tzn. kto moze to zrobic, np. admin tamtego serwera? No jasne, SSL nie
> chroni przeciez przed druga strona, a tylko przed posluchem itp.
> w srodku.

Jeszcze raz. Czy ktoś POMIEDZY. Router, MiM etc. jest w stanie to odczytać.

>> Ale najlatwiej zrobic to na routerze.
> 
> Nie wiem co. Odczytac adres IP i byc moze nazwe domeny? Jasne, SSL przed
> tym nie chroni. Odczytac "PLLr/text"? Nie, o ile nie uda sie nam atak
> np. MITM.

Nie tekst ale ADRES PLLr/...

-- 
^^

>> Jesli jest inaczej prosze o odpowiedź. Oczywiscie bardziej zaawansowane
>> rzeczy jak chinski mur NA PEWNO moga odczytac pelen adres. Ale najlatwiej
>> zrobic to na routerze.
> 
> pobieranie https://wklej.to/PLLr/text wygląda AFAIK tak:
> 1) klient odpytuje DNS o wklej.to bez szyfrowania (chyba ze ma IP w
> cache'u)
> 2) klient łączy się z tym IP:443
> 3) zestawia się kanał szyfrowany
> 4) zaszyfrowanym kanałem podaje jaki adres chce
> 5) odpowiedz leci zaszyfrowanym kanałem

Rozumiem i dziekuje za odpowiedź. Prosze jesli to mozliwe o odpowiedź, czy 
jeśli uzywam zainfekowanego routera i wiem o tym. Jest możliwe otwarcie 
strony (poznanie jej pełnego adresu czyli PPLr/...)

Wydaje mi się, że tak. Nawet chyba gdzies był raport o tym wlaśnie dotyczący 
Chin.

-- 
^^

"Piotr J. Kolanok" <kolano0123@m0.mx.poczta.tlen.pl> writes:

> Rozumiem i dziekuje za odpowiedź. Prosze jesli to mozliwe o odpowiedź, czy 
> jeśli uzywam zainfekowanego routera i wiem o tym. Jest możliwe otwarcie 
> strony (poznanie jej pełnego adresu czyli PPLr/...)

Nie przy HTTPS. Poznac URL mozna dokladnie w takich samych
okolicznosciach co np. tresc strony - konieczne jest jakies zlamanie
SSL. O ile oczywiscie nie mozna wykluczyc, ze jest to mozliwe, o tyle
nie jest to nic, co (przy prawidlowym uzyciu SSL) moze ktos (np. jakis
router albo inny rzad) robic rutynowo.
-- 
Krzysztof Halasa

Krzysztof Halasa wrote:

> "Piotr J. Kolanok" <kolano0123@m0.mx.poczta.tlen.pl> writes:
> 
>> Rozumiem i dziekuje za odpowiedź. Prosze jesli to mozliwe o odpowiedź,
>> czy jeśli uzywam zainfekowanego routera i wiem o tym. Jest możliwe
>> otwarcie strony (poznanie jej pełnego adresu czyli PPLr/...)
> 
> Nie przy HTTPS. Poznac URL mozna dokladnie w takich samych
> okolicznosciach co np. tresc strony - konieczne jest jakies zlamanie
> SSL. O ile oczywiscie nie mozna wykluczyc, ze jest to mozliwe, o tyle
> nie jest to nic, co (przy prawidlowym uzyciu SSL) moze ktos (np. jakis
> router albo inny rzad) robic rutynowo.

Bardzo mnie zaciekawiło to co napisałeś. Co to znaczy rutynowo? Moim zdaniem 
wszystkie routery w Chinach rutynowo są oficjalnie nastawione na podszywanie 
się. Nie mam pojecia jak to mozna by obejść. Inaczej trzeba by było założyc, 
ze dowolna transmisja ssl jest kodowana (jabber,poczta,www) co ewidentnie 
nie jest prawdą. 

O ile moge uwierzyć, że treśc może być bardziej chroniona niż nagłówki, to 
trudno mi uwierzyć w to by rutynowo nie łamano SSL. To w koncu podstawowa 
usługa. Dla Chin oficjalnie pisza programy najlepsze firmy zachodnie.
-- 
^^

Day Fri, 27 Nov 2009 20:08:38 +0100, Bartosz Kiziukiewicz wrote:

> On Fri, 27 Nov 2009 19:14:01 +0100, MarcinF <marfi@interia.pl> wrote:
> 
>>> Skoro używasz transmisji szyfrowanej, zakładasz, że ktoś mógłby ją
>>> podsłuchiwać. Dlaczego zatem przesyłasz otwartym tekstem dane konieczne
>>> do zalogowania się do zasobu? Je też można podsłuchać.
>> 
>> co masz na mysli ? sugerujesz ze te dane sa przesylane bez szyfrowania ?
> 
> Kolega sugeruje, że jeśli preparujesz linka w sposób:
> https://user:pass@domena
> to robisz to po to, żeby komuś go dać do kliknięcia.


Niekoniecznie.
Mozesz mieć jakiś skrypt który lokalnie (np. wgetem) pobiera Ci coś przez
https:// lub ftps://. Wtedy IMO tak skonstruowany link jest najwygodniejszy.


-- 
Artur 'Bzyk' Frydel
"W Królestwie środka nigdy nie wiadomo, co jest przysłowiem, a co zwykłą
bzdurą. Dla ucha cudzoziemca jedno i drugie brzmi niebezpiecznie podobnie."

On Sun, 29 Nov 2009 22:49:36 +0100, Krzysztof Halasa wrote:

> "Piotr J. Kolanok" <kolano0123@m0.mx.poczta.tlen.pl> writes:
> 
>> Rozumiem i dziekuje za odpowiedź. Prosze jesli to mozliwe o odpowiedź, czy 
>> jeśli uzywam zainfekowanego routera i wiem o tym. Jest możliwe otwarcie 
>> strony (poznanie jej pełnego adresu czyli PPLr/...)
> 
> Nie przy HTTPS. Poznac URL mozna dokladnie w takich samych
> okolicznosciach co np. tresc strony - konieczne jest jakies zlamanie
> SSL. O ile oczywiscie nie mozna wykluczyc, ze jest to mozliwe, o tyle
> nie jest to nic, co (przy prawidlowym uzyciu SSL) moze ktos (np. jakis
> router albo inny rzad) robic rutynowo.

Zasadniczo... może. Odpowiednio zhackowany router może przypuścić MITM (man 
in the middle) attack, udając przed serwerem klienta, negocjując z nim 
połączenie SSL, a z klientem negocjując połączenie, podszywając się pod 
serwer. I wtedy cały ruch jednej strony router sobie odszyfrowuje i szyfruje 
ponownie przed wysłaniem do drugiej, a po drodze może z nim zrobić co chce - 
nie tylko podsłuchać, ale i dowolnie zmodyfikować. Cała sztuka w tym, że aby 
skutecznie dokonać takiego podszycia, trzeba albo a) liczyć na to, że 
użytkownik zignoruje niezgodność certyfikatu, albo b) być w stanie wystawić 
fałszywy certyfikat, przy którym przeglądarka nie zgłosi ostrzeżenia (jest 
kilka możliwych sposobów na osiągnięcie tego). Przy czym o ile b) może być 
nietrywialne, o tyle znając użytkowników jestem przekonany, że a) zadziała w 
więcej niż 50% przypadków.
-- 
Szymon Sokół (SS316-RIPE) -- Network Manager                                 B
Computer Center, AGH - University of Science and Technology, Cracow, Poland  O
http://home.agh.edu.pl/szymon/ PGP key id: RSA: 0x2ABE016B, DSS: 0xF9289982  F
Free speech includes the right not to listen, if not interested -- Heinlein  H

"Piotr J. Kolanok" <kolano0123@m0.mx.poczta.tlen.pl> writes:

> Bardzo mnie zaciekawiło to co napisałeś. Co to znaczy rutynowo? Moim zdaniem 
> wszystkie routery w Chinach rutynowo są oficjalnie nastawione na podszywanie 
> się.

Bylbym bardzo zdziwiony.
Filtrowanie, tak, ze tego sa znani.

> O ile moge uwierzyć, że treśc może być bardziej chroniona niż nagłówki, to 
> trudno mi uwierzyć w to by rutynowo nie łamano SSL. To w koncu podstawowa 
> usługa. Dla Chin oficjalnie pisza programy najlepsze firmy zachodnie.

A co to zmienia? Poprawne uzycie systemu certyfikatow powoduje, ze takie
ataki sa nieskuteczne. Przynajmniej do momentu zlamania algorytmu(ow).
-- 
Krzysztof Halasa

Szymon Sokół <szymon@bastard.operator.from.hell.pl> writes:

> Zasadniczo... może. Odpowiednio zhackowany router może przypuścić MITM (man 
> in the middle) attack, udając przed serwerem klienta, negocjując z nim 
> połączenie SSL, a z klientem negocjując połączenie, podszywając się pod 
> serwer. I wtedy cały ruch jednej strony router sobie odszyfrowuje i szyfruje 
> ponownie przed wysłaniem do drugiej, a po drodze może z nim zrobić co chce - 
> nie tylko podsłuchać, ale i dowolnie zmodyfikować.

Tyle ze to zostanie natychmiast wykryte.
Takie cos mozna probowac robic przeciwko jakiemus konkretnemu
przeciwnikowi, ale nie przeciwko wszystkim.

> Cała sztuka w tym, że aby 
> skutecznie dokonać takiego podszycia, trzeba albo a) liczyć na to, że 
> użytkownik zignoruje niezgodność certyfikatu, albo b) być w stanie wystawić 
> fałszywy certyfikat, przy którym przeglądarka nie zgłosi ostrzeżenia (jest 
> kilka możliwych sposobów na osiągnięcie tego). Przy czym o ile b) może być 
> nietrywialne,

I dosc niepewne, zwlaszcza ze potrzebujemy praktycznie 100% skutecznosci
przy takiej masowce.

> o tyle znając użytkowników jestem przekonany, że a) zadziała w 
> więcej niż 50% przypadków.

Ale to zdecydowanie za malo. Nawet 99% oznacza, ze co setny uzytkownik
zauwazy co sie dzieje, i natychmiast wszyscy beda o tym wiedziec.
-- 
Krzysztof Halasa

On Mon, 30 Nov 2009 21:32:32 +0100, Krzysztof Halasa wrote:

> "Piotr J. Kolanok" <kolano0123@m0.mx.poczta.tlen.pl> writes:
> 
>> Bardzo mnie zaciekawiło to co napisałeś. Co to znaczy rutynowo? Moim zdaniem 
>> wszystkie routery w Chinach rutynowo są oficjalnie nastawione na podszywanie 
>> się.
> 
> Bylbym bardzo zdziwiony.
> Filtrowanie, tak, ze tego sa znani.
> 
>> O ile moge uwierzyć, że treśc może być bardziej chroniona niż nagłówki, to 
>> trudno mi uwierzyć w to by rutynowo nie łamano SSL. To w koncu podstawowa 
>> usługa. Dla Chin oficjalnie pisza programy najlepsze firmy zachodnie.
> 
> A co to zmienia? Poprawne uzycie systemu certyfikatow powoduje, ze takie
> ataki sa nieskuteczne. Przynajmniej do momentu zlamania algorytmu(ow).

Jeśli kontrolujesz przynajmniej jedno CA uznawane przez popularne
przeglądarki, możesz generować "lewe" certyfikaty. 
-- 
Szymon Sokół (SS316-RIPE) -- Network Manager                                 B
Computer Center, AGH - University of Science and Technology, Cracow, Poland  O
http://home.agh.edu.pl/szymon/ PGP key id: RSA: 0x2ABE016B, DSS: 0xF9289982  F
Free speech includes the right not to listen, if not interested -- Heinlein  H

>>> Rozumiem i dziekuje za odpowiedź. Prosze jesli to mozliwe o odpowiedź,
>>> czy jeśli uzywam zainfekowanego routera i wiem o tym. Jest możliwe
>>> otwarcie strony (poznanie jej pełnego adresu czyli PPLr/...)
>> 
>> Nie przy HTTPS. Poznac URL mozna dokladnie w takich samych
>> okolicznosciach co np. tresc strony - konieczne jest jakies zlamanie
>> SSL. O ile oczywiscie nie mozna wykluczyc, ze jest to mozliwe, o tyle
>> nie jest to nic, co (przy prawidlowym uzyciu SSL) moze ktos (np. jakis
>> router albo inny rzad) robic rutynowo.
> 
> Zasadniczo... może. Odpowiednio zhackowany router może przypuścić MITM
> (man in the middle) attack, udając przed serwerem klienta, negocjując z
> nim połączenie SSL, a z klientem negocjując połączenie, podszywając się
> pod serwer. I wtedy cały ruch jednej strony router sobie odszyfrowuje i
> szyfruje ponownie przed wysłaniem do drugiej, a po drodze może z nim
> zrobić co chce - nie tylko podsłuchać, ale i dowolnie zmodyfikować. Cała
> sztuka w tym, że aby skutecznie dokonać takiego podszycia, trzeba albo a)
> liczyć na to, że użytkownik zignoruje niezgodność certyfikatu, albo b) być
> w stanie wystawić fałszywy certyfikat, przy którym przeglądarka nie zgłosi
> ostrzeżenia (jest kilka możliwych sposobów na osiągnięcie tego). Przy czym
> o ile b) może być nietrywialne, o tyle znając użytkowników jestem
> przekonany, że a) zadziała w więcej niż 50% przypadków.

Poprosze ponownie bo nie wiem czy dokładnie zrozumiałem. Chodzi mi o wariant 
b) Zakładam dokładnego usera. Sprawdza certyfikat (czyli nie tylko kłódeczka 
mi sie zapaliła) i wie jaki ma być. Powiedzmy sprawdza odcisk. Czy w tej 
sytuacji jest możliwe nadal podsłuchanie transmisji i dowiedzenia sie o 
dalsza czesc adresu i(lub) tresc? 

W ten sposób np. program pocztowy (thunderbird) łączący się z serwerem w 
Polsce (nie ma oddziału w Chinach) było by to bezpieczne? (Ciekawi mnie czy 
thunderbird dokładnie sprawdza certyfikaty) Po roznych doniesieniach, ze 
uzywajac szyfrowanej poczty jednak smutni panowie pojawiali sie u chinskich 
dysydentow czy bankierow to bylo by dziwne. 
-- 
^^

Szymon Sokół <szymon@bastard.operator.from.hell.pl> writes:

>> A co to zmienia? Poprawne uzycie systemu certyfikatow powoduje, ze takie
>> ataki sa nieskuteczne. Przynajmniej do momentu zlamania algorytmu(ow).
>
> Jeśli kontrolujesz przynajmniej jedno CA uznawane przez popularne
> przeglądarki, możesz generować "lewe" certyfikaty. 

Ale nie w takiej skali - bo natychmiast wyjdzie to na jaw, i jedyne co
uzyskam to to, ze nikt juz temu CA nie bedzie wierzyl.
-- 
Krzysztof Halasa

On Mon, 30 Nov 2009 22:16:29 +0100, Piotr J. Kolanok wrote:

> Poprosze ponownie bo nie wiem czy dokładnie zrozumiałem. Chodzi mi o wariant 
> b) Zakładam dokładnego usera. Sprawdza certyfikat (czyli nie tylko kłódeczka 
> mi sie zapaliła) i wie jaki ma być. Powiedzmy sprawdza odcisk. Czy w tej 
> sytuacji jest możliwe nadal podsłuchanie transmisji i dowiedzenia sie o 
> dalsza czesc adresu i(lub) tresc? 

Nie. Chyba że znalazłeś jakąś słabość RSA lub algorytmów symetrycznych
stosowanych w SSL (RC4, 3DES, AES itd.), o której nikt poza Tobą jeszcze nie
wie, a która pozwala na łamanie tych szyfrów w sensownym czasie. Niektórzy
twierdzą, że np. NSA czymś takim dysponuje. Większość ludzi uważa, że to
bzdura. 
Oczywiście nawet bardzo skrupulatnego użytkownika można wprowadzić w błąd
np. podkładając mu trojana, który będzie modyfikował działanie biblioteki
SSL... no ale wtedy równie dobrze można przechwytywać dane jeszcze zanim w
ogóle się zobaczą z SSL.

> W ten sposób np. program pocztowy (thunderbird) łączący się z serwerem w 
> Polsce (nie ma oddziału w Chinach) było by to bezpieczne? (Ciekawi mnie czy 
> thunderbird dokładnie sprawdza certyfikaty) Po roznych doniesieniach, ze 
> uzywajac szyfrowanej poczty jednak smutni panowie pojawiali sie u chinskich 
> dysydentow czy bankierow to bylo by dziwne.

Znaczy, to ci smutni panowie używali szyfrowanej poczty? Bo tak wychodzi z
Twojego zdania, może przemyśl, co w zasadzie napisałeś :->

-- 
Szymon Sokół (SS316-RIPE) -- Network Manager                                 B
Computer Center, AGH - University of Science and Technology, Cracow, Poland  O
http://home.agh.edu.pl/szymon/ PGP key id: RSA: 0x2ABE016B, DSS: 0xF9289982  F
Free speech includes the right not to listen, if not interested -- Heinlein  H

On Mon, 30 Nov 2009 12:04:06 +0100, Artur Frydel
<artur.frydel@gmail.com> wrote:

> > Kolega sugeruje, że jeśli preparujesz linka w sposób:
> > https://user:pass@domena
> > to robisz to po to, żeby komuś go dać do kliknięcia.
> 
> 
> Niekoniecznie.
> Mozesz mieć jakiś skrypt który lokalnie (np. wgetem) pobiera Ci coś przez
> https:// lub ftps://. Wtedy IMO tak skonstruowany link jest najwygodniejszy.

W takim wypadku powyższe nie ma zastosowania, ale nie była to moja
sugestia ;-)

-- 
Pozdrawiam
  Bartek

Moje poglądy prezentowane w Usenecie są całkowicie prywatne.

Szymon Sokół wrote:

> On Mon, 30 Nov 2009 22:16:29 +0100, Piotr J. Kolanok wrote:
> 
>> Poprosze ponownie bo nie wiem czy dokładnie zrozumiałem. Chodzi mi o
>> wariant b) Zakładam dokładnego usera. Sprawdza certyfikat (czyli nie
>> tylko kłódeczka mi sie zapaliła) i wie jaki ma być. Powiedzmy sprawdza
>> odcisk. Czy w tej sytuacji jest możliwe nadal podsłuchanie transmisji i
>> dowiedzenia sie o dalsza czesc adresu i(lub) tresc?
> 
> Nie. Chyba że znalazłeś jakąś słabość RSA lub algorytmów symetrycznych
> stosowanych w SSL (RC4, 3DES, AES itd.), o której nikt poza Tobą jeszcze
> nie wie, a która pozwala na łamanie tych szyfrów w sensownym czasie.

SSL szyfruje też nagłówek? POST raczej tak, ale to co jest przed?
Czy szyfruje też GET?
i inne dane. Z tego co piszesz szyfruje totalnie. I chyba za każdym razem 
zestawia nowe łącze, czyli zestawia połączenie.

>> W ten sposób np. program pocztowy (thunderbird) łączący się z serwerem w
>> Polsce (nie ma oddziału w Chinach) było by to bezpieczne? (Ciekawi mnie
>> czy thunderbird dokładnie sprawdza certyfikaty) Po roznych doniesieniach,
>> ze uzywajac szyfrowanej poczty jednak smutni panowie pojawiali sie u
>> chinskich dysydentow czy bankierow to bylo by dziwne.
> 
> Znaczy, to ci smutni panowie używali szyfrowanej poczty? Bo tak wychodzi z
> Twojego zdania, może przemyśl, co w zasadzie napisałeś :->

;)
A wiesz jak thunderbird podchodzi do tych certyfikatów? Może wyjsciem było 
by wykosić wszystkie CA i zostawić tylko swoje? Wtedy nie dało by sie pobrać 
żadnego e-maila nawet z legalnym certyfikatem. Czy w wypadku zmiany 
certyfikatu, ale na legalny thunderbird by to jakoś sygnalizował?

-- 
^^

On 2009-12-02, Piotr J. Kolanok <kolano0123@m0.mx.poczta.tlen.pl> wrote:
> Szymon Sokół wrote:
>
>> On Mon, 30 Nov 2009 22:16:29 +0100, Piotr J. Kolanok wrote:
>> 
>>> Poprosze ponownie bo nie wiem czy dokładnie zrozumiałem. Chodzi mi o
>>> wariant b) Zakładam dokładnego usera. Sprawdza certyfikat (czyli nie
>>> tylko kłódeczka mi sie zapaliła) i wie jaki ma być. Powiedzmy sprawdza
>>> odcisk. Czy w tej sytuacji jest możliwe nadal podsłuchanie transmisji i
>>> dowiedzenia sie o dalsza czesc adresu i(lub) tresc?
>> 
>> Nie. Chyba że znalazłeś jakąś słabość RSA lub algorytmów symetrycznych
>> stosowanych w SSL (RC4, 3DES, AES itd.), o której nikt poza Tobą jeszcze
>> nie wie, a która pozwala na łamanie tych szyfrów w sensownym czasie.
>
> SSL szyfruje też nagłówek? POST raczej tak, ale to co jest przed?
> Czy szyfruje też GET?
> i inne dane. Z tego co piszesz szyfruje totalnie. I chyba za każdym razem 
> zestawia nowe łącze, czyli zestawia połączenie.

Szyfrowana jest całość, czyli razem z żądaniem (niezależnie czy GET,
POST, czy cokolwiek innego). A co do zestawiania połączenia, to tak jak
w normalnym HTTP/1.1 - możesz poprosić o keep-alive i masz to samo
połączenie na kilka żądań (np strona i css-y, skrypty do niej).

>>> W ten sposób np. program pocztowy (thunderbird) łączący się z serwerem w
>>> Polsce (nie ma oddziału w Chinach) było by to bezpieczne? (Ciekawi mnie
>>> czy thunderbird dokładnie sprawdza certyfikaty) Po roznych doniesieniach,
>>> ze uzywajac szyfrowanej poczty jednak smutni panowie pojawiali sie u
>>> chinskich dysydentow czy bankierow to bylo by dziwne.
>> 
>> Znaczy, to ci smutni panowie używali szyfrowanej poczty? Bo tak wychodzi z
>> Twojego zdania, może przemyśl, co w zasadzie napisałeś :->
>
> ;)
> A wiesz jak thunderbird podchodzi do tych certyfikatów? Może wyjsciem było 
> by wykosić wszystkie CA i zostawić tylko swoje? Wtedy nie dało by sie pobrać 
> żadnego e-maila nawet z legalnym certyfikatem. Czy w wypadku zmiany 
> certyfikatu, ale na legalny thunderbird by to jakoś sygnalizował?

Akurat w przypadku poczty to można jeszcze używać szyfrowania samej
wiadomości. W skrócie: szyfrujesz wiadomość kluczem publicznym odbiorcy
tak, że tylko on może to odszyfrować, następnie takiego maila wysyłasz
jakkolwiek (można też po SSLu, chociażby aby ukryć usera i hasło).
Niezależnie jak ta wiadomość będzie szła i przez jak bardzo
monitorowane/podsłuchiwane serwery tylko odbiorca będzie mógł
odszyfrować. Jedyne co widać, to że jest przesyłana wiadomość, oraz od
kogo do kogo. Treści już nie.

Szczegóły: słowa kluczowe: PGP lub S/MIME.

-- 
Pozdrawiam,
Marek Marczykowski          |   gg:2873965      | RLU #390519
marmarek at staszic waw pl  | xmpp:marmarek at staszic waw pl
http://akademia.linuksa.pl - Szkolenia Linux, PHP, Java, Office

epsilon$ while read LINE; do echo \>"$LINE"; done < "Piotr J. Kolanok"
>>> Poprosze ponownie bo nie wiem czy dokładnie zrozumiałem. Chodzi mi o
>>> wariant b) Zakładam dokładnego usera. Sprawdza certyfikat (czyli nie
>>> tylko kłódeczka mi sie zapaliła) i wie jaki ma być. Powiedzmy sprawdza
>>> odcisk. Czy w tej sytuacji jest możliwe nadal podsłuchanie transmisji i
>>> dowiedzenia sie o dalsza czesc adresu i(lub) tresc?
>> 
>> Nie. Chyba że znalazłeś jakąś słabość RSA lub algorytmów symetrycznych
>> stosowanych w SSL (RC4, 3DES, AES itd.), o której nikt poza Tobą jeszcze
>> nie wie, a która pozwala na łamanie tych szyfrów w sensownym czasie.
>
>SSL szyfruje też nagłówek? POST raczej tak, ale to co jest przed?
>Czy szyfruje też GET?

Nie czytałeś dokładnie, prawda? Najpierw zostaje wynegocjowane
połączenie SSL, a potem wewnątrz tego - już zaszyfrowanym kanałem -
zostaje przeprowadzona transakcja HTTP.

>i inne dane. Z tego co piszesz szyfruje totalnie. I chyba za każdym razem 
>zestawia nowe łącze, czyli zestawia połączenie.

Poczytaj o HTTP keep-alive.

-- 
d'`'`'`'`'`'`'`'`'`'`'`'`'Yb 
`b  Kruk@epsilon.eu.org   d' 
d' http://epsilon.eu.org/ Yb 
`b,-,.,-,.,-,.,-,.,-,.,-,.d' 

>> A wiesz jak thunderbird podchodzi do tych certyfikatów? Może wyjsciem
>> było by wykosić wszystkie CA i zostawić tylko swoje? Wtedy nie dało by
>> sie pobrać żadnego e-maila nawet z legalnym certyfikatem. Czy w wypadku
>> zmiany certyfikatu, ale na legalny thunderbird by to jakoś sygnalizował?
> 
> Akurat w przypadku poczty to można jeszcze używać szyfrowania samej
> wiadomości. W skrócie: szyfrujesz wiadomość kluczem publicznym odbiorcy
> tak, że tylko on może to odszyfrować, następnie takiego maila wysyłasz
> jakkolwiek (można też po SSLu, chociażby aby ukryć usera i hasło).
> Niezależnie jak ta wiadomość będzie szła i przez jak bardzo
> monitorowane/podsłuchiwane serwery tylko odbiorca będzie mógł
> odszyfrować. Jedyne co widać, to że jest przesyłana wiadomość, oraz od
> kogo do kogo. Treści już nie.

Prawie dobrze ;-)
Nie szyfruje sie np. kiedy, którędy oraz TEMATU! W żadnym przypadku nie 
szyfruje się tematu. Może ktoś nie wiedzieć więc piszę. 

Niestety pozostaje sam fakt szyfrowania. 
-- 
^^

"Piotr J. Kolanok" <kolano0123@m0.mx.poczta.tlen.pl> writes:

> A wiesz jak thunderbird podchodzi do tych certyfikatów? Może wyjsciem było 
> by wykosić wszystkie CA i zostawić tylko swoje?

Jest to standardowa procedura w niektorych zastosowaniach.

> Czy w wypadku zmiany 
> certyfikatu, ale na legalny thunderbird by to jakoś sygnalizował?

Watpie.
-- 
Krzysztof Halasa

Bartosz Kiziukiewicz <kiziuk@epf.bez-tego.pl> wrote:
> On Mon, 30 Nov 2009 12:04:06 +0100, Artur Frydel
> <artur.frydel@gmail.com> wrote:
> 
> > > Kolega sugeruje, że jeśli preparujesz linka w sposób:
> > > https://user:pass@domena
> > > to robisz to po to, żeby komuś go dać do kliknięcia.
> > 
> > 
> > Niekoniecznie.
> > Mozesz mieć jakiś skrypt który lokalnie (np. wgetem) pobiera Ci coś przez
> > https:// lub ftps://. Wtedy IMO tak skonstruowany link jest najwygodniejszy.
> 
> W takim wypadku powyższe nie ma zastosowania, ale nie była to moja
> sugestia ;-)

Ma, bo w takim wypadku hasło można sobie podpatrzeć np. za pomocą "ps". 

Pozdrawiam,

			Krzysztof Oledzki

-- 
Krzysztof Olędzki
e-mail address:		ole(a-t)ans(d-o-t)pl
Registered User:	Linux - 189200, BSD - 51140
Nick Handles:		KO60-RIPE, KO581 (Network Solutions)