Jak mogę załagodzić lukę w zabezpieczeniach / obejście luki SSLV3 POODLE (CVE-2014-3566)?

158

Po BEAST ataku i Błąd Heartbleed , teraz słyszałem o nowej luce w SSL / TLS nazywanej POODLE . Jak chronić się przed wyzyskiem?

  • Występują tylko serwery lub klienci?
  • Czy jest to specyfikacja OpenSSL / GnuTLS?
  • Jaki rodzaj usług dotyczy? Tylko HTTPS lub też IMAPS, SMTPS, OpenVPN itd.?

Pokaż przykłady, jak uniknąć tej luki.

    
zadawane gertvdijk 15.10.2014, 01:49
źródło

4 odpowiedzi

210

Informacje o tle

SSL ma na celu zabezpieczenie poziomu transportu w Internecie. W przypadku "sieci", czyli HTTP, będziesz znał to jako HTTPS, ale jest również używany w innych protokołach aplikacji. Protokół SSLv2 był pierwszym szeroko stosowanym protokołem bezpieczeństwa transportu, ale wkrótce został wykryty jako niebezpieczny. Następcy SSLv3 i TLSv1 są obecnie szeroko wspierane. TLSv1.1 i TLSv1.2 są nowsze i zyskują również duże wsparcie. Większość, jeśli nie wszystkie przeglądarki internetowe wydane od 2014 roku, mają do niego wsparcie.

Niedawne odkrycie inżynierów Google wskazuje, że nie powinno się już używać SSLv3 (podobnie jak protokół SSLv2 jest przestarzały już dawno temu). Klienci, którzy nie będą mogli połączyć się z Twoją witryną / usługą, są prawdopodobnie bardzo ograniczeni. CloudFlare ogłosiło , że mniej niż 0,09% odwiedzających nadal polega na SSLv3.

Proste rozwiązanie: wyłącz SSLv3.

Czy Ubuntu zapewnia aktualizację?

Tak, przez usn-2385-1 z dodatkiem funkcji SCSV, ale nie całkowicie eliminuje problem , ponieważ nie wyłącza SSLv3, a poprawka działa tylko wtedy, gdy obie strony połączenia zostały załatane. Otrzymasz go za pośrednictwem regularnych aktualizacji zabezpieczeń w menedżerze pakietów.

Wciąż TY musisz sam podjąć działanie, aby wyłączyć SSLv3 (można go skonfigurować). Przyszłe wersje klientów / przeglądarek najprawdopodobniej wyłączą SSLv3. Na przykład. Firefox 34 zrobi to.

Całkowite wyłączenie SSLv3 domyślnie w Ubuntu na poziomie implementacji prawdopodobnie zepsuje pewne rzeczy również w przypadku użycia SSL bez HTTPS, które nie jest tak bardzo podatne na ataki, więc zakładam, że opiekunowie tego nie zrobią i tylko ta łatka SCSV będzie zastosowany.

Dlaczego aktualizacja SCSV w OpenSSL za pośrednictwem usn-2385-1 nie łagodzi problemu?

Naprawdę, przestań zadawać takie pytania i po prostu pomiń kilka akapitów i wyłącz SSLv3. Ale hej, jeśli nie jesteś przekonany, proszę:

POODLE pokazuje, że SSLv3 z szyframi CBC jest uszkodzony, implementacja SCSV tego nie zmienia. SCSV zapewnia tylko, że nie zmienisz wersji z jakiegoś protokołu TLS na niższy protokół TLS / SSL w razie potrzeby z atakiem typu Man-in-the-Middle wymagany w zwykłych przypadkach.

Jeśli musisz uzyskać dostęp do serwera, który nie oferuje TLS w ogóle, ale tylko SSLv3, to twoja przeglądarka tak naprawdę nie ma wyboru i musi rozmawiać z serwerem za pomocą SSLv3, który jest wtedy podatny na atak bez żadnego ataku na obniżenie wersji .

Jeśli musisz uzyskać dostęp do serwera, który oferuje również TLSv1 + i SSLv3 (co jest odradzane) i chcesz mieć pewność, że twoje połączenie nie zostanie zmienione na SSLv3 przez atakującego, to oba serwer a klient potrzebuje tej poprawki SCSV.

