it-swarm-eu.dev

Jaké šifry bych měl použít na svém webovém serveru po konfiguraci certifikátu SSL?

Existuje mnoho skvělé otázky , které se ptají, jaký certifikát je nejlepší použít pro web; ale jakmile je certifikát zakoupen, je zde také možnost vybrat nebo upravit seznam Šifra.

Přestože každý prodejce může toto nastavení nazvat něco trochu jiného, ​​chápu, že seznam šifrování se používá k vyjednávání šifrovacích protokolů mezi klientem a serverem.

  1. Jaké jsou základy výběru seznamu Cipher pro můj web? Pokud je třeba změnit výchozí nastavení Kam by měli „začátečníci“ získat spolehlivou radu?

  2. Změnilo se některé z tradičních doporučení od září 2011 BEAST nebo 2012 CRIME útoku?

  3. Udržuje někdo seznam šifrů podporovaných OS/Prodejcem/a verzí? Je správné říci, že by něco takového bylo užitečné?

  4. Jsou některé certifikáty nekompatibilní s některými šifry?

  5. Kde se mohu dozvědět více? Jak konkrétně mohu získat zběžnou schopnost porovnávat šifry, aniž bych musel opakovat některé post-sekundární matematické třídy?

30

V SSL/TLS vybere sada šifry sadu algoritmů pro několik úkolů: dohoda klíče, symetrické šifrování, kontrola integrity.

Typ certifikátu má vliv na výběr klíčové dohody. Je třeba vzít v úvahu dva parametry: použití klíče a použití klíče :

  • Pomocí klíče RSA můžete nominálně použít sadu šifry „RSA“ a „DHE_RSA“. Má-li však serverový certifikát rozšíření pro použití klíčů, které nezahrnuje příznak "keyEncipherment", pak jste nominálně omezeni na "DHE_RSA".
  • S klíčem DSA můžete použít pouze sadu šablon „DHE_DSS“.
  • S klíčem Diffie-Hellman můžete použít pouze jeden z „DH_RSA“ nebo „DH_DSS“ v závislosti na typu klíče vydávající certifikační autority.

Většina certifikátů serveru SSL má klíč RSA, který není omezen rozšířením použití klíče, takže můžete použít typy klíčů „RSA“ i „DHE_RSA“.

„DHE“ znamená „Diffie-Hellman Ephemeral“. To umožňuje Perfect Forward Secrecy . PFS znamená, že pokud útočník ukradne soukromý klíč serveru (ten, který je uložen v souboru, tedy věrohodně zranitelný vůči pozdějšímu krádeži), nebude stále schopen dešifrovat minulé zaznamenané transakce. Toto je žádoucí vlastnost, zejména pokud chcete, aby váš systém během auditu vypadal dobře.

Pro kontrolu integrity byste neměli používat MD5 a pokud je to možné, vyhýbat se také SHA-1. Žádná ze současných známých slabých stránek MD5 a SHA-1 neovlivňuje zabezpečení TLS (s výjimkou případu, kdy je použita v certifikátu, ale to si vybere CA, ne vy). Nicméně používání MD5 (nebo v menší míře SHA-1) je pro public relations špatné. MD5 je „nefunkční“. Pokud používáte MD5, možná se budete muset ospravedlnit. Nikdo by nezpochybnil výběr SHA-256. Obecná shoda spočívá v tom, že SHA-1 je „tolerovatelný“ ze starších důvodů.

