it-swarm-tr.com

SSL sertifikamı yapılandırdıktan sonra web sunucumda hangi şifreleri kullanmalıyım?

Bir web sitesi için kullanılacak en iyi sertifikanın ne olduğunu soran birçok harika sorular vardır; ancak sertifika satın alındıktan sonra, Şifre listesini seçme veya düzenleme olanağı da vardır.

Her satıcı bu ayarı biraz farklı bir şey olarak adlandırabilse de, benim anlayışım, Şifre Listesi'nin istemci ve sunucu arasındaki şifreleme protokollerini görüşmek için kullanılmasıdır.

  1. Web sitem için bir Şifre listesi seçmenin temelleri nelerdir? Varsayılanların değiştirilmesi gerekiyorsa "Yeni başlayanlar" güvenilir tavsiye almak için nereye gitmelidir?

  2. Eylül 2011'in BEAST veya 2012'nin CRIME saldırısı itibariyle geleneksel önerilerden herhangi biri değişti mi?

  3. OS/Satıcı/ve sürüm tarafından desteklenen şifrelerin bir listesi var mı? Böyle bir şeyin yararlı olacağını söylemek doğru mu?

  4. Bazı sertifikalar belirli şifrelerle uyumsuz veya tercih edilmiyor mu?

  5. Nereden daha fazla bilgi edinebilirim? Özellikle, bazı ortaöğretim sonrası matematik derslerini almak zorunda kalmadan Şifreleri karşılaştırma becerisine nasıl sahip olabilirim?

30

SSL/TLS içinde, şifre paketi çeşitli görevler için bir dizi algoritma seçer: anahtar anlaşması, simetrik şifreleme, bütünlük kontrolü.

sertifika türü anahtar anlaşmanın seçimini etkiler. İki parametre dikkate alınmalıdır: anahtar türü ve anahtar kullanımı:

  • Bir RSA anahtarıyla "RSA" ve "DHE_RSA" şifreleme paketini kullanabilirsiniz. Ancak sunucu sertifikasında değil "keyEncipherment" bayrağı bulunan bir Anahtar Kullanımı uzantısı varsa, nominal olarak "DHE_RSA" ile sınırlandırılırsınız.
  • DSA anahtarıyla yalnızca bir "DHE_DSS" şifreleme paketi kullanabilirsiniz.
  • Diffie-Hellman anahtarıyla, sertifika yetkilisi anahtarı türüne bağlı olarak "DH_RSA" veya "DH_DSS" öğelerinden yalnızca birini kullanabilirsiniz.

SSL sunucusu sertifikalarının çoğunda, Anahtar Kullanımı uzantısıyla kısıtlanmayan bir RSA anahtarı vardır, bu nedenle hem "RSA" hem de "DHE_RSA" anahtar türlerini kullanabilirsiniz.

"DHE", "Diffie-Hellman Geçici" anlamına gelir. Bu Mükemmel İletme Gizliliği sağlar. PFS, bir saldırgan sunucu özel anahtarını (bir dosyada saklanan anahtar, dolayısıyla hırsızlığa karşı makul bir şekilde savunmasız) çalarsa, geçmişte kaydedilen işlemlerin şifresini hala çözemeyeceği anlamına gelir. Bu, özellikle sisteminizin bir denetim sırasında iyi görünmesini istediğinizde istenen bir özelliktir.

bütünlük denetimi için MD5 kullanmamalısınız ve mümkünse SHA-1'den de kaçınmalısınız. Şu anda bilinen MD5 ve SHA-1 zayıflıklarının hiçbiri TLS'nin güvenliğini etkilemez (muhtemelen bir sertifika içinde kullanılması dışında, ancak bu CA tarafından değil, CA tarafından seçilir). Bununla birlikte, MD5 (veya daha az bir ölçüde SHA-1) kullanmak halkla ilişkiler için kötüdür. MD5 "bozuk". MD5 kullanıyorsanız, kendinizi haklı çıkarmanız gerekebilir. Kimse SHA-256'nın seçimini sorgulamaz. Genel fikir birliği, SHA-1'in eski nedenlerden ötürü "tolere edilebilir" olmasıdır.

