Vraag Hoe patch / doorloop SSLv3 POODLE-kwetsbaarheid (CVE-2014-3566)?


Na de BEAST-aanval en Heartbleed bug, nu heb ik gehoord over een nieuwe kwetsbaarheid in SSL / TLS genaamd POEDEL. Hoe bescherm ik mezelf tegen misbruik?

  • Worden alleen servers of ook klanten getroffen?
  • Is dit OpenSSL / GnuTLS specifiek?
  • Wat voor soort services worden er beïnvloed? Alleen HTTPS of ook IMAPS, SMTPS, OpenVPN, etc.?

Laat me voorbeelden zien van hoe dit beveiligingslek kan worden voorkomen.


158
2017-10-14 23:49


oorsprong


Meer informatie is hier te vinden SSL3 "Poodle" -gevoeligheid - Braiam
@Braiam Ja ik weet het, de briljante Thomas weer! Dat is echter een zeer cryptografisch georiënteerde vraag en antwoord. Deze Q & A op AU moet praktische en Ubuntu-gerichte informatie bieden. :-) - gertvdijk
Huh? Hoe verwacht je een meer praktische oplossing dan: "Als je de pleisters niet installeert, zal Níðhöggr je milt verslinden." - Braiam
@Braiam Allereerst: er is geen patch (lees mijn antwoord). Ik denk dat Thomas verwijst naar apparaten in plaats van DIY-Ubuntu web server hosting. Toestellen zoals load balancers bieden meestal firmware-updates voor het wijzigen van standaardinstellingen of bieden functionaliteit om het te kunnen configureren. In Ubuntu is het echter aan de gebruiker / beheerder. - gertvdijk
Eigenlijk is er: leveranciers kunnen alle SSLv3-gerelateerde code deactiveren / verwijderen, dus u hoeft helemaal niets aan te raken. - Braiam


antwoorden:


Achtergrond informatie

SSL is ontworpen om het transportniveau op internet te beveiligen. Voor 'het web', ook bekend als HTTP, kent u dit als HTTPS, maar het wordt ook gebruikt voor andere applicatieprotocollen. SSLv2 was het eerste veel gebruikte protocol voor transportbeveiliging, maar werd niet lang daarna onveilig gevonden. Opvolgers SSLv3 en TLSv1 worden nu breed ondersteund. TLSv1.1 en TLSv1.2 zijn nieuwer en krijgen ook veel steun. De meeste, zo niet alle webbrowsers die vanaf 2014 zijn vrijgegeven, hebben er ondersteuning voor.

De recente ontdekking door Google-technici wijst erop dat SSLv3 niet langer zou mogen worden gebruikt (zoals SSLv2 lang geleden is verouderd). De clients die geen verbinding kunnen maken met uw site / service zijn waarschijnlijk heel erg beperkt. CloudFlare aangekondigd dat minder dan 0,09% van hun bezoekers nog steeds vertrouwen op SSLv3.

Eenvoudige oplossing: SSLv3 uitschakelen.

Verstrekt Ubuntu updates?

Ja, via usn-2385-1 met de toevoeging van de SCSV-functie, maar het lost het probleem niet volledig op omdat SSLv3 niet wordt uitgeschakeld en de patch alleen werkt als beide zijden van de verbinding zijn gepatcht. U ontvangt het via uw reguliere beveiligingsupdates in uw pakketbeheerder.

Zo stil U moet zelf actie ondernemen om SSLv3 uit te schakelen (het is configureerbaar). Toekomstige versies van clients / browsers zullen waarschijnlijk SSLv3 uitschakelen. Bijv. Firefox 34 doet dit.

Het volledig uitschakelen van SSLv3 volledig in Ubuntu op implementatieniveau zal waarschijnlijk ook een aantal dingen breken voor niet-HTTPS SSL-gebruik, dat niet zozeer kwetsbaar is, dus ik neem aan dat beheerders dit niet zullen doen en alleen deze SCSV-patch zal worden toegepast.