Aby całkowicie złagodzić problem, wyłączenie SSLv3 wystarczy i możesz być pewien, że nie zostaniesz obniżony. I nie będzie można rozmawiać z serwerami tylko SSLv3.

Okay, więc jak mogę wyłączyć SSLv3?

Zobacz poniżej w poszczególnych sekcjach aplikacji: Firefox, Chrome, Apache, Nginx i Postfix są już dostępne.

Czy dotyczy to tylko serwerów lub klientów?

Luka istnieje, jeśli zarówno serwer, jak i klient akceptują SSLv3 (nawet jeśli oba są w stanie TLSv1 / TLSv1.1 / TLS1.2 z powodu ataku polegającego na obniżeniu wersji).

Jako administrator serwera należy wyłączyć protokół SSLv3 teraz , aby zapewnić bezpieczeństwo swoim użytkownikom.

Jako użytkownik powinieneś wyłączyć SSLv3 w przeglądarce teraz , aby zabezpieczyć się podczas odwiedzania stron internetowych, które nadal obsługują SSLv3.

Czy jest to specyfikacja OpenSSL / GnuTLS / przeglądarki?

Nie. To błąd protokołu (projektu), a nie błąd implementacji. Oznacza to, że nie możesz go naprawiać (chyba że zmieniasz projekt starego SSLv3).

Tak, istnieje nowe wydanie zabezpieczeń OpenSSL , ale przeczytaj poniżej ( Ale naprawdę naprawde potrzebujesz wsparcia SSLv3 ... z powodu X, Y, Z! ), dlaczego lepiej skupić się na wyłączeniu SSLv3 w ogóle.

Czy mogę zabić SSLv3 na poziomie sieci (zapory)?

Cóż, tak, prawdopodobnie. Umieszczam to w oddzielnym poście na blogu, aby uzyskać dalsze przemyślenia i pracę. Możemy mieć magiczną zasadę iptables , której możesz użyć!

Mój wpis na blogu: Jak usunąć SSLv3 z sieci za pomocą iptables dla POODLE?

Czy jest to istotne tylko dla HTTPS, czy też dla IMAP / SMTP / OpenVPN i innych protokołów z obsługą SSL?

Obecny wektor ataku, jak pokazują badacze, działa z kontrolą tekstu jawnego wysyłanego do serwera przy użyciu Javascriptu uruchamianego na komputerze ofiary. Ten wektor nie dotyczy scenariuszy bez HTTPS bez korzystania z przeglądarki.

Ponadto, zwykle klient SSL nie zezwala na obniżenie sesji do protokołu SSLv3 (z widocznością protokołu TLSv1 + w możliwościach uzgadniania), ale przeglądarki chcą być bardzo kompatybilne wstecz i robią to. Połączenie z kontrolującym jawnym tekstem i specyficznym sposobem, w jaki budowany jest nagłówek HTTP, sprawia, że ​​można go wykorzystać.

Wniosek: wyłącz SSLv3 dla HTTPS teraz , wyłącz SSLv3 dla innych usług w następnym oknie usługi.

Jaki jest wpływ? Czy muszę odwołać i zregenerować certyfikat serwera? (Tak jak w Heartbleed)

Nie, nie trzeba obracać za to certyfikatów. Luka ujawnia odzyskiwanie tekstu jawnego z danych sesji, nie zapewnia dostępu do żadnych tajnych kluczy (ani klucza sesji, ani klucza certyfikatu).

Osoba atakująca najprawdopodobniej może jedynie kradnąć nagłówki zwykłego tekstu, takie jak pliki cookie sesji, aby wykonać przechwycenie sesji . Dodatkowym ograniczeniem jest konieczność pełnego (aktywnego) ataku MitM .

Czy jest coś jeszcze, co mogę zrobić, aby ogólnie poprawić moją konfigurację SSL?

Jako użytkownik, oprócz wyłączania SSLv3 w przeglądarce, nie jest tak naprawdę. Zawsze instaluj najnowsze aktualizacje zabezpieczeń.

Dla serwerów, postępuj zgodnie z Przewodnikiem serwera TLS Mozilli . I przetestuj za pomocą testu Qualys 'SSL Labs . Naprawdę nietrudno uzyskać ocenę A + na swojej stronie. Po prostu zaktualizuj swoje pakiety i zastosuj zalecenia z przewodnika Mozilli.