simetrik şifreleme için, (çoğunlukla) RC4, 3DES ve AES arasında seçim yapabilirsiniz (ikincisi için 256 bit sürüm aşırıdır; AES- 128 zaten iyidir). Aşağıdaki noktalar yapılabilir:

  • RC4 ve 3DES her yerde desteklenecek. En eski istemciler AES'yi desteklemeyebilir (örn. Internet Explorer 6.0, AES tabanlı şifre paketleriyle pazarlık yapamıyor gibi görünüyor).

  • RC4'te bilinen zayıflıklar vardır. Hiçbiri ölümcül değildir. Durum SHA-1'inkine biraz benziyor: akademik olarak "kırık", ama şu anda bir sorun değil. Bu, kaçınılabiliyorsa RC4'ü kullanmamak için iyi bir nedendir.

  • 3DES 64 bitlik bir blok şifredir. Bu, tek bir oturumda birkaç gigabayttan fazlasını şifrelediğinizde bazı (akademik) zayıflıkları ifade eder.

  • 3DES CPU'nuzda ağır olabilir. 2,7 GHz Intel i7'de, OpenSSL , AES-128 ile 180 MB/s şifreleme hızına ulaşır ( AES-NI talimatları ) kullanırsa daha iyi olabilir 3DES ile 25 MB/s. 25 MB/s hala iyi (100 Mbits/s bağlantısının işleyebileceği 2.5 kat ve tek bir çekirdek kullanıyor), ancak durumunuza bağlı olarak ihmal edilemeyebilir.

  • BEAST saldırısı, yakın zamanda pratikte uygulanabilir olduğu kanıtlanmış eski bir akademik zayıflıktır. Saldırganın ve bağlantısında casusluk yapmasını gerektirir (ve bu kod dış casusluk sistemiyle iletişim kurmalıdır); BEAST yazarları, düşmanca dahili kod Java veya Javascript kullandığında) çalıştırmayı başardılar. Genel çözüm, bağışık olan TLS 1.1 veya 1.2'ye geçmektir. CBC modunda; RC4 bağışıktır.

  • Bir SSL/TLS anlaşmasında müşteri, desteklenen şifre paketlerini (tercih edilen paketler önce gelir) duyurur, ardından sunucu kullanılacak paketi seçer. Sunucunun istemci tercihlerini onurlandırması geleneksel - yani, istemcinin gönderebileceği istemci tarafından gönderilen listedeki ilk paketi seçer. Ancak bir sunucu kendi tercih sırasını uygulayabilir.

  • DHE, sunucuda biraz daha yüksek CPU tüketimi anlamına gelir (ancak saniyede yüzlerce yeni SSL oturumu oluşturmadığınız sürece fark edilir bir fark yaratmaz).

  • RC4 kullanan hiçbir DHE şifreleme paketi yoktur.

Özet: bu beni aşağıdaki tercih edilen şifre paketleri listesine götürüyor. BEAST saldırısı sizin için geçerliyse (yani istemci bir Web tarayıcısıysa), şunu kullanın:

  • Oturum SSL-3.0 veya TLS-1.0 kullanıyorsa, TLS_RSA_WITH_RC4_128_SHA 'U kullanmayı deneyin.
  • İstemci TLS 1.1+'yi destekliyorsa veya TLS_RSA_WITH_RC4_128_SHA 'U desteklemiyorsa veya PFS'nin sizin için BEAST benzeri aktif saldırılardan daha önemli olduğunu düşünüyorsanız (örneğin, uzun vadeli gizlilik konusunda endişelisiniz, hemen ihlal etmez), ardından TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 kullanın (istemci SHA-256'yı desteklemiyorsa TLS_DHE_RSA_WITH_AES_128_CBC_SHA 'e geri dönüş).
  • DHE şifreleme paketleri istemci tarafından desteklenmiyorsa, karşılık gelen DHE olmayan paketi kullanın.
  • Genel geri dönüş, her yerde çalışması gereken TLS_RSA_WITH_3DES_EDE_CBC_SHA.

Yukarıdaki seçeneklerin, anlaşılan protokol sürümüne bağlı olarak, belirli SSL sunucunuz için kullanılabilir bir seçenek olabilecek veya olmayabilecek olan paket seçimini değiştirebileceğinizi varsaydığını unutmayın.

BEAST sizin için geçerli değilse (istemci düşmanca kod çalıştırmaz), RC4 desteğini tamamen bırakın; AES-128 ve SHA-256 üzerinde konsantre edin; sırasıyla 3DES ve SHA-1'de düşüş; varsa DHE kullanın.

29
Thomas Pornin

