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

157

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.

gertvdijk
źródło
2
Więcej informacji można znaleźć tutaj Luka w zabezpieczeniach
protokołu
1
@Braiam Tak, wiem, znowu genialny Thomas! Jest to jednak bardzo zorientowane na kryptografię pytania i odpowiedzi. Te pytania i odpowiedzi dotyczące AU mają dostarczyć praktycznych i zorientowanych na Ubuntu informacji. :-)
gertvdijk
10
Co? Jak możesz oczekiwać bardziej praktycznego rozwiązania niż „Jeśli nie zainstalujesz łat, Níðhöggr pożre twoją śledzionę”.
Braiam
2
@Braiam Po pierwsze: nie ma łatki (przeczytaj moją odpowiedź). Myślę, że Thomas ma na myśli raczej urządzenia, a nie hosting serwera DIY-Ubuntu. Urządzenia takie jak usługi równoważenia obciążenia zwykle oferują aktualizacje oprogramowania układowego w celu zmiany ustawień domyślnych lub oferują funkcje umożliwiające konfigurację. Jednak w Ubuntu wszystko zależy od użytkownika / administratora.
gertvdijk
W rzeczywistości istnieje: dostawcy mogą wyłączyć / usunąć cały kod związany z SSLv3, dlatego nie trzeba w ogóle niczego dotykać.
Braiam

Odpowiedzi:

209

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 .

gertvdijk
źródło
7
Ta odpowiedź została utworzona bardzo szybko po publicznym wydaniu luki w zabezpieczeniach. Mogą nadal występować błędy - jak zawsze, możesz je edytować / ulepszać.
gertvdijk
1
Konfiguracja Nginx nie powinna mieć dwukropka po dyrektywie ssl_protocols
Michelle
1
W porządku, dla Firefoksa wierzę, że tak się dzieje.
fuglede
4
Ten post na blogu Mozilla Security sugeruje instalację tego dodatku zamiast ręcznego dostosowywania preferencji.
legoscia
1
@muru Oto początek zabijania SSLv3 na poziomie zapory ogniowej. blog.g3rt.nl/take-down-sslv3-using-iptables.html
gertvdijk
4

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

3rdEden
źródło
1
IMO nie powinieneś wystawiać HTTP (S) za pomocą Node / Python / Ruby ani niczego podobnego bezpośrednio. Umieść przed nim porządny HTTPd, taki jak Apache / Nginx / ...
gertvdijk
Tak, nie powinieneś ujawniać bezpośrednio. Języki nie są zbyt dobre w przypadku warstwy HTTP tcp, ale lubią robić gniazda. Niech nginx przeczyta go z gniazda. :-)
jrg
4
To nie zasługiwało na głosowanie w dół. Istnieje wiele przypadków, w których tls jest używany oprócz hostingu serwera http.
psanford
@gertvdijk & jrg Node.js nie jest językiem. To środowisko do budowania skalowalnych aplikacji sieciowych. A gdy oświadczysz, że powinieneś umieścić Node.js za serwerem Apache (a nawet nazwać go „przyzwoitym”), już jasno wynika, że ​​nie masz absolutnego pojęcia o czym mówisz. Stwierdzenie, że nie są dobre z tpc / http, jest oczywiście osobistym uprzedzeniem. Proszę pozostać na temat zamiast dziecinnej technologii głosowania, której nie rozumiesz.
3rdEden
@ 3rdEden Cóż, być może moja uwaga była nieco uogólniona, ale oto kilka uwag, które chciałbym zrobić. 1) Nie głosowałem, 2) mój komentarz był delikatnym „IMO”, 3) Być może to tylko moje zaplecze w zakresie bezpieczeństwa, ale nauczyłem się, że nie należy narażać środowiska aplikacji bezpośrednio na 80/443 dla świata w produkcja. (chyba że w celach demonstracyjnych). 4) Nie rozumiem, w jaki sposób twój post jest „odpowiedzią” na pytanie dla ogólnego użytkownika Ask Ubuntu; jest to bardzo bardzo specyficzne dla konkretnego przypadku wdrożeń Node.js.
gertvdijk
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 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.

PrgWiz
źródło
-1

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"
Lal Krishna
źródło
1
-1 za włączenie RC4 i niefunkcjonalnego ECDSA, ponieważ większość ludzi posiada certyfikaty RSA. Przeczytaj, jak poprawnie skonfigurować serwer. wiki.mozilla.org/Security/Server_Side_TLS
gertvdijk
2
@gertvdijk Zgadzam się z tobą w sprawie RC4, ale dołączenie pakietów ECDSA nie zaszkodzi. Jest to nieszkodliwe, jeśli masz tylko certyfikat RSA i oszczędza kłopotów z naprawieniem konfiguracji, jeśli później otrzymasz certyfikat ECDSA.
Matt Nordhoff,
@MattNordhoff W porządku, ale mam na myśli to, że niewiele szyfrów pozostało do normalnej konfiguracji opartej na certyfikacie RSA. Będzie działać w większości przeglądarek, ale mogą wystąpić problemy ze zgodnością.
gertvdijk
Zdecydowanie pozbądź się RC4 z tej listy, to nie jest bezpieczne. Pozostań przy pozostałych, jeśli możesz. 3DES jest słaby, ale włączyłem to w jednym konkretnym miejscu dla kompatybilności. Nienawidzę tego robić, ponieważ jest słaby, ale przynajmniej tak naprawdę nie jest zepsuty ...
Brian Knoblauch