Waarom verhelpt de SCSV-update in OpenSSL via usn-2385-1 het probleem niet?

Echt, stop met het stellen van dergelijke vragen en sla een paar paragrafen over en schakel SSLv3 uit. Maar goed, als je niet overtuigd bent, hier ga je:

POODLE laat zien dat SSLv3 met CBC-coderingen verbroken is, maar het implementeren van SCSV verandert daar niets aan. SCSV zorgt er alleen voor dat u niet downgradet van een of ander TLS-protocol naar een lager TLS / SSL-protocol als dat nodig is met de Man-in-the-Middle-aanval die vereist is voor de gebruikelijke gevallen.

Als u toegang moet hebben tot een server die helemaal geen TLS aanbiedt, maar alleen SSLv3, dan heeft uw browser niet echt een keuze en moet hij met de server praten via SSLv3, die dan kwetsbaar is zonder een downgrade-aanval.

Als u toegang moet hebben tot een server die ook TLSv1 + en SSLv3 aanbiedt (wat wordt afgeraden) en u wilt er zeker van zijn dat uw verbinding niet naar SSLv3 wordt gedowngraded door een aanvaller, dan beide de server en de client hebben deze SCSV-patch nodig.

Om het probleem volledig te ondervangen, is de uitschakeling van SSLv3 uw doel genoeg en kunt u er zeker van zijn dat u niet wordt gedowngraded. En u kunt niet praten met SSLv3-only servers.

Oké, dus hoe schakel ik SSLv3 uit?

Zie hieronder in de toepassingsspecifieke secties: Firefox, Chrome, Apache, Nginx en Postfix zijn voorlopig gedekt.

Worden alleen servers of ook klanten getroffen?

Het beveiligingslek bestaat als zowel de server als de client SSLv3 accepteert (zelfs als beide in staat zijn tot TLSv1 / TLSv1.1 / TLS1.2 vanwege een downgrade-aanval).

Als serverbeheerder moet u SSLv3 uitschakelen nu voor de veiligheid van uw gebruikers.

Als gebruiker moet u SSLv3 uitschakelen in uw browser nu om jezelf te beveiligen bij het bezoeken van websites die SSLv3 nog steeds ondersteunen.

Is deze OpenSSL / GnuTLS / browser specifiek?

Nee. Het is een protocol (ontwerp) bug, geen implementatie bug. Dit betekent dat je het niet echt kunt patchen (tenzij je het ontwerp van de oude SSLv3 verandert).

En ja, er is een nieuwe OpenSSL beveiligingsupdate, maar lees hieronder (Maar ik heb echt SSLv3-ondersteuning nodig ... voor reden X, Y, Z!) over waarom je je beter kunt richten op het volledig uitschakelen van SSLv3.

Kan ik SSLv3 op het netwerk (firewall) -niveau doden?

Nou ja, waarschijnlijk. Ik heb dit in een aparte blogpost geplaatst voor verdere gedachten en werk. We hebben misschien wat magie iptables regel die je kunt gebruiken!

Mijn blogpost: Hoe verwijder je SSLv3 in je netwerk met iptables voor POODLE?

Is het alleen relevant voor HTTPS of ook voor IMAP / SMTP / OpenVPN en andere protocollen met SSL-ondersteuning?

De huidige aanvalsvector, zoals getoond door de onderzoekers, werkt met het beheersen van de leesbare tekst die naar de server wordt gestuurd, waarbij Javascript wordt uitgevoerd op de machine van het slachtoffer. Deze vector is niet van toepassing op niet-HTTPS-scenario's zonder een browser te gebruiken.

Normaal gesproken staat een SSL-client niet toe dat de sessie wordt gedowngraded naar SSLv3 (waarbij TLSv1 + wordt gezien in de handshake-mogelijkheden), maar browsers willen zeer achterwaarts compatibel zijn en dat doen ze. De combinatie met het beheren van leesbare tekst en de specifieke manier waarop een HTTP-header is opgebouwd, maakt het bruikbaar.

