Pytanie:
Czy szyfrowanie jest nadal stosowane, jeśli zignorujesz ostrzeżenie o certyfikacie SSL dla certyfikatów z podpisem własnym?
Damien.Rick
2019-07-18 15:07:16 UTC
view on stackexchange narkive permalink

Czy szyfrowanie będzie nadal stosowane w komunikacji z urządzeniami korzystającymi z certyfikatów z podpisem własnym, jeśli zignorujesz ostrzeżenie i kontynuujesz bez instalowania certyfikatu? Czy musisz go zainstalować, aby zapewnić szyfrowanie, czy też będzie domyślnie szyfrować, gdy użytkownik zignoruje ostrzeżenie i kontynuuje?

Rozumiem, że część dotycząca integralności lub walidacja serwera lub urządzenia przez urząd certyfikacji nie jest stosowana, ale chciałem tylko wiedzieć, czy część szyfrowania zostanie zastosowana, jeśli zignorujemy ostrzeżenie przeglądarki i kontynuujemy.

Jeśli instalacja jest wymagana, W środowisku, w którym logujesz się tylko z sieci wewnętrznej do zasobu tylko wewnętrznego przez https itp., powiedzmy, portal wewnętrzny, czy zaleca się dodanie tego certyfikatu z podpisem własnym do listy zaufanych, aby zastosować szyfrowanie, a ataki MiTM nie byłyby w stanie zobaczyć przesłanych poświadczeń. W przypadku czysto wewnętrznej konfiguracji produkcyjnej (zakładając, że urząd certyfikacji nie jest jeszcze skonfigurowany), jakie byłyby najlepsze praktyki w przypadku certyfikatów z podpisem własnym.

A tak przy okazji, nie jest to ostrzeżenie z podpisem własnym, to ostrzeżenie o braku zaufania (wystawca).Jeśli samodzielnie zweryfikujesz wystawcę (sprawdzając odcisk palca certyfikatu), może to być nawet bezpieczniejsze niż zaufanie któregokolwiek z setek międzynarodowych urzędów certyfikacji, że wykonają swoją pracę poprawnie.
Z pewnym odstąpieniem od ręki to właśnie robi Anonymous Diffie-Hellman (ADH).W TLS podczas korzystania z ADH serwer nawet nie przejmuje się wysyłaniem swojego certyfikatu (jeśli taki posiada).Wysyła tylko klucz publiczny DH do klienta.
Znawcy są jednym z największych wektorów zagrożeń.„Tylko do użytku wewnętrznego” nie powinno być brane pod uwagę!(Może nawet istnieć dramatycznie podwyższone ryzyko, że pojedyncza osoba przejmie wszystkie role potrzebne do zaaranżowania samego ataku MITM).
Dupe https://security.stackexchange.com/questions/110334/is-my-ssl-connection-encrypted-if-the-certificate-isnt-trusted
Siedem odpowiedzi:
Lie Ryan
2019-07-18 15:25:55 UTC
view on stackexchange narkive permalink

Jeśli zignorujesz certyfikat ostrzegający, że szyfrowanie jest nadal stosowane, ale ponieważ jest to szyfrowanie nieuwierzytelnione, szyfrowanie jest bezużyteczne wobec aktywnego przeciwnika (przeciwnika MITM, który może przechwytywać i modyfikować przechodzące przez niego dane), ponieważ aktywny przeciwnik może po prostu ponownie zaszyfruj połączenie.

Najlepszą praktyką w przypadku używania certyfikatu z podpisem własnym w środowisku produkcyjnym jest porównanie odcisku cyfrowego certyfikatu z oczekiwanym odciskiem cyfrowym certyfikatu uzyskanym za pośrednictwem zaufanego kanału. Po zweryfikowaniu odcisku palca certyfikatu należy przypiąć certyfikat, dodając go do listy zaufanych. Ponadto, jeśli potrzebujesz pracować z wieloma certyfikatami i wieloma urządzeniami, możesz utworzyć własny urząd certyfikacji i dodać ten certyfikat głównego urzędu certyfikacji do listy głównych zaufanych ośrodków.

Dzięki za to, dla aktywnego przeciwnika - nadal potrzebowałby klucza prywatnego serwera, prawda?Jeśli przechwycą ruch, będą ponownie zaszyfrowane dane, aby je ponownie odszyfrować i ponownie zaszyfrować, potrzebowałby klucza prywatnego urządzenia / serwera, do którego klient przesyła dane?Zakładając, że nie włamał się jeszcze na serwer docelowy.
@Damien.Rick: aktywny przeciwnik nie potrzebuje klucza prywatnego serwera do przechwycenia, po prostu musi przechwycić uzgadnianie i wysłać własny certyfikat z podpisem własnym do twojego klienta, a twój klient po prostu go zaakceptuje, ponieważ nie sprawdza poprawności połączeń„certyfikat.
@Damien.Rick nie, nie potrzebują żadnego kompromisu z serwerem docelowym, atak typu man-in-the-middle spowodowałby, że atakujący byłby „serwerem” komunikującym się z Tobą, a „Tobą” komunikującym się z serwerem,i mają dwa oddzielne kanały SSL, które są zabezpieczone przed pasywnym nasłuchiwaniem, ale nie przed przechwytującym proxy w środku.
Zasadniczo osoba atakująca pokazuje * inny * certyfikat z podpisem własnym, przed którym przepuszczasz wielkie ostrzeżenie, a następnie przekazuje dane do właściwego serwera.PKI zapobiega temu, sprawiając, że nazwa zwyczajowa (CN) certyfikatu jest wiarygodna, ale ręczna wymiana odcisków palców jest równie dobra!
Sjoerd
2019-07-18 15:32:36 UTC
view on stackexchange narkive permalink