Ale naprawdę potrzebuję wsparcia SSLv3 ... z powodu X, Y, Z! Co teraz?

No cóż, istnieje łatka, która omija atak na obniżenie poziomu klientów obsługujących protokół TLSv1, nazywany ochroną awaryjną SSLv3. Poprawi to również bezpieczeństwo TLSv1 + (przy okazji atak w dół jest trudniejszy / niemożliwy). Jest oferowany jako backport z nowszej wersji OpenSSL w poradniku bezpieczeństwa Ubuntu Security usn-2385-1 .

Big catch: zarówno klienci, jak i serwery potrzebują tej poprawki, aby działać. Tak więc, moim zdaniem, podczas aktualizowania zarówno klientów, jak i serwerów, należy uaktualnić do TLSv1 +.

Jednak, proszę, po prostu wycofaj SSLv3 w swojej sieci na razie. Staraj się ulepszyć standardy bezpieczeństwa i po prostu porzuć SSLv3.

Słyszałem o obsłudze SCSV, aby wyeliminować atak na obniżenie protokołu. Czy potrzebuję tego?

Tylko jeśli naprawdę potrzebujesz SSLv3 z jakiegoś dziwnego powodu, ale poprawia to także bezpieczeństwo w TLSv1 +, więc tak, poleciłbym go zainstalować. Ubuntu zapewnia aktualizację tej funkcji w usn-2385-1 . Otrzymasz go za pośrednictwem regularnych aktualizacji zabezpieczeń w menedżerze pakietów.

Luka w zabezpieczeniach witryn hostowanych prywatnie (np. intranet / offline).

Twoje serwery są podatne na ataki, jeśli tylko obsługują SSLv3. Kilka opcji tutaj:

  • Z OpenSSL s_client:

    openssl s_client -connect <server>:<port> -ssl3
    

    Jeśli połączenie się powiedzie, funkcja sslv3 jest włączona. Jeśli się nie uda, jest wyłączone. Gdy zawiedzie, powinieneś zobaczyć coś takiego:

    error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
    
  • Używanie nmap :

    nmap --script ssl-enum-ciphers -p 443 myhostname.tld
    

    Powinien wypisać " SSLv3: No supported ciphers found ". Dostosuj nazwę hosta / port.

  • Korzystanie z szyfrowania . Sklonuj / pobierz plik binarny i wykonaj go:

    ./cipherscan myhostname.tld
    

    Powinien nie wymienić czegokolwiek z SSLv3 w kolumnie "protokoły".

Przeglądarka Firefox

Otwórz about:config , znajdź security.tls.version.min i ustaw wartość na 1 . Następnie uruchom ponownie przeglądarkę, aby usunąć wszystkie otwarte połączenia SSL.

Firefox od wersji 34 będzie domyślnie wyłączał SSLv3 i dlatego nie wymaga żadnych działań ( source ). Jednak w momencie pisania, 33 zostało właśnie wydane, a 34 zostało ustawione na 25 listopada.

Google Chrome (Linux)

Edytuj plik /usr/share/applications/google-chrome.desktop , np.

sudo nano /usr/share/applications/google-chrome.desktop

Edytuj wszystkie wiersze zaczynając od Exec= , aby dołączyć --ssl-version-min=tls1 .

E.g. linia taka jak

Exec=/usr/bin/google-chrome-stable %U

staje się

Exec=/usr/bin/google-chrome-stable --ssl-version-min=tls1 %U

Następnie upewnij się, że w pełni zamkniesz przeglądarkę (aplikacje Chrome mogą utrzymywać Twoją przeglądarkę aktywną w tle!).

Uwaga: może być konieczne powtórzenie każdej aktualizacji pakietu google-chrome, nadpisując plik% launcher .desktop . Przeglądarka Google Chrome lub Chromium z wyłączonym domyślnie SSLv3 nie jest jeszcze anonsowana w chwili pisania.

Serwer HTTP Apache

Jeśli używasz serwera WWW Apache, który aktualnie zezwala na SSLv3, musisz edytować konfigurację Apache. W systemach Debian i Ubuntu plik to /etc/apache2/mods-available/ssl.conf . W CentOS i Fedorze plik jest /etc/httpd/conf.d/ssl.conf .Będziesz musiał dodać następujący wiersz do konfiguracji Apache z innymi dyrektywami SSL.