Conclusie: SSLv3 uitschakelen voor HTTPS nu, schakel SSLv3 uit voor andere services in uw volgende servicevenster.

Wat is de impact? Moet ik mijn servercertificaat intrekken en opnieuw genereren? (Zoals met Heartbleed)

Nee, u hoeft hiervoor uw certificaten niet te roteren. Het beveiligingslek maakt herstel van niet-gecodeerde tekst van de sessiegegevens zichtbaar en biedt geen toegang tot eventuele geheimen (de sessiesleutel of certificaatsleutel niet).

Een aanvaller is waarschijnlijk alleen in staat om de kopteksten in platte tekst zoals sessiecookies te stelen om te kunnen presteren sessie kaping. Een extra beperking is de behoefte aan een volledige (actieve) MitM-aanval.

Kan ik nog iets anders doen om mijn SSL-configuratie in het algemeen te verbeteren?

Als een gebruiker, naast het uitschakelen van SSLv3 in uw browser, niet echt. Installeer gewoon de nieuwste beveiligingsupdates.

Voor servers, volg Mozilla's TLS-servergids. En test met SSL-labstest van Qualys. Het is echt niet zo moeilijk om een ​​A + -beoordeling op uw site te krijgen. Werk uw pakketten bij en voer de aanbevelingen uit de handleiding van Mozilla uit.

Maar ik heb echt SSLv3-ondersteuning nodig ... voor reden X, Y, Z! Wat nu?

Welnu, er is een patch die de downgrade-aanval van TLSv1-capabele clients omzeilt, de SSLv3 Fallback Protection. Het verbetert trouwens de beveiliging van TLSv1 + (downgrade-aanval is moeilijker / onmogelijk). Het wordt aangeboden als een backport van een meer recente OpenSSL-versie in het Ubuntu Security-advies usn-2385-1.

Big catch: zowel clients als servers hebben deze patch nodig om te kunnen werken. Dus, naar mijn mening, terwijl je zowel clients als servers bijwerkt, zou je hoe dan ook gewoon moeten upgraden naar TLSv1 +.

Alsjeblieft, stop alstublieft SSLv3 in je netwerk voor nu. Doe inspanningen om de beveiligingsstandaarden te upgraden en SSLv3 gewoon te dumpen.

Ik hoorde over SCSV-ondersteuning om de protocol downgrade-aanval te elimineren. Heb ik het nodig?

Alleen als je SSLv3 om een ​​of andere vreemde reden echt nodig hebt, maar het verbetert ook de veiligheid in TLSv1 +, dus ja, ik raad je aan het te installeren. Ubuntu biedt een update voor deze functie in usn-2385-1. U ontvangt het via uw reguliere beveiligingsupdates in uw pakketbeheerder.

Het testen van de kwetsbaarheid voor privé gehoste sites (bijvoorbeeld intranet / offline).

Uw servers zijn kwetsbaar als ze SSLv3 ondersteunen. Verschillende opties hier:

  • Met OpenSSL s_client:

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

    Als de verbinding slaagt, is sslv3 ingeschakeld. Als het mislukt, is het uitgeschakeld. Als het mislukt, ziet u iets als:

    error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
    
  • Gebruik makend van nmap:

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

    Het zou moeten uitvoeren 'SSLv3: No supported ciphers found'. Aanpassen voor je hostnaam / poort.

  • Gebruik makend van cipherscan. Kloon / download het binaire bestand en voer het uit:

    ./cipherscan myhostname.tld
    

    Het zou moeten niet lijst alles met SSLv3 in de kolom 'protocollen'.


Firefox-browser

Open about:config, vind security.tls.version.min en stel de waarde in op 1. Start vervolgens uw browser opnieuw op om eventuele open SSL-verbindingen te verwijderen.

Firefox vanaf versie 34 zal SSLv3 standaard uitschakelen en vereist dus geen actie (bron). Op het moment van schrijven is 33 echter net vrijgegeven en 34 is vastgesteld op 25 november.