Tak, komunikacja jest nadal szyfrowana za pomocą certyfikatów z podpisem własnym.

Certyfikaty z podpisem własnym mogą być tworzone przez Ciebie, ale może je również wykonać każdy atakujący. Jeśli nalegasz na używanie certyfikatów z podpisem własnym, radzę Ci oznaczyć certyfikat jako zaufany, aby otrzymać ostrzeżenie, jeśli ma miejsce aktywny atak typu man-in-the-middle.

Tworzenie własny certyfikat CA nie jest tak naprawdę trudniejszy niż utworzenie certyfikatu z podpisem własnym i ma tę zaletę, że możesz tworzyć zaufane certyfikaty teraz iw przyszłości, po prostu ufając swojemu certyfikatowi CA.

Oczywiście należy szczególnie uważać na klucze prywatne urzędu certyfikacji, ponieważ jeśli zostaną one naruszone, osoba atakująca może utworzyć w Twoim imieniu własne ważne certyfikaty - wyciek pojedynczego klucza naruszy wszystkie inne certyfikaty pochodzące z urzędu certyfikacji.Wyciekający klucz prywatny dla certyfikatu końcowego naraża połączenie z tym jednym serwerem, ale nie wpływa na żadne inne certyfikaty w systemie, w przeciwieństwie do wyciekającego zaufanego klucza CA.
Jeśli chcesz użyć niestandardowego urzędu certyfikacji, powinien on obejmować pojedynczą domenę, której jesteś właścicielem, a nie fałszywy główny urząd certyfikacji.
Ogólnie rzecz biorąc, zarządzanie niestandardowym urzędem certyfikacji jest dość skomplikowanym procesem, jeśli faktycznie chcesz, aby był bezpieczny.Pomyśl o ceremoniach podpisywania kluczy, fizycznie bezpiecznym przechowywaniu kluczy offline, regularnej rotacji kluczy pośrednich i tak dalej.To nie jest dla osób o słabym sercu.
mat
2019-07-18 17:08:56 UTC
view on stackexchange narkive permalink

Kryptografia ma trzy główne cele bezpieczeństwa:

  • Poufność
  • Integralność
  • Uwierzytelnianie

Certyfikat w protokole TLS / SSL handshake służy do zapewnienia uwierzytelnienia, tj. zagwarantowania klientowi, że rozmawia z wybranym serwerem, a nie z jakimś atakującym Man in the middle . Zignorowanie ostrzeżenia o certyfikacie zniszczy tę właściwość połączenia.

Połączenie będzie nadal zabezpieczone metodami kryptograficznymi w celu zapewnienia poufności i integralności, tj. Tylko początkowi partnerzy komunikacyjni (kimkolwiek są) będą mogli czytać lub zmodyfikuj wiadomość.

Jonathan Widdicombe
2019-07-19 14:35:56 UTC
view on stackexchange narkive permalink

Szyfrowanie jest nadal stosowane, problem z samopodpisanymi certyfikatami polega na tym, że nie masz pewności, że serwer, z którym się łączysz, jest tym, za kogo się podaje.

Problem nie polega na tym, że są one podpisany samodzielnie, to znaczy, że nie są podpisane przez zaufaną firmę zewnętrzną. Podczas przeglądania witryny https komputer sprawdza, czy otrzymany certyfikat został podpisany przez zaufaną stronę trzecią, co oznacza, że ​​jeśli nie doszło do naruszenia bezpieczeństwa serwera, łączysz się za pośrednictwem szyfrowanego kanału i to z kim się łączysz, jest tym, za kogo się podaje. Z podpisem własnym nie możesz być pewien drugiej części.

ulidtko
2019-07-19 23:26:01 UTC
view on stackexchange narkive permalink

