-
11. Data: 2019-05-22 07:40:12
Temat: Re: Odbieranie wiadomości na mikrokontrolerze
Od: Luke <l...@l...net>
> Prosty, wrecz trywialny polling http.
> esp8266 daje to w standardzie.
Apropos prywatności, czy tam jest jakiś SSL?
Czy musi to lecieć po czystym http, a user musi sobie zaimplementować
jakieś szyfrowanie?
L.
-
12. Data: 2019-05-22 09:54:48
Temat: Re: Odbieranie wiadomości na mikrokontrolerze
Od: Marek <f...@f...com>
On Wed, 22 May 2019 07:40:12 +0200, Luke <l...@l...net> wrote:
> Apropos prywatności, czy tam jest jakiś SSL?
A po co? Prawdopodobieństwo, że Atlantis będzie celem MiM jest
mniejsze niż wygrana w totka. SSL to prawie synonim paranoi.
--
Marek
-
13. Data: 2019-05-22 10:05:37
Temat: Re: Odbieranie wiadomości na mikrokontrolerze
Od: Zbych <a...@o...pl>
W dniu 22.05.2019 o 07:40, Luke pisze:
>
>> Prosty, wrecz trywialny polling http.
>> esp8266 daje to w standardzie.
>
> Apropos prywatności, czy tam jest jakiś SSL?
>
> Czy musi to lecieć po czystym http, a user musi sobie zaimplementować
> jakieś szyfrowanie?
Wystarczy zajrzeć do repo z softem:
https://github.com/espressif/ESP8266_RTOS_SDK/tree/m
aster/components
Masz tam 2 implementacje SSL do wyboru.
-
14. Data: 2019-05-22 10:15:42
Temat: Re: Odbieranie wiadomości na mikrokontrolerze
Od: Piotr Gałka <p...@c...pl>
W dniu 2019-05-22 o 07:39, Luke pisze:
> W dniu 2019-05-19 o 23:31, Mirek pisze:
>
>> Ja myślę, że kiedyś nie spuścimy nawet wody w kiblu bez zalogowania się
>> do FB.
>
> Drogi użytkowniku naszego publicznego kibla!
>
> Aby dokonać spuszczenia wody zaloguj się do naszego kiblowego serwisu
> przez Facebook!
Musieliby jeszcze zrobić jakąś blokadę drzwi bo ja nie mając Fecebooka
musiałbym zostawić nie spuszczone :)
P.G.
-
15. Data: 2019-05-22 10:41:16
Temat: Re: Odbieranie wiadomości na mikrokontrolerze
Od: Piotr Gałka <p...@c...pl>
W dniu 2019-05-22 o 07:40, Luke pisze:
>
>> Prosty, wrecz trywialny polling http.
>> esp8266 daje to w standardzie.
>
> Apropos prywatności, czy tam jest jakiś SSL?
>
> Czy musi to lecieć po czystym http, a user musi sobie zaimplementować
> jakieś szyfrowanie?
>
Nie znam szczegółów SSL. Wyprowadźcie mnie jeśli jestem w błędzie.
Jak się loguję do banku po SSL to:
- ja ufam, że to jest właściwa strona dzięki mojemu zaufaniu do 'strony
trzeciej' potwierdzającej certyfikat banku. Daje to duży poziom
zaufania, że po drugiej stronie jest faktycznie mój bank pod warunkiem,
że ktoś mi nie podrzucił wcześniej na komputer certyfikatu jakiejś innej
trzeciej strony tak, że mój komputer uznał go za zaufany (nie jest
łatwe, ale czy wykluczone).
- dużo gorzej jest w drugą stronę. Jedynym potwierdzeniem dla banku, że
ja to ja jest hasło.
Hasło 10 znakowe ma podobno siłę rzędu 55 bitów (występujące korelacje
między znakami powodują, że jeden znak typowo wnosi (o ile się nie mylę)
coś między 5 a 6 bitów). Podczas, gdy obecnie algorytmy o sile poniżej
128 bitów uważane są za słabe. Hasło powinno być wydłużane (ale nie wiem
czy w SSL jest i czy to wynika z samego SSL, czy zależy od
implementacji). Kilka lat temu na moim poprzednim komputerze sprawdzałem
- wydłużenie hasła o 20 bitów zajmowało mi około 1s. Tyle user może
jeszcze poczekać i prawie nie zauważyć. Ale to i tak dopiero 75 bitów
(10^15 razy mniej niż 128 bitów).
Tymczasem zaimplementowane szyfrowanie przez usera bez problemu może
oprzeć się na AES256 (klucze 256 bitowe).
W książce "Kryptografia w Praktyce" (polskie wydanie 2004) wyczytałem,
że kryptografia asymetryczna ma sens wtedy, gdy komunikujący się ze sobą
nie mogą się wcześniej ze sobą spotkać w celu wymiany wspólnej tajemnicy
a mają wspólnego kogoś komu ufają.
Jeśli user implementujący komunikację między sobą a mikrokontrolerem
jest w stanie spotkać się w tajemnicy z tym mikrokontrolerem i wymienić
się kluczami to nie ma powodu opierać komunikacji z nim na zaufaniu do
trzeciej strony. Tak przynajmniej mi się wydaje.
P.G.
-
16. Data: 2019-05-22 10:52:42
Temat: Re: Odbieranie wiadomości na mikrokontrolerze
Od: "Grzegorz Niemirowski" <g...@g...net>
Piotr Gałka <p...@c...pl> napisał(a):
> Nie znam szczegółów SSL. Wyprowadźcie mnie jeśli jestem w błędzie.
> Jak się loguję do banku po SSL to:
> - ja ufam, że to jest właściwa strona dzięki mojemu zaufaniu do 'strony
> trzeciej' potwierdzającej certyfikat banku. Daje to duży poziom zaufania,
> że po drugiej stronie jest faktycznie mój bank pod warunkiem, że ktoś mi
> nie podrzucił wcześniej na komputer certyfikatu jakiejś innej trzeciej
> strony tak, że mój komputer uznał go za zaufany (nie jest łatwe, ale czy
> wykluczone).
> - dużo gorzej jest w drugą stronę. Jedynym potwierdzeniem dla banku, że ja
> to ja jest hasło.
Tak jest, ale nie musi. Bank jest przykładem powszechnym ale niemówiącym
wszystkiego. Użytkownik jak najbardziej może się logować swoim certyfikatem.
Po prostu jest to stosunkowo mało spotykane bo wymaga wydania użytkownikowi
certyfikatu z kluczem.
> Jeśli user implementujący komunikację między sobą a mikrokontrolerem jest
> w stanie spotkać się w tajemnicy z tym mikrokontrolerem i wymienić się
> kluczami to nie ma powodu opierać komunikacji z nim na zaufaniu do
> trzeciej strony. Tak przynajmniej mi się wydaje.
Jak najbardziej.
--
Grzegorz Niemirowski
https://www.grzegorz.net/
-
17. Data: 2019-05-22 11:06:59
Temat: Re: Odbieranie wiadomości na mikrokontrolerze
Od: "J.F." <j...@p...onet.pl>
Użytkownik "Piotr Gałka" napisał w wiadomości grup
dyskusyjnych:qc31va$mve$1$P...@n...chmurka.ne
t...
W dniu 2019-05-22 o 07:40, Luke pisze:
>> Apropos prywatności, czy tam jest jakiś SSL?
>> Czy musi to lecieć po czystym http, a user musi sobie
>> zaimplementować
>> jakieś szyfrowanie?
>
>Nie znam szczegółów SSL. Wyprowadźcie mnie jeśli jestem w błędzie.
>Jak się loguję do banku po SSL to:
SSL sprawdza certyfikaty, czy to jest dodatkowa funkcja ?
Wydaje mi sie, ze nie sprawdza.
>- ja ufam, że to jest właściwa strona dzięki mojemu zaufaniu do
>'strony trzeciej' potwierdzającej certyfikat banku. Daje to duży
>poziom zaufania, że po drugiej stronie jest faktycznie mój bank pod
>warunkiem, że ktoś mi nie podrzucił wcześniej na komputer certyfikatu
>jakiejś innej trzeciej strony tak, że mój komputer uznał go za
>zaufany (nie jest łatwe, ale czy wykluczone).
A tych stron jest chyba wiecej niz trzy - tzn przegladarka, a moze juz
system ma zaszyte certyfikaty kilku organizacji, ktore moga sprawdzic
nastepne organizacje, ktore dopiero certyfikuja bank, albo kolejna
organizacje.
>- dużo gorzej jest w drugą stronę. Jedynym potwierdzeniem dla banku,
>że ja to ja jest hasło.
>Hasło 10 znakowe ma podobno siłę rzędu 55 bitów (występujące
>korelacje
Ba - w takim Millenium sa 4 znaki plus pesel.
Przy maskowanym hasle mozesz podajesz 4-5 znakow.
>między znakami powodują, że jeden znak typowo wnosi (o ile się nie
>mylę) coś między 5 a 6 bitów). Podczas, gdy obecnie algorytmy o sile
>poniżej 128 bitów uważane są za słabe.
Ale czego sie obawiasz - ze ktos wykradnie z banku plik z
zaszyfrowanymi haslami i zacznie rozkodowywac ?
Czy, ze ktos zacznie sie logowac na losowe hasla ?
Tu sa kolejne zabezpieczenia - np trzy podania zlego hasla blokuja
dostep.
I mam nadzieje, ze ktos w banku monitoruje, ze np z tego adresu IP
ktos probuje zgadnac haslo.
Tym niemniej ... majac opanowane tysiace komputerow w terenie (jakis
wirus), mozna by probowac losowych hasel.
Tylko - jesli szansa trafienia jest np 1:100 mln, to tysiace
komputerow nie pomoga, trzeba by miliony, zeby bank sie nie
zorientowal ...
no chyba, ze haslo krotsze i mamy szanse np 1:100 tys ... w pare dni
mozna cos trafic, bez wzbudzania podejrzen.
>Hasło powinno być wydłużane (ale nie wiem czy w SSL jest i czy to
>wynika z samego SSL, czy zależy od implementacji).
Ale haslo do banku podajesz juz przez SSL.
Sama sesja SSL ma jakis klucz szyfrowania, losowy,
>W książce "Kryptografia w Praktyce" (polskie wydanie 2004)
>wyczytałem, że kryptografia asymetryczna ma sens wtedy, gdy
>komunikujący się ze sobą nie mogą się wcześniej ze sobą spotkać w
>celu wymiany wspólnej tajemnicy a mają wspólnego kogoś komu ufają.
>Jeśli user implementujący komunikację między sobą a mikrokontrolerem
>jest w stanie spotkać się w tajemnicy z tym mikrokontrolerem i
>wymienić się kluczami to nie ma powodu opierać komunikacji z nim na
>zaufaniu do trzeciej strony. Tak przynajmniej mi się wydaje.
No i gdzies tam sa przewidziane pliki certyfikatow, rozsylane inna
droga.
Ale w wielu przypadkach dzialalnosci bankowej bedzie to nadmierne
utrudnienie.
A jak klient cos zgubi daleko od domu ?
No i zauwaz, ze teraz stawiaja na apki w telefonie - tu juz mozna
identyfikowac konkretna instalacje/telefon.
Pytanie tylko, czy tego sie nie da latwo wykrasc z telefonu.
J.
-
18. Data: 2019-05-22 11:16:18
Temat: Re: Odbieranie wiadomości na mikrokontrolerze
Od: Piotr Gałka <p...@c...pl>
W dniu 2019-05-22 o 10:52, Grzegorz Niemirowski pisze:
> Użytkownik jak najbardziej może się logować swoim
> certyfikatem.
Myślałem, że SSL narzuca wszystko w formie jakiej się domyślam na
podstawie logowania do banku.
Mam w planie zapoznać się z SSL, tylko ta cholerna doba nie chce być
dłuższa, a wręcz mam wrażenie, że robi się coraz krótsza.
P.G.
-
19. Data: 2019-05-22 11:18:17
Temat: Re: Odbieranie wiadomości na mikrokontrolerze
Od: "Grzegorz Niemirowski" <g...@g...net>
J.F. <j...@p...onet.pl> napisał(a):
> SSL sprawdza certyfikaty, czy to jest dodatkowa funkcja ?
> Wydaje mi sie, ze nie sprawdza.
Od tego jest żeby sprawdzał. Chyba, że nie rozumiem pytania :) Serwer WWW
można skonfigurować do uwierzytelniania klienta certyfkatem.
> A tych stron jest chyba wiecej niz trzy - tzn przegladarka, a moze juz
> system ma zaszyte certyfikaty kilku organizacji, ktore moga sprawdzic
> nastepne organizacje, ktore dopiero certyfikuja bank, albo kolejna
> organizacje.
To są narzędzia, trudno nazwać je stronami. Stroną jest CA, które wydając
certyfikat sprawdza tożsamość (dowód osobisty, dokumenty spółki. Lub też czy
po prostu jesteś właścicielem domeny. Stąd są różne poziomy certyfikatów.
--
Grzegorz Niemirowski
https://www.grzegorz.net/
-
20. Data: 2019-05-22 11:25:33
Temat: Re: Odbieranie wiadomości na mikrokontrolerze
Od: "Grzegorz Niemirowski" <g...@g...net>
Piotr Gałka <p...@c...pl> napisał(a):
> Myślałem, że SSL narzuca wszystko w formie jakiej się domyślam na
> podstawie logowania do banku.
SSL zajmuje się połączeniem: poufnością, integralnością i tożsamością. Sam w
sobie zawiera mechanizmy wystarczające do zalogowania się. Jednak w praktyce
używany jest tylko do potwierdzenia tożsamości serwera banku oraz
zapewnienia poufności transmisji, użytkownik loguje się hasłem. Tak więc nie
narzuca sposobu logowania. To jest trochę zaszłość historyczna. Kiedyś
logowało się haslem i to hasło latało czystym tekstem. Czy to HTTP, czy
telnet, czy POP3 czy FTP. Zeby to ucywilizować dodano w niektórych z tych
protokołów warstwę SSL, działającą w sposob dosyć przezroczysty. Protokoły
były bez zmian, hasło było nadal, ale już sam kanał transmisyjny był
zaszyfrowany. W ten sposób powstał HTTPS, POP3S czy FTPS. Telnet miał inną
historię, został zastąpiony przez nowy protokół SSH. Posiadał on przy okazji
możliwość przesyłania plików, znaną jako SFTP, niemającą związku z FTPS.
> Mam w planie zapoznać się z SSL, tylko ta cholerna doba nie chce być
> dłuższa, a wręcz mam wrażenie, że robi się coraz krótsza.
> P.G.
Na pewno warto zapoznać się z tym tematem.
--
Grzegorz Niemirowski
https://www.grzegorz.net/