Google Chrome (Linux)

Bewerk de /usr/share/applications/google-chrome.desktop bestand, b.v.

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

Bewerk alle lijnen beginnend met Exec= opnemen --ssl-version-min=tls1.

Bijv. een lijn zoals

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

wordt

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

Zorg er vervolgens voor dat u de browser volledig sluit (Chrome-apps kunnen uw browser op de achtergrond actief houden!).

Opmerking: mogelijk moet u dit elke update van het Google Chrome-pakket herhalen en dit overschrijven .desktop Launcher-bestand. Een Google Chrome- of Chromium-browser met SSLv3 die standaard is uitgeschakeld, is nog niet aangekondigd op het moment van schrijven.


Apache HTTPD-server

Als u een Apache-webserver gebruikt die momenteel SSLv3 toestaat, moet u de Apache-configuratie bewerken. Op Debian en Ubuntu-systemen is het bestand /etc/apache2/mods-available/ssl.conf. Op CentOS en Fedora is het bestand /etc/httpd/conf.d/ssl.conf. U moet de volgende regel toevoegen aan uw Apache-configuratie met andere SSL-richtlijnen.

SSLProtocol All -SSLv2 -SSLv3

Hierdoor zijn alle protocollen behalve SSLv2 en SSLv3 mogelijk.

Terwijl je bezig bent, kun je overwegen om de ciphersuite-configuratie voor je webserver te verbeteren, zoals uitgelegd Mozilla's TLS-servergids. Voeg bijvoorbeeld toe:

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"

Controleer vervolgens of de nieuwe configuratie correct is (geen typfouten enz.):

sudo apache2ctl configtest

En herstart de server, bijvoorbeeld

sudo service apache2 restart

Op CentOS en Fedora:

systemctl restart httpd

Meer informatie: Apache-documentatie

Test het nu: als uw site openbaar beschikbaar is, test u deze met De SSL Labs-tool van Qualys.


Nginx-server

Als u Nginx gebruikt, neemt u de volgende regel in uw configuratie op naast de andere SSL-richtlijnen:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Terwijl je bezig bent, kun je overwegen om de ciphersuite-configuratie voor je webserver te verbeteren, zoals uitgelegd Mozilla's TLS-servergids. Voeg bijvoorbeeld toe:

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;

En herstart de server, bijvoorbeeld

sudo service nginx restart

Referentie: Nginx-documentatie

Test het nu: als uw site openbaar is, beschikbaar, test deze dan met De SSL Labs-tool van Qualys.


Lighttpd webserver

Lighttpd-versies> 1.4.28 ondersteunen een configuratieoptie om SSLv2 en v3 uit te schakelen. Lighttpd releases voor 1.4.28 staan ​​je toe om SSLv2 ALLEEN uit te schakelen. Let op: Ubuntu 12.04 LTS en eerder installeren op zijn best lighttpd v1.4.28 en daarom is een eenvoudige oplossing niet beschikbaar voor die distributies.  Daarom moet deze oplossing alleen worden gebruikt voor Ubuntu-versies die groter zijn dan 12.04.

Voor Ubuntu-versie 12.04 of Debian 6 is een bijgewerkt lighttpd-pakket beschikbaar vanuit de openSUSE-repository: http://download.opensuse.org/repositories/server:/http/Debian_6.0

Het pakket is bedoeld voor Debian 6 (squeeze) maar werkt ook op 12.04 (nauwkeurig)

Bewerk je /etc/lighttpd/lighttpd.conf om de volgende regels toe te voegen na de ssl.engine = "enable" richtlijn

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

Dan zou u de lighttpd-service opnieuw moeten starten met een sudo service lighttpd restart en voer een ssl3-handshake-test uit zoals beschreven in eerdere secties om te controleren of de wijziging met succes is geïmplementeerd.

Genomen van http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_SSL.


Postfix SMTP

