Jak załatać / obejść lukę w zabezpieczeniach SSLv3 POODLE (CVE-2014-3566)?

Po ataku BEAST i Heartbleed usłyszałem o nowej podatności w SSL / TLS o nazwie POODLE . Jak uchronić się przed wykorzystaniem?

• Czy dotyczy to tylko serwerów lub klientów?
• Czy ten OpenSSL / GnuTLS jest specyficzny?
• Jakiego rodzaju usługi to dotyczy? Tylko HTTPS, a także IMAPS, SMTPS, OpenVPN itp.?

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

Podstawowe informacje

SSL ma na celu zabezpieczenie poziomu transportu w Internecie. W przypadku „sieci”, czyli HTTP, będzie to znane jako HTTPS, ale jest również używane w innych protokołach aplikacji. SSLv2 był pierwszym powszechnie stosowanym protokołem bezpieczeństwa transportu, ale niedługo potem okazał się niepewny. Następcy SSLv3 i TLSv1 są teraz szeroko obsługiwane. TLSv1.1 i TLSv1.2 są nowsze i również zyskują duże wsparcie. Większość, jeśli nie wszystkie przeglądarki internetowe wydane od 2014 roku, obsługują tę funkcję.

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

Proste rozwiązanie: wyłącz SSLv3.

Czy Ubuntu zapewnia aktualizację?

Tak, za pośrednictwem usn-2385-1 z dodaną funkcją SCSV, ale nie ogranicza to całkowicie problemu, ponieważ nie wyłącza SSLv3, a łatka będzie działać tylko wtedy, gdy obie strony połączenia zostały załatane. Otrzymasz go poprzez regularne aktualizacje zabezpieczeń w menedżerze pakietów.

Więc nadal TY musiał sam podjąć działania w celu wyłączenia SSLv3 (to konfigurowalne). Przyszłe wersje klientów / przeglądarek najprawdopodobniej wyłączą SSLv3. Np. Firefox 34 to zrobi.

Całkowite wyłączenie SSLv3 domyślnie w Ubuntu na poziomie implementacji prawdopodobnie spowoduje uszkodzenie niektórych elementów również w przypadku użycia SSL innego niż HTTPS, który nie jest tak bardzo podatny na zagrożenia, więc zakładam, że opiekunowie tego nie zrobią i zostanie zastosowana tylko łatka SCSV.

Dlaczego aktualizacja SCSV w OpenSSL przez usn-2385-1 nie zmniejsza problemu?

Naprawdę, przestań zadawać takie pytania, 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 zepsuty, wdrożenie SCSV tego nie zmienia. SCSV dba tylko o to, aby nie obniżyć poziomu niektórych protokołów TLS do niższych protokołów TLS / SSL w razie potrzeby z atakiem Man-in-the-Middle wymaganym w zwykłych przypadkach.

Jeśli musisz uzyskać dostęp do serwera, który w ogóle nie oferuje TLS, ale tylko SSLv3, twoja przeglądarka tak naprawdę nie ma wyboru i musi rozmawiać z serwerem za pomocą SSLv3, który jest wtedy narażony 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 obniżone do SSLv3 przez atakującego, zarówno serwer, jak i klient potrzebują tej poprawki SCSV.

Aby całkowicie złagodzić problem, wystarczy wyłączenie SSLv3, wystarczy Twój koniec i możesz mieć pewność, że nie zostaniesz obniżony. Nie będziesz mógł rozmawiać z serwerami tylko SSLv3.

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

Zobacz poniżej w sekcjach dotyczących aplikacji: Firefox, Chrome, Apache, Nginx i Postfix.

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

Luka istnieje, jeśli zarówno serwer, jak i klient zaakceptują SSLv3 (nawet jeśli oba są w stanie obsługiwać TLSv1 / TLSv1.1 / TLS1.2 z powodu ataku na obniżenie wersji).

Jako administrator serwera powinieneś teraz wyłączyć SSLv3 dla bezpieczeństwa swoich użytkowników.

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

Czy to jest OpenSSL / GnuTLS / przeglądarka?

Nie. To błąd protokołu (projektu), a nie błąd implementacji. Oznacza to, że tak naprawdę nie możesz go załatać (chyba że zmienisz wygląd starego SSLv3).

I tak, pojawiła się nowa wersja bezpieczeństwa OpenSSL , ale przeczytaj poniżej ( ale naprawdę potrzebuję wsparcia SSLv3 ... z powodów X, Y, Z! ), Dlaczego lepiej skupić się na całkowitym wyłączeniu SSLv3.

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

Cóż, tak, prawdopodobnie. Umieściłem to w osobnym poście na blogu, aby uzyskać dalsze przemyślenia i pracę. Możemy mieć jakąś magiczną iptableszasadę, której możesz użyć!

Mój post na blogu: Jak usunąć SSLv3 w swojej sieci przy użyciu iptables dla POODLE?

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