SSLProtocol All -SSLv2 -SSLv3

Umożliwi to wszystkie protokoły oprócz SSLv2 i SSLv3.

Podczas gdy jesteś na tym etapie, możesz rozważyć ulepszenie konfiguracji ciphersuite dla swojego serwera WWW, jak wyjaśniono na serwerze TLS Mozilli przewodnik . Dodaj na przykład:

SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
SSLHonorCipherOrder     on
SSLCompression          off
# Read up on HSTS before you enable it (recommended)
# Header add Strict-Transport-Security "max-age=15768000"

Następnie sprawdź, czy nowa konfiguracja jest poprawna (bez literówek itp.):

sudo apache2ctl configtest

I zrestartuj serwer, np.

sudo service apache2 restart

W CentOS i Fedorze:

systemctl restart httpd

Więcej informacji: Dokumentacja Apache

Teraz przetestuj: jeśli Twoja witryna jest publicznie dostępna, przetestuj ją, używając narzędzia Qualys 'SSL Labs .

Serwer Nginx

Jeśli używasz Nginx, po prostu dodaj następującą linię do swojej konfiguracji spośród innych dyrektyw SSL:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Kiedy już to zrobisz, możesz rozważyć ulepszenie konfiguracji ciphersuite na swoim serwerze internetowym, jak wyjaśniono na serwerze TLS Mozilli przewodnik . Dodaj na przykład:

ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
ssl_prefer_server_ciphers on;
# Read up on HSTS before you enable it (recommended)
# add_header Strict-Transport-Security max-age=15768000;

I zrestartuj serwer, np.

sudo service nginx restart

Dokumentacja: Dokumentacja Nginx

Sprawdź teraz: jeśli Twoja witryna jest publicznie dostępna, przetestuj ją, używając narzędzia Qualys 'SSL Labs .

Serwer WWW Lighttpd

Wersje Lighttpd & gt; 1.4.28 obsługują opcję konfiguracji, aby wyłączyć SSLv2 i v3. Wersje Lighttpd przed wersją 1.4.28 umożliwiają WYŁĄCZENIE TYLKO SSLv2. Zwróć uwagę, że Ubuntu 12.04 LTS i wcześniejsza instalacja w najlepszym przypadku lighttpd v1.4.28, a zatem prosta poprawka nie jest dostępna dla tych dystrybucji. Dlatego ta poprawka powinna być używana tylko w wersjach Ubuntu większych niż 12.04.

W przypadku wersji Ubuntu 12.04 lub Debian 6 zaktualizowany pakiet lighttpd jest dostępny z repozytorium openSUSE: link

Pakiet jest przeznaczony dla Debiana 6 (squeeze), ale działa również 12.04 (precyzyjnie)

Edytuj swój /etc/lighttpd/lighttpd.conf , aby dodać następujące wiersze po dyrektywie ssl.engine = "enable"

ssl.use-sslv2          = "disable"
ssl.use-sslv3          = "disable"

Następnie należy ponownie uruchomić usługę lighttpd z sudo service lighttpd restart i wykonać test uzgadniania ssl3 zgodnie z opisem we wcześniejszych sekcjach, aby upewnić się, że zmiana została pomyślnie wdrożona.

Zaczerpnięte z linku .

Postfiks SMTP

W przypadku "oportunistycznego protokołu SSL" (zasady szyfrowania nie są wymuszane, a także proste), nie trzeba niczego zmieniać. Nawet SSLv2 jest lepszy niż prosty, więc jeśli potrzebujesz zabezpieczyć swój serwer, powinieneś używać trybu "obowiązkowego SSL".

Aby skonfigurować tryb "obowiązkowego protokołu SSL", wystarczy dodać / zmienić ustawienia smtpd_tls_mandatory_protocols dla przychodzących połączenia i smtp_tls_mandatory_protocols dla połączeń wychodzących:

smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3
smtp_tls_mandatory_protocols=!SSLv2,!SSLv3

Opcjonalnie, jeśli chcesz wyłączyć SSLv3 również w przypadku oportunistycznego szyfrowania (nawet jeśli jest to niepotrzebne, jak wyjaśniono powyżej), wykonaj to w ten sposób:

