@Lizard - korzystam z różnych hostingów dla siebie i klientów i jeszcze się nie spotkałem, by Let's Encrypt się autmatycznie nie przedłużał.

Wszystko zalezy co hostingowa firma zaproponowala. Jesli ma w ofercie SSL certy z np Let's Encrypt'a to zazwyczaj jest tez dzialajaca funkacja automatycznego odnawiania, a i  tez to wszsytko zalezy od roznych czynnikow jak czy SSL cert jest dla jednego url'a, czy jest SAN czy jest wildcard.
Od tego jaki typ to jest certa, zalezy metoda uwiezytelnienia podacz generowania certa - np. wildcard mozna tylko uwiezytlnic po przez rekod(y) w DNS'ie a DNS mozna trzymac w firmie hostingowej tam gdzie sie hostuje strone, albo tam gdzie sie kupilo domene, i w tym drugim przypadku juz tak latwo automatycznie donowic certa z  Let's Encrypt sie nie da.

Kolega Lizard piszac ze cert trzeba odnawiac co 3 miesiace podal poprostu ogolna zasade jaka sie taki cert zadzi (wygasa co 3 miesiace).

Ja np hostuje swoje zeczy sam na moim serwerze i calosc musze ogarniac po swojemu.

Jeżeli masz na myśli zamianę po stronie klienta hasła w coś innego (np. hash) i przesłanie w takiej formie, to nie jest to żadne zabezpieczenie. Żaden szanujący się system nie trzyma hasłem w otwartej postaci - zawsze są to hashe. I to właśnie one, a nie hasła, są porównywane podczas uwierzytelniania.

Żaden szanujący się system (sieciowy) nie porównuje ani haseł ani ich hashy podczas uwierzytelniania.

Nigdzie nie pisałem o trzymaniu hasła w postaci jawnej, po to właśnie są hashe :)

Już na spokojnie, bo pisanie jednym ciągiem wprowadza trochę bałaganu. W bazie trzymany jest hash (np. Argon2id). Porównanie odbywa się na serwerze, który ma od klienta hasło i hash z bazy.

I jak najbardziej algo generuje różne hashe dla tego samego ciągu, tu przykład Bcrypt:
https://bcrypt-generator.com/
ciąg: ccwrc
wygenerowane hashe:
$2a$12$oigG3gG7jlroHTTzTL/beeCRVxi7FNj1rkGw3dseHv3K8gbksxbIC
$2a$12$5boL5FfyLKNSlyNHKFTLCO6vumXUVJ04afwfXJnvTU9ICEmVyn6K2
$2a$12$DrL6oFP9qz98Mbss1VRh5OtnrDvIL8ite1TDvet2km8brYa84qiWK

Jak chcesz, możesz dodatkowo sprawdzić zgodność hasha z hasłem (ccwrc) na innej stronie:
https://bcrypt.online/

Może pewne zamieszanie wynikać z tego, że checksum (np. MD5) jest mylone z hashem a to zupełnie inne rzeczy. Checksum zawsze da taki sam ciąg wyjściowy dla określonego ciągu wejściowego.

Niniejszym piszę, że wiem jak działa SSL, wiem po co jest, wiem co zapewnia i wiem, że jest do podsłuchania/obejścia po jednej ze stron łącza (właściwie po obu, ale łatwiej po stronie użytkownika).

Dane, przed wysłaniem i po odebraniu, są w postaci niezaszyfrowanej, więc nie ma za bardzo sensu ich podsłuchiwania - wystarczy po nie sięgnąć. Przed tym procederem powinien chronić antywirus, którego skuteczność nie jest przedmiotem tej dyskusji.

Tak, osłabiono algorytm A5/1 stosowany w sieciach GSM na potrzeby eksportowe USA do krajów z ograniczeniami importowania produktów z funkcjami szyfrowania. Najpopularniejsze algorytmy szyfrowania symetrycznego używają kluczy: 56-bitowych (DES), 112 (3DES), 128/256 (AES), więc długość klucza jest wydłużana. W przypadku szyfrowania asymetrycznego początkowo stosowano klucze 768-bitowe, ale od wielu lat zaleca się stosowanie 2048-bitowych i dłuższych.