Obecny wektor ataku, jak pokazują badacze, działa z kontrolowaniem zwykłego tekstu wysyłanego na serwer za pomocą Javascript uruchomionego na maszynie ofiary. Ten wektor nie dotyczy scenariuszy innych niż HTTPS bez użycia przeglądarki.

Ponadto normalnie klient SSL nie pozwala na obniżenie poziomu sesji do SSLv3 (mając TLSv1 + w możliwościach uzgadniania), ale przeglądarki chcą być bardzo kompatybilne wstecz i robią to. Połączenie ze sterowaniem tekstem jawnym i szczególnym sposobem budowania nagłówka 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ć mój certyfikat serwera? (Jak w Heartbleed)

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

Osoba atakująca najprawdopodobniej jest w stanie jedynie ukraść nagłówki tekstu jawnego, takie jak sesyjne pliki cookie, w celu przejęcia sesji . Dodatkowym ograniczeniem jest potrzeba pełnego (aktywnego) ataku MitM .

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

Jako użytkownik, oprócz wyłączenia SSLv3 w przeglądarce, nie bardzo. Po prostu zawsze instaluj najnowsze aktualizacje zabezpieczeń.

W przypadku serwerów postępuj zgodnie z przewodnikiem serwera TLS Mozilli . I przetestuj testem Qualys SSL Labs . Naprawdę nie jest trudno uzyskać ocenę A + na swojej stronie. Po prostu zaktualizuj swoje pakiety i zastosuj zalecenia z przewodnika Mozilli.

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

Cóż, istnieje łatka, która omija atak na obniżenie wersji klientów obsługujących TLSv1, zwany Zabezpieczeniem przed awarią SSLv3. Nawiasem mówiąc, poprawi to także bezpieczeństwo TLSv1 + (atak na obniżenie wersji jest trudniejszy / niemożliwy). Jest oferowany jako backport od nowszej wersji OpenSSL w poradniku bezpieczeństwa Ubuntu usn-2385-1 .

Big catch: Zarówno klienci, jak i serwery potrzebują tej poprawki, aby działać. Tak więc, moim zdaniem, podczas aktualizacji zarówno klientów, jak i serwerów, powinieneś po prostu uaktualnić do TLSv1 +.

Proszę jednak na razie wycofać SSLv3 w swojej sieci. Postaraj się zaktualizować standardy bezpieczeństwa i po prostu porzuć SSLv3.

Słyszałem o wsparciu SCSV w celu wyeliminowania ataku 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, polecam go zainstalować. Ubuntu zapewnia aktualizację tej funkcji w usn-2385-1 . Otrzymasz go poprzez regularne aktualizacje zabezpieczeń w menedżerze pakietów.

Testowanie podatności na prywatne witryny (np. Intranet / offline).

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

• Z OpenSSL s_client:

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

  Jeśli połączenie się powiedzie, sslv3 jest włączony. Jeśli się nie powiedzie, zostaje wyłączony. Kiedy się nie powiedzie, 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 generować „ SSLv3: No supported ciphers found”. Dostosuj swoją nazwę hosta / port.

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

  ./cipherscan myhostname.tld
  

  Należy nie notować coś z SSLv3 w kolumnie „protokołów”.

Przeglądarka Firefox

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

Firefox począwszy od wersji 34 domyślnie wyłączy SSLv3, a zatem nie będzie wymagał żadnych działań ( źródła ). Jednak w chwili pisania tego tekstu 33 zostało właśnie wydane, a 34 na 25 listopada.

Google Chrome (Linux)

Edytuj /usr/share/applications/google-chrome.desktopplik, np

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

Edytuj wszystkie linie, zaczynając od, Exec=aby uwzględnić --ssl-version-min=tls1.

Np. Linia jak

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

staje się

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

Następnie pamiętaj, aby całkowicie zamknąć przeglądarkę (aplikacje Chrome mogą utrzymywać przeglądarkę w tle!).

Uwaga: może być konieczne powtarzanie tej każdej aktualizacji pakietu google-chrome, zastępując ten .desktopplik uruchamiania. Przeglądarka Google Chrome lub Chromium z domyślnie wyłączonym SSLv3 nie jest jeszcze ogłoszona w momencie pisania.

Serwer Apache HTTPD

Jeśli korzystasz z serwera WWW Apache, który obecnie obsługuje SSLv3, musisz edytować konfigurację Apache. W systemach Debian i Ubuntu plik to /etc/apache2/mods-available/ssl.conf . W CentOS i Fedorze jest to plik /etc/httpd/conf.d/ssl.conf . Konieczne będzie dodanie następującego wiersza do konfiguracji Apache wraz z innymi dyrektywami SSL.

SSLProtocol All -SSLv2 -SSLv3

Umożliwi to stosowanie wszystkich protokołów oprócz SSLv2 i SSLv3.

