https - linki z hasłami

[Artur Frydel]

Witam.

Czy wysłanie tak skonstruowanego linka;
https://username:***@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?

[Mariusz Kruk]

epsilon$ while read LINE; do echo \>"$LINE"; done < "Artur Frydel"

Post by Artur Frydel
Witam.
Czy wysłanie tak skonstruowanego linka;
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.

[Artur Frydel]

Post by Mariusz Kruk
epsilon$ while read LINE; do echo \>"$LINE"; done < "Artur Frydel"

Post by Artur Frydel
Witam.
Czy wysłanie tak skonstruowanego linka;
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:***@ftp.com tez jest evil?

[Mariusz Kruk]

epsilon$ while read LINE; do echo \>"$LINE"; done < "Artur Frydel"

Post by Mariusz Kruk

Post by Artur Frydel
Czy wysłanie tak skonstruowanego linka;
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 ;-)

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ć.

[Bartosz Kiziukiewicz]

Post by Mariusz Kruk
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:***@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.

[MarcinF]

Post by Bartosz Kiziukiewicz
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

[Artur Frydel]

Post by Bartosz Kiziukiewicz

Post by Mariusz Kruk
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 ?

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.

[Bartosz Kiziukiewicz]

On Mon, 30 Nov 2009 12:04:06 +0100, Artur Frydel

Post by Artur Frydel

Post by Bartosz Kiziukiewicz
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 ;-)

[Krzysztof Oledzki]

Post by Bartosz Kiziukiewicz
On Mon, 30 Nov 2009 12:04:06 +0100, Artur Frydel

Post by Artur Frydel

Post by Bartosz Kiziukiewicz
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

[MarcinF]

Post by Mariusz Kruk
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 ?

[Stachu 'Dozzie' K.]

Post by Artur Frydel
Witam.
Czy wysłanie tak skonstruowanego linka;
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.

[Artur Frydel]

Post by Stachu 'Dozzie' K.

Post by Artur Frydel
Witam.
Czy wysłanie tak skonstruowanego linka;
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.

[Krzysztof Halasa]

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.

[Piotr J. Kolanok]

Post by Krzysztof Halasa

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ć.

Post by Krzysztof Halasa

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/...

[Jordan Szubert]

Dnia 28-11-2009 o 13:01:59 Piotr J. Kolanok

Post by Artur Frydel

Post by Stachu 'Dozzie' K.
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

[Piotr J. Kolanok]

Post by Jordan Szubert

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.

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.

[Krzysztof Halasa]

Post by Piotr J. Kolanok
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.

[Piotr J. Kolanok]

Post by Krzysztof Halasa

Post by Piotr J. Kolanok
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.

[Krzysztof Halasa]

Post by Piotr J. Kolanok
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.

Post by Piotr J. Kolanok
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).

[Szymon Sokół]

Post by Krzysztof Halasa

Post by Piotr J. Kolanok
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.

Post by Piotr J. Kolanok
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.

[Krzysztof Halasa]

Post by Szymon Sokół

Post by Krzysztof Halasa
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.

[Szymon Sokół]

Post by Krzysztof Halasa

Post by Piotr J. Kolanok
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.

[Krzysztof Halasa]

Post by Szymon Sokół
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.

Post by Szymon Sokół
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.

Post by Szymon Sokół
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.

[Piotr J. Kolanok]

Post by Szymon Sokół

Post by Krzysztof Halasa

Post by Piotr J. Kolanok
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ół]

Post by 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. 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.

Post by Piotr J. Kolanok
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ś :->

[Piotr J. Kolanok]

Post by Szymon Sokół

Post by 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?
i inne dane. Z tego co piszesz szyfruje totalnie. I chyba za każdym razem
zestawia nowe łącze, czyli zestawia połączenie.

Post by Szymon Sokół

Post by Piotr J. Kolanok
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ł?

[Marek Marczykowski]

Post by Piotr J. Kolanok

Post by Szymon Sokół

Post by 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?
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).

Post by Piotr J. Kolanok

Post by Szymon Sokół

Post by Piotr J. Kolanok
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.

[Piotr J. Kolanok]

Post by Marek Marczykowski

Post by Piotr J. Kolanok
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.

[Mariusz Kruk]

epsilon$ while read LINE; do echo \>"$LINE"; done < "Piotr J. Kolanok"

Post by Piotr J. Kolanok

Post by Szymon Sokół

Post by 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.

Post by Piotr J. Kolanok
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.

[Krzysztof Halasa]

Post by Piotr J. Kolanok
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.

Post by Piotr J. Kolanok
Czy w wypadku zmiany
certyfikatu, ale na legalny thunderbird by to jakoś sygnalizował?

Watpie.

[Piotr J. Kolanok]

Post by Artur Frydel

Post by Stachu 'Dozzie' K.
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.