Voor 'opportunistische SSL' (versleutelingsbeleid niet afgedwongen en duidelijk is ook acceptabel) hoeft u niets te veranderen. Zelfs SSLv2 is beter dan gewoon, dus als je je server moet beveiligen, zou je hoe dan ook de 'verplichte SSL'-modus moeten gebruiken.

Om de 'verplichte SSL'-modus al te configureren, voegt u gewoon de / toe smtpd_tls_mandatory_protocols instelling voor inkomende verbindingen en smtp_tls_mandatory_protocols voor uitgaande verbindingen:

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

Optioneel, als u SSLv3 ook wilt uitschakelen voor opportunistische codering (hoewel het onnodig is, zoals hierboven uitgelegd), doe dit dan als volgt:

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

en herstart Postfix:

sudo service postfix restart

Verzend mail

(Niet-geverifieerde bewerking door een anonieme gebruiker, ik ben niet comfortabel met Sendmail, controleer alstublieft.)

Deze opties zijn geconfigureerd in de LOCAL_CONFIG gedeelte van uw 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

duiventil

Voeg in Dovecot v2.1 + het volgende toe aan uw /etc/dovecot/local.conf (of een nieuw bestand in /etc/dovecot/conf.d):

ssl_protocols = !SSLv2 !SSLv3

en herstart Dovecot:

sudo service dovecot restart

Voor oudere versies zul je dit moeten doen patch de broncode.


Courier-imap (imapd-ssl)

Courier-imap staat SSLv3 standaard toe op Ubuntu 12.04 en anderen. U moet dit uitschakelen en STARTTLS gebruiken om TLS te forceren. Bewerk je /etc/courier/imapd-ssl configuratiebestand om de volgende wijzigingen weer te geven

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!>"

HAProxy Server

SSL wordt ondersteund in HAProxy> = 1.5.

Bewerk de /etc/haproxy.cfg bestand en vind uw bind lijn. toevoegen no-sslv3. Bijvoorbeeld:

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

Referentie: HAProxy-documentatie


OpenVPN

Verschijnt niet te worden beïnvloed (bron).

OpenVPN maakt gebruik van TLSv1.0, of (met> = 2.3.3) optioneel TLSv1.2 en wordt dus niet beïnvloed door POODLE.


Marionet

Puppet maakt gebruik van SSL via HTTPS, maar wordt niet gebruikt door 'browser'-clients, alleen Puppet-agents die niet kwetsbaar zijn voor de getoonde aanvalsvector. Het is echter het beste om SSLv3 gewoon uit te schakelen.

Mijn aanbeveling is om de stephenrjohnson / puppetmodule Puppet-module om je Puppet-meester in te stellen Ik heb SSLv3 gedood een tijdje geleden.


210
2017-10-14 23:49



Dit antwoord is heel snel gemaakt na de openbare vrijgave van het beveiligingslek. Er kunnen nog steeds fouten in zitten - zoals altijd, voel je vrij om te bewerken / verbeteren. - gertvdijk
Nginx config mag geen dubbele punt na ssl_protocols-richtlijn hebben - Michelle
Oké, voor Firefox geloof ik deze is wat er aan de hand is. - fuglede
Dit blogbericht over Mozilla Security stelt voor om te installeren deze add-on in plaats van de voorkeuren handmatig aan te passen. - legoscia
@muru Hier is een begin met het doden van SSLv3 op firewallniveau. blog.g3rt.nl/take-down-sslv3-using-iptables.html - gertvdijk


Mogelijk niet ubuntu-specifiek, maar om de kwetsbaarheid van de Poodle in Node.js te omzeilen, kunt u de secureOptions naar require('constants').SSL_OP_NO_SSLv3 wanneer u een https- of tls-server maakt.

Zien https://gist.github.com/3rd-Eden/715522f6950044da45d8 voor aanvullende informatie


4
2017-10-15 08:59