Pro symetrické šifrování máte na výběr mezi (většinou) RC4, 3DES a AES (pro druhé je 256bitová verze nadměrná; AES- 128 je již v pořádku). Lze uvést následující body:

  • RC4 a 3DES budou podporovány všude. Nejstarší klienti nemusí podporovat AES (např. Internet Explorer 6.0 se nezdá být schopen vyjednat AES šifrovací sady).

  • V RC4 jsou známy slabiny. Žádný není hned fatální. Situace je poněkud podobná situaci jako SHA-1: akademicky „zlomená“, ale právě teď to není problém. To je stále dobrý důvod k nepoužívání RC4, pokud se tomu lze vyhnout.

  • 3DES je 64bitová bloková šifra. To znamená určité (akademické) slabosti, když zašifrujete více než několik gigabajtů v jedné relaci.

  • 3DES může být na vašem procesoru těžký. Na 2,7 GHz Intel i7 dosahuje OpenSSL rychlost šifrování 180 MB/s pomocí AES-128 (mohlo by to být mnohem lepší, kdyby použil instrukce AES-NI ), ale pouze 25 MB/s s 3DES. 25 MB/s je stále dobré (to je 2,5x to, co zvládne spojení 100 Mbits/s, a používá jedno jádro), ale nemusí být zanedbatelné, v závislosti na vaší situaci.

  • Útok BEAST je stará akademická slabost, která byla nedávno prokázána jako použitelná v praxi. Vyžaduje, aby útočník vyzvedl na odkazu a spustil nepřátelský kód na klientovi (a tento kód musí komunikovat s externím systémem špionáže); autorům BEAST se to podařilo spustit, když nepřátelský interní kód používá Java nebo Javascript.) Obecným řešením je přepnutí na TLS 1.1 nebo 1.2, které jsou imunní. Týká se to pouze blokových šifrů v režimu CBC; RC4 je imunní.

  • V handshake SSL/TLS klient oznámí své podporované šifrovací sady (preferované sady přicházejí jako první), poté server vybere sadu, která bude použita. Je tradiční , že server ctí preference klienta - tj. Vybere první sadu v seznamu odeslaném klientem, se kterým server dokáže pracovat. Server však mohl prosadit vlastní pořadí preferencí.

  • DHE znamená poněkud vyšší spotřebu procesoru na serveru (ale nebude to znatelný rozdíl, pokud nezavedete několik stovek nových SSL relací za sekundu).

  • Neexistuje žádná sada šifrování DHE, která používá RC4.

Shrnutí: mě to vede k následujícímu upřednostňovanému seznamu sad šifry. Pokud se na vás může vztahovat útok BEAST (tj. Klient je webový prohlížeč), použijte toto:

  • Pokud relace používá SSL-3.0 nebo TLS-1.0, zkuste použít TLS_RSA_WITH_RC4_128_SHA.
  • Pokud klient podporuje TLS 1.1+ nebo nepodporuje TLS_RSA_WITH_RC4_128_SHA, nebo pokud považujete PFS za důležitější než aktivní útoky typu BEAST (např. nejvíc se obáváte dlouhodobé důvěrnosti, nikoli okamžitého porušení), použijte TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (návrat k TLS_DHE_RSA_WITH_AES_128_CBC_SHA pokud klient nepodporuje SHA-256).
  • Pokud klient šifrovací sady DHE nepodporuje, použijte odpovídající sadu jiných než DHE.
  • Obecná záložní reklama je TLS_RSA_WITH_3DES_EDE_CBC_SHA které by mělo fungovat všude.

Všimněte si, že výše uvedené možnosti předpokládají, že výběr sady můžete změnit v závislosti na sjednané verzi protokolu, což může nebo nemusí být dostupná možnost pro váš konkrétní server SSL.

Pokud se na vás BEAST nevztahuje (klient nespustí nepřátelský kód), zrušte podporu RC4; soustředit se na AES-128 a SHA-256; havárie na 3DES a SHA-1; použijte DHE, pokud je k dispozici.

29
Thomas Pornin

Líbí se mi sada šifry, kterou navrhla Mozilla (v lednu 2014):

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:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:AES128:AES256:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK

zdroj: https://wiki.mozilla.org/Security/Server_Side_TLS

snaží se vyvážit výkon a bezpečnost. Nicméně podle doporučení mého Microsoft , zůstal bych daleko od RC4

2
VP.

Kde jsou opravy a jak by mohly vypadat? Oprava by spočívala pouze v tom, že všechny prohlížeče na všech příslušných plattformách budou implementovány TLS 1.1 nebo 1.2. Nevěřím však tomu, že se to stane pro starší plattformy.