smtpd_tls_protocols=!SSLv2,!SSLv3
smtp_tls_protocols=!SSLv2,!SSLv3

i zrestartuj Postfix:

sudo service postfix restart

Sendmail

(Niezweryfikowana edycja przez anonimowego użytkownika, nie czuję się dobrze z Sendmailem, zweryfikuj.)

Te opcje są skonfigurowane w sekcji LOCAL_CONFIG twojego sendmail.mc

LOCAL_CONFIG
O CipherList=HIGH
O ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 +SSL_OP_CIPHER_SERVER_PREFERENCE
O ClientSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3

Dovecot

W Dovecot v2.1 + dodaj następujące dane do /etc/dovecot/local.conf (lub nowego pliku w /etc/dovecot/conf.d ):

ssl_protocols = !SSLv2 !SSLv3

i zrestartuj Dovecot:

sudo service dovecot restart

W przypadku starszych wersji musisz załączyć kod źródłowy .

Courier-imap (imapd-ssl)

Courier-imap domyślnie zezwala na SSLv3 na Ubuntu 12.04 i innych. Powinieneś go wyłączyć i użyć STARTTLS zamiast wymusić TLS. Edytuj plik konfiguracji /etc/courier/imapd-ssl , aby odzwierciedlić następujące zmiany

IMAPDSSLSTART=NO
IMAPDSTARTTLS=YES
IMAP_TLS_REQUIRED=1
TLS_PROTOCOL=TLS1
TLS_STARTTLS_PROTOCOL=TLS1
TLS_CIPHER_LIST="<take those from the Mozilla TLS Server guide!>"

Serwer HAProxy

SSL jest obsługiwane w HAProxy & gt; = 1.5.

Edytuj plik /etc/haproxy.cfg i znajdź linię bind . Dołącz no-sslv3 . Na przykład:

bind :443 ssl crt <crt> ciphers <ciphers> no-sslv3

Dokumentacja: Dokumentacja HAProxy

OpenVPN

Wygląda na niezmieniony ( źródło ).

  

OpenVPN używa TLSv1.0 lub (z & gt; = 2.3.3) opcjonalnie TLSv1.2, przez co POODLE nie ma wpływu.

Lalka

Puppet używa SSL przez HTTPS, ale nie jest używany przez klientów "przeglądarek", tylko agentów Puppet, którzy nie są podatni na pokazany wektor ataku.Najlepiej jednak po prostu wyłączyć SSLv3.

Moim zaleceniem jest użycie stephenrjohnson / puppetmodule Moduł marionetek do ustawienia swojego Władcy Lalek, w którym Je pewnego razu zabiłem SSLv3 .

    
odpowiedział gertvdijk 15.10.2014, 01:49
źródło
4

Może nie być specyficzne dla Ubuntu, ale aby obejść lukę w Poodle w Node.js, możesz ustawić secureOptions na require('constants').SSL_OP_NO_SSLv3 podczas tworzenia serwera https lub tls.

Zobacz link , aby uzyskać dodatkowe informacje

    
odpowiedział 3rdEden 15.10.2014, 10:59
źródło
0

"Poprawka" dla kuriera wyłącza tls 1.1 i tls 1.2. Wydaje się, że nie ma sposobu na uruchomienie kuriera z tls 1.1 lub nowszym. Skan PCI na twoim serwerze może powrócić z zaleceniem:

Skonfiguruj serwery SSL / TLS tak, aby używały tylko TLS 1.1 lub TLS 1.2, jeśli są obsługiwane. Skonfiguruj serwery SSL / TLS tak, aby obsługiwały tylko pakiety szyfrów, które nie używają szyfrów blokowych.

    
odpowiedział PrgWiz 27.02.2015, 15:45
źródło
-1

Odkąd POODLE Vulnerability jest wadą konstrukcyjną samego protokołu, a nie błędem implementacji, nie będzie żadnych poprawek. Jedynym sposobem na złagodzenie tego jest wyłączenie SSLv3 na serwerze apache. Dodaj poniższe linie do pliku ssl.conf i wykonaj pełen wdzięku restart Apache.

SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"
    
odpowiedział Lal Krishna 16.10.2014, 00:55
źródło

Przeczytaj inne pytania na temat tagów