Może i nazywa się Man In The Middle, z tym że próba podsłuchiwania wymaga podmiany certyfikatów wykorzystywanych do ustalenia klucza symetrycznego, co kończy się informacją o błędnym certyfikacie serwera. Zebranie danych zaszyfrowanych, aby rozszyfrować je off-line mija się z celem, ze względu na czas potrzebny do tej czynności.

Musisz mieć możliwość zweryfikowania, czy otrzymany "kod szyfrujący" pochodzi z właściwego źródła. Do tego służą certyfikaty. Inaczej zły człowiek przechwyci transmisję, w miejsce "kodu szyfrującego" serwera wstawi własny i prześle do klienta. Dalej mamy klasyczne MITM.

Odwrotnie, to samo hasło zawsze da ten sam hash. Dopiero dodawanie losowej soli do hasła daje różne hashe. Kolizja jest wtedy, gdy dwie różne dane dają ten sam skrót.

Jak chcesz "hasło" porównać z "610881de40fac65b12445aef6c603234" (MD5 tylko dla przykładu)? :-) Trzymanie haseł w postaci jawnej jest skrajnie nieodpowiedzialne. Przechowuje się hashe i ew. sól. Podczas uwierzytelniania do przesłanego hasła dodawana jest sól, z tego obliczany jest skrót i dopiero to jest sprawdzane.

Certyfikaty Let's Encrypt ważne są trzy miesiące i dobrze jest mieć narzędzie do automatycznego odnawiania. Poza tym na hoscie trzeba mieć możliwość włączenia szyfrowania spełniającego współczesne wymogi. :-p

A co ma JS? ano to, że serwer wysyła określony kod szyfrujący JS z określonymi kluczami publicznymi, haszuje i szyfruje hasło, wysyła na serwer, a serwer kluczem prywatnym (i publicznym) sobie to odszyfrowuje i porównuje hasz. Nie wiem, czy takie rozwiązania są stosowane pewnie tak. Ale jest to jak najbardziej możliwe i bezpieczne, jeśli nie będzie luk.

Trzeba też używać SSL w najnowszej wersji, bo starsze zostały złamane i nie dają żadnej ochrony.

A co to za dziwne stwierdzenie? Czyżby algorytm liczb pierwszych został właśnie odkryty?

Obecnie używa się TLS, ale to po prostu rozszerzenie SSL.

Pytanie czy ktoś się boi, że ukradną jego hasło i będą pisać pod jego nickiem np. kiełbasę wyborczą :)
Ale za to powinien się poważnie bać ten, kto używa tego samego hasła na forum i np. w banku. Bo prędzej czy później botnety zaczną tym hasłem się posługiwać.

A nie po to żeby uniemożliwić łatwe przechwytywanie haseł podczas logowania? :]

Temu dokładnie służy - ochronie transmisji przed wścibskimi, w tym danych niejawnych, jak: hasła, numery kart płatniczych, ciasteczka itp.

Jest bardzo prawdopodobne, że duża część ludzi uznaje SSL, jako ochronę prywatności, bo często jest to tak przedstawiane. U mnie trzy z czterech stron, będącymi pierwszymi wynikami wyszukiwania hasła "ssl prywatność", przedstawia SSL jako:

Powyżej ewidentnie pomylono prywatność z możliwością przechwycenia transmitowanych danych.

Jeżeli masz na myśli zamianę po stronie klienta hasła w coś innego (np. hash) i przesłanie w takiej formie, to nie jest to żadne zabezpieczenie. Żaden szanujący się system nie trzyma hasłem w otwartej postaci - zawsze są to hashe. I to właśnie one, a nie hasła, są porównywane podczas uwierzytelniania.

A nie po to żeby uniemożliwić łatwe przechwytywanie haseł podczas logowania? :]

Edit: skoro już edytowałeś... Co ma JS do tego co napisałeś? Po co w ogóle używać JS do opisanego przypadku? Chodzi tylko i wyłącznie o jawność/niejawność danych pomiędzy klientem a serwerem.

Hasła można przesyłać bezpiecznie - przecież jest javascript czy inne rozwiązania - można tego użyć do zamiany hasła na cokolwiek, zanim się to prześle internetami.