Takže zatím jsem RC4 viděl jen jako obcházení, protože většina vývojářů SW minul v minulosti implementaci nejnovějších standardů TLS a nyní jsme zasaženi takovou situací.

2
Jui

Aktualizace 2016 prostřednictvím SSL Labs:

Měli byste se spoléhat hlavně na sady AEAD, které poskytují silnou autentizaci a výměnu klíčů, dopředné tajemství a šifrování nejméně 128 bitů. Některá slabší apartmá mohou být stále podporována, pokud jsou vyjednávána pouze se staršími klienty, kteří nic lepšího nepodporují.

Je třeba se vyvarovat několika zastaralých kryptografických primitiv:

Anonymní sady Diffie-Hellman (ADH) neposkytují ověřování.

  • NULL šifrovací sady neposkytují žádné šifrování.
  • Export šifrovacích sad je při vyjednávání v připojení nezabezpečený, ale lze je také použít proti serveru, který preferuje silnější sady (útok FREAK).
  • Sady se slabými šifry (obvykle 40 a 56 bitů) používají šifrování, které lze snadno rozbít.
  • RC4 je nejistá.
  • 3DES je pomalý a slabý.

Jako výchozí bod použijte následující konfiguraci sady navrženou pro klíče RSA a ECDSA:

ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-SHA
ECDHE-ECDSA-AES256-SHA
ECDHE-ECDSA-AES128-SHA256
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA384
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES128-SHA
DHE-RSA-AES256-SHA
DHE-RSA-AES128-SHA256
DHE-RSA-AES256-SHA256
EDH-RSA-DES-CBC3-SHA

Poznámka: Tato příkladná konfigurace používá nestandardní názvy sad vyžadovaných OpenSSL. Pro nasazení v jiných prostředích (např. IIS) budete muset použít standardní názvy TLS suite.

Reference: https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices#23-use-secure-cipher-suites

1
bhushan5640

Podívejme se nejprve na šifry, které neberou ohled na útok BEAST.

Doporučil bych používat pouze „současné“ šifry se silnými klíči a nepodporovat historické šifry, které nikdo stejně nepoužívá. Například žádné RC4. Také bych doporučil proti exportním šifrám, které mají velmi slabé klíče, aby je americká vláda mohla rozbít. Přestože věřím, že export kryptografu vyššího stupně již není nelegální, tento koncept stále existuje v konfiguraci serveru. Nakonec se vyhněte algoritmům hashování, které mají velké problémy, například MD5.

Nyní útok BEAST .. AES v režimu CBC, jak je používán v TLS 1.0, je zranitelný vůči vybranému útoku obnovy prostého textu. mail.google.com se proti tomu bránil tím, že tento týden rychle přepnul na 128 bitů RC4. Pokud vás tento útok v následujících 2 týdnech velmi znepokojuje (jako by byl google), můžete použít stejné řešení. V ostatních případech bych prostě počkal na opravu a nakonfiguroval vaše šifry, aniž by se tento útok týkal.

0
chris

Můžete najít zajímavou konfiguraci pro Apache2 a silný výběr algoritmu SSL zde:

Generátor konfigurace Mozilly SSL https://mozilla.github.io/server-side-tls/ssl-config-generator/

Doporučení 2019.02 pro moderní prohlížeče je:

SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384: ECDHE-RSA-AES256-GCM-SHA384: ECDHE-ECDSA-CHACHA20-POLY1305: ECDHE-EC-ECDHE-ECE -AES128-GCM-SHA256: ECDHE-ECDSA-AES256-SHA384: ECDHE-RSA-AES256-SHA384: ECDHE-ECDSA-AES128-SHA256: ECDHE-RSA-AES128-SHA256

čitelný:

ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES256-SHA384
ECDHE-ECDSA-AES128-SHA256
ECDHE-RSA-AES128-SHA256
0
amprantino