IMO je zou HTTP (S) niet moeten blootstellen aan Node / Python / Ruby of iets dergelijks direct. Zet er een fatsoenlijke HTTPd voor zoals Apache / Nginx / ... - gertvdijk
Ja, je moet niet direct worden blootgesteld. Talen zijn niet zo goed met TCP-laag HTTP, maar ze rocken bij het doen van sockets. Laat nginx het uit een socket lezen. :-) - jrg♦
Dit verdiende geen neerwaartse stemming. Er zijn veel gevallen waarin tls wordt gebruikt naast het hosten van een http-server. - psanford
@gertvdijk & jrg Node.js is geen taal. Het is een raamwerk voor het bouwen van schaalbare netwerktoepassingen. En als je zegt dat je Node.js achter een Apache-server moet plaatsen (en het zelfs "fatsoenlijk" noemt), wordt het al duidelijk dat je absoluut geen idee hebt waar je het over hebt. Beweren dat ze niet goed zijn met tpc / http is duidelijk een persoonlijke vooroordeel. Blijf alsjeblieft ongewapend over kinderachtige technologie om te down-stemmen die je niet begrijpt. - 3rdEden
@ 3rdEden Nou, misschien was mijn opmerking een beetje generaliserend, maar hier zijn een paar opmerkingen die ik zou willen maken. 1) Ik heb niet downdownt, 2) mijn opmerking was een zachte 'IMO', 3) Misschien is het gewoon mijn achtergrond in beveiliging, maar ik heb geleerd dat men een toepassingsraamwerk niet direct aan 80/443 aan de wereld mag blootstellen in productie. (tenzij voor demonstratiedoeleinden). 4) Ik zie niet in hoe uw bericht een 'antwoord' is op de vraag voor de algemene Ask Ubuntu-bezoeker; het is gewoon heel specifiek voor een bepaald geval van Node.js-implementaties. - gertvdijk


De "fix" voor koerier schakelt tls 1.1 en tls 1.2 uit. Er lijkt geen manier om koerier te runnen met tls 1.1 of hoger. Een PCI-scan op uw server komt mogelijk terug met de aanbeveling:

Configureer SSL / TLS-servers om alleen TLS 1.1 of TLS 1.2 te gebruiken als dit wordt ondersteund. Configureer SSL / TLS-servers om alleen versleutelingspakketten te ondersteunen die geen blokcodes gebruiken.


0
2018-02-27 14:45





Omdat POODLE Kwetsbaarheid een ontwerpfout in het protocol zelf is en geen implementatiefout, zullen er geen patches zijn. De enige manier om dit te beperken, is door SSLv3 in de apache-server uit te schakelen. Voeg de onderstaande regels toe aan ssl.conf en voer een sierlijke apache-herstart uit.

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"

-1
2017-10-15 22:55



-1 voor het opnemen van RC4 en niet-functionele ECDSA omdat de meeste mensen RSA-certificaten hebben. Lees alsjeblieft hoe je je server op de juiste manier configureert. wiki.mozilla.org/Security/Server_Side_TLS - gertvdijk
@gertvdijk Ik ben het met je eens over RC4, maar het doet geen pijn om ECDSA-suites op te nemen. Het is onschadelijk als u alleen een RSA-certificaat hebt en u de moeite van het repareren van uw configuratie bespaart als u later een ECDSA-certificaat krijgt. - Matt Nordhoff
@MattNordhoff Eerlijk genoeg, maar wat ik bedoel is dat er niet veel cijfers over zijn voor een reguliere RSA-certificaatgebaseerde configuratie. Het werkt in de meeste browsers, maar er kunnen compatibiliteitsproblemen optreden. - gertvdijk
Verwijder zeker RC4 uit deze lijst, dat is niet veilig. Blijf bij de overblijvers als je kunt. 3DES is zwak, maar ik heb dat op een bepaalde plaats ingeschakeld voor compatibiliteit. Ik haat het om het te doen omdat het zwak is, maar het is tenminste niet echt gebroken ... - Brian Knoblauch