W tym momencie możesz rozważyć poprawę konfiguracji serwera szyfrującego dla swojego serwera WWW, jak wyjaśniono w przewodniku serwera TLS Mozilli . 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ą za pomocą narzędzia Qualys SSL Labs .

Serwer Nginx

Jeśli korzystasz z Nginx, po prostu dołącz następujący wiersz do konfiguracji wśród innych dyrektyw SSL:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

W tym momencie możesz rozważyć poprawę konfiguracji serwera szyfrującego dla swojego serwera WWW, jak wyjaśniono w przewodniku serwera TLS Mozilli . 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

Odniesienie: dokumentacja Nginx

Teraz przetestuj: jeśli Twoja witryna jest publicznie dostępna, przetestuj ją za pomocą narzędzia Qualys SSL Labs .

Serwer WWW Lighttpd

Wersje Lighttpd> 1.4.28 obsługują opcję konfiguracji wyłączającą SSLv2 i v3. Wersje Lighttpd przed 1.4.28 pozwalają WYŁĄCZNIE WYŁĄCZYĆ SSLv2. Należy pamiętać, że Ubuntu 12.04 LTS i wcześniejsze instalują co najwyżej lighttpd v1.4.28 i dlatego dla tych dystrybucji nie jest dostępna prosta poprawka. Dlatego ta poprawka powinna być używana tylko dla wersji Ubuntu większych niż 12.04.

W przypadku Ubuntu w wersji 12.04 lub Debian 6 zaktualizowany pakiet lighttpd jest dostępny z repozytorium openSUSE: http://download.opensuse.org/repositories/server:/http/Debian_6.0

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

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

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

Następnie należy ponownie uruchomić usługę lighttpd za pomocą a sudo service lighttpd restarti 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 http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_SSL .

Postfiks SMTP

W przypadku „oportunistycznego protokołu SSL” (polityka szyfrowania nie jest egzekwowana, a akceptowalna jest również akceptowalna), nie trzeba niczego zmieniać. Nawet SSLv2 jest lepszy niż zwykły, więc jeśli chcesz zabezpieczyć serwer, i tak powinieneś używać trybu „obowiązkowego SSL”.

Aby tryb „obowiązkowego SSL” był już skonfigurowany, wystarczy dodać / zmienić ustawienie smtpd_tls_mandatory_protocols dla połączeń przychodzących 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 również wyłączyć SSLv3 dla szyfrowania oportunistycznego (chociaż nie jest to konieczne, jak wyjaśniono powyżej), zrób to w ten sposób:

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

i uruchom ponownie Postfix:

sudo service postfix restart

Wyślij maila

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

Te opcje są skonfigurowane w LOCAL_CONFIGsekcji twojegosendmail.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

Gołębnik

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

ssl_protocols = !SSLv2 !SSLv3

i ponownie uruchom Dovecot:

sudo service dovecot restart

W przypadku starszych wersji konieczne będzie załatanie kodu źródłowego .

Courier-imap (imapd-ssl)

Courier-imap domyślnie zezwala na SSLv3 w Ubuntu 12.04 i innych. Powinieneś go wyłączyć i zamiast tego użyć STARTTLS, aby wymusić TLS. Edytuj /etc/courier/imapd-sslplik konfiguracyjny, 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ługiwany w HAProxy> = 1,5.

Edytuj /etc/haproxy.cfgplik i znajdź swoją bindlinię. Dołącz no-sslv3. Na przykład:

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

Odniesienie: Dokumentacja HAProxy

OpenVPN

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

OpenVPN używa TLSv1.0 lub (z> = 2.3.3) opcjonalnie TLSv1.2 i dlatego POODLE nie ma na nie wpływu.

Marionetka

Puppet używa protokołu SSL przez HTTPS, ale nie jest używany przez klientów „przeglądarki”, tylko agentów Puppet, którzy nie są podatni na pokazany wektor ataku. Jednak najlepszym rozwiązaniem jest wyłączenie SSLv3.

Polecam użyć modułu Stephenrjohnson / puppetmodule Puppet, aby skonfigurować swojego mistrza Puppet, w którym jakiś czas temu zabiłem SSLv3 .

Może nie być specyficzny dla Ubuntu, ale w celu obejścia luki w zabezpieczeniach Poodle w Node.js możesz ustawić secureOptionsto require('constants').SSL_OP_NO_SSLv3podczas tworzenia serwera https lub tls.

Dodatkowe informacje można znaleźć na https://gist.github.com/3rd-Eden/715522f6950044da45d8

„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 wyższym. Skanowanie PCI na twoim serwerze może wrócić z zaleceniem:

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

Ponieważ luka w zabezpieczeniach POODLE jest wadą projektową w samym protokole, a nie błędem implementacyjnym, nie będzie łatek. Jedynym sposobem na złagodzenie tego jest wyłączenie SSLv3 na serwerze Apache. Dodaj poniższe wiersze do pliku ssl.conf i wykonaj wdzięczny 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"