Pozwól, że narysuję dla Ciebie MITM.

  === | Gdy akceptujesz certyfikat z podpisem własnym | === === | i miej szczęście | === + - [Twoja przeglądarka] - + + - [Serwer S] - + | akceptuje cert A | | ma cert A || wysyła + --------------------- + ------------------- > ma klucz A || POST / sekret | | | odszyfrowuje || szyfruje dla A | + ------ + ----- + | | + ------------------ + pahQu: eiSh6m | widzi | (widoczne na drucie) | POST / sekret | + -------------- + === | Kiedy odrzucasz ostrzeżenia przeglądarki | === === | i zaakceptuj cokolwiek | === + - [Twoja przeglądarka] - + + --- [serwer Złego Chrisa] ---- + + - [Serwer S] - + | akceptuje cert M | | | | || wysyła | | ma certyfikat M | akceptuje | | ma cert A || POST / secret + - + --- > ma klucz M | cert A + --- + - > ma klucz A || szyfruje dla M | | | odszyfrowuje | ponownie szyfruje | | | odszyfrowuje | + ------------------ + | | dla A | | | | | | ! WIDZI! | | | widzi | + ------------ + | POST / sekret | | | POST / sekret | fex5be; P [ivR + --------------------------- + | + -------------- + (widoczne na przewodzie) | + ----- + ------ + Qui8paeY] u0V (widoczne na kablu)  

Widzisz? Szyfrowanie jest trochę bezużyteczne (tj. Łatwe do pokonania) bez uwierzytelnienia.

„Prawdziwe” (nie z podpisem własnym) certyfikaty zapewniają uwierzytelnianie: sposób, w jaki przeglądarka może stwierdzić, czy komunikuje się z serwerem kontrolowanym przez właściciela witryny / domeny, czy też z zupełnie innym komputerem.

To powiedziany; tak szyfrowanie jest nadal stosowane. Nawet z fałszywymi certyfikatami nadal masz ochronę przed pasywnym podsłuchiwaniem. Jednak w zasadzie niektóre urządzenia sieciowe mogą wykrywać certyfikaty z podpisem własnym i wykonywać SSL MITM w sposób, który wygląda na całkowicie pasywny, niewidoczny, dopóki nie zaczniesz sprawdzać dokładnych dopasowań bajtów w odciskach palców.

W przypadku intranetu użyj, skonfiguruj CA i przypnij / ufaj jego korzeniom.


Przy okazji, jeśli nadal myślisz, że musisz płacić za zielony HTTPS - sprawdź https://letsencrypt.org / TERAZ.
Ci goście, autorzy Let's Encrypt, EFF, toczą dobrą walkę o ochronę Twoich praw cyfrowych.
Dowiedz się więcej samodzielnie.

LunarGuardian
2019-07-19 20:59:44 UTC
view on stackexchange narkive permalink

Tak, stosowane jest szyfrowanie. Ostrzeżenie to po prostu powiadamia Cię, że tożsamość serwera, do którego wysyłasz zaszyfrowane dane, może nie być tym, za kogo się podaje, dlatego informacje, które wysyłasz przez zaszyfrowane połączenie, mogą trafiać do nieuprawnionej strony . Zaakceptowanie certyfikatów z podpisem własnym może być niebezpieczne, ponieważ każdy może wygenerować certyfikat, podając się za kogokolwiek innego.

Jeśli jednak jesteś właścicielem certyfikatu i masz pewność, że Twój klucz prywatny do certyfikatu nie został naruszony, lub możesz potwierdzić, że osoba, która przedstawiła certyfikat, posiada klucz prywatny do certyfikatu (również upewniając się, że nie został naruszony), możesz zaufać połączeniu, w takim przypadku możesz zainstalować certyfikat jako zaufany katalog główny, aby poinformować komputer, że ufasz połączeniom z serwerem prezentującym ten certyfikat. Nie jest to jednak wymagane do włączenia szyfrowania, szyfrowanie jest nadal stosowane po zignorowaniu ostrzeżenia.

Bass
2019-07-20 23:42:59 UTC
view on stackexchange narkive permalink

Szyfrowanie nadal będzie działać. Jest jednak w większości bezużyteczny .

TLS ma na celu zapewnienie, że połączenie między punktami końcowymi jest bezpieczne. Aby tak się stało, istotne jest, aby punkty końcowe mogły się wzajemnie identyfikować. Ponieważ udostępnianie tajemnicy każdej innej witrynie jest niepraktyczne dla każdego punktu końcowego, zaufana strona trzecia (urzędy certyfikacji) jest używana do weryfikacji własności każdego (asymetrycznego) sekretu.

Po kliknięciu „tak, idź na już, kogo to obchodzi ”w ostrzeżeniu pomijasz tę weryfikację i nie masz absolutnie pojęcia, kto jest po przeciwnej stronie.

Innymi słowy:

Jeśli komuś uda się kiedykolwiek podszywać się pod witrynę, do której zamierzasz wysłać swoje prywatne dane, zobaczysz tylko to ostrzeżenie . Nie ignoruj ​​tego.

Zamiast tego powinieneś zainstalować konkretny certyfikat z podpisem własnym jako „zaufany certyfikat” na komputerach klienckich lub nawet lepiej, mieć drugi koniec używaj certyfikatów LE zamiast certyfikatów z podpisem własnym.



To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 4.0, w ramach której jest rozpowszechniana.
Loading...