Mozilla tarafından önerilen şifre paketini seviyorum (Ocak 2014'te):

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

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

performans ve güvenliği dengelemeye çalışır. Ancak, benim Microsoft tavsiye edildiği gibi , RC4 uzak kalmak istiyorum

2
VP.

Düzeltmeler nerede ve neye benzeyebilirler? Yalnızca düzeltme, ilgili tüm platformlardaki tüm Tarayıcıların TLS 1.1 veya 1.2'yi almasıdır. Ancak, bunun gibi eski platformlar için olacağına inanmıyorum.

Şimdilik, çoğu SW geliştiricisinin geçmişte en son TLS standartlarını uygulamayı kaçırdığı için RC4'ü sadece bir çözüm olarak gördüm ve şimdi olduğu gibi yakalandık.

2
Jui

2016'yı SSL Labs ile güncelleyin:

Güçlü kimlik doğrulama ve anahtar değişimi, ileri gizlilik ve en az 128 bit şifreleme sağlayan AEAD paketlerine güvenmelisiniz. Yalnızca daha iyi hiçbir şeyi desteklemeyen eski müşterilerle müzakere edilmeleri koşuluyla, bazı diğer zayıf paketler hala desteklenebilir.

Kaçınılması gereken birkaç eski kriptografik ilkel var:

Anonim Diffie-Hellman (ADH) süitleri kimlik doğrulaması sağlamaz.

  • NULL şifre takımları şifreleme sağlamaz.
  • Dışa aktarma şifreleme paketleri, bir bağlantıda görüşülürken güvenli değildir, ancak daha güçlü paketleri (FREAK saldırısı) tercih eden bir sunucuya karşı da kullanılabilirler.
  • Zayıf şifreleri olan paketler (genellikle 40 ve 56 bit) kolayca kırılabilen şifreleme kullanır.
  • RC4 güvensizdir.
  • 3DES yavaş ve zayıftır.

Başlangıç ​​noktanız olarak hem RSA hem de ECDSA anahtarları için tasarlanmış aşağıdaki paket yapılandırmasını kullanın:

ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128 SHS
ECDHE-ECDSA-AES256 SHS
ECDHE-ECDSA-AES128-SHA 256
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA AES128-GCM-SHA 256
ECDHE-RSA AES256-GCM-SHA384
ECDHE-RSA AES128 SHS
ECDHE-RSA AES256 SHS
ECDHE-RSA AES128-SHA 256
ECDHE-RSA AES256-SHA384
DHE-RSA AES128-GCM-SHA 256
DHE-RSA AES256-GCM-SHA384
DHE-RSA AES128 SHS
DHE-RSA AES256 SHS
DHE-RSA AES128-SHA 256
DHE-RSA AES256-SHA 256
Edh-RSA-DES-CBC3 SHS

Not Bu örnek yapılandırma, OpenSSL için gereken standart dışı paket adlarını kullanır. Diğer ortamlarda (ör. IIS) dağıtım için standart TLS paketi adlarını kullanmanız gerekir.

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

1
bhushan5640

Önce BEAST saldırısını göz ardı ederek şifreleri inceleyelim.

Sadece 'mevcut' şifreleri güçlü tuşlarla kullanmanızı ve kimsenin kullanmadığı tarihi şifreleri desteklememenizi tavsiye ederim. Yani örneğin RC4 yok. Ayrıca, ihracat düzeyindeki şifrelere karşı öneriyorum, bunların çok zayıf anahtarları var, böylece ABD hükümeti onları kırabilir. Yüksek dereceli kriptoyu dışa aktarmanın artık yasadışı olmadığına inanmama rağmen, konsept hala sunucu yapılandırmanızda var. Son olarak, MD5 gibi büyük sorunları olan karma algoritmalardan kaçının.

Şimdi BEAST saldırısı .. Görünüşe göre, TLS 1.0'da kullanılan CBC modundaki AES, seçilen bir düz metin kurtarma saldırısına karşı savunmasızdır. mail.google.com, bu hafta hızla 128 bit RC4'e geçerek buna karşı savunma yaptı. Önümüzdeki 2 hafta içinde (google gibi) bu saldırıdan çok endişe ediyorsanız, aynı çözümü uygulayabilirsiniz. Diğer durumlarda, sadece bir düzeltme bekler ve bu saldırıyla ilgili olmadan şifrelerinizi yapılandırırdım.

0
chris

Apache2 ve güçlü SSL algoritması seçimi için bazı ilginç yapılandırmalar burada bulabilirsiniz:

Mozilla SSL Yapılandırma Oluşturucu https://mozilla.github.io/server-side-tls/ssl-config-generator/

Modern tarayıcılar için 2019.02 önerisi:

SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384: ECDHE-RSA-AES256-GCM-SHA384: ECDHE-ECDSA-CHACHA20-POLY1305: ECDHE-RSA-CHACHA20-POLY1305: ECDHE-CHACHA20-ECHSA-A-DS8 -AES128-GCM-SHA 256: ECDHE-ECDSA-AES256-SHA384: ECDHE-RSA AES256-SHA384: ECDHE-ECDSA-AES128-SHA 256: ECDHE-RSA AES128-SHA 256

okunabilir:

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