Това ръководство показва как да се създаде висока степен на SSL сигурност на уеб сървъра Nginx. Ще направим това чрез актуализиране на OpenSSL до последната версия, за да се намали риска от такива атаки като heartbleed, компресия и износ SSL криптиране на разстояние за смекчаване на тези видове атаки, като изрод, престъпност и буксуване, забраните SSLv3 и по-ниско поради уязвимости в протокола, ще създаде Consumer Secret позволява мощно използване криптиране, когато е възможно. Ние също така ще включва и HSTS HPKP. По този начин, ние се мощен и професионален SSL конфигурация, и да получи най-висок рейтинг А + в Qually Labs SSL тест.
Ние ще се промени в /etc/nginx/sited-enabled/yoursite.com Nginx конфигурационен файл (на Ubuntu / Debian) или /etc/nginx/conf.d/nginx.conf (на RHEL / CentOS).
Вие трябва да редактирате частта между устройството на сървъра в конфигурацията на сървъра за порт 443 (SSL довереник) на. В края на ръководството ще намерите пример за напълно конфигуриран.
Уверете се, че сте създали архивни файлове, преди да редактирате!
Звяр атаки и RC4
С една дума, чрез счупване на кодиращия алгоритъм в ТГС - шифър блок верига - режими на криптиран част от трафика може да бъде разшифрован тайна.
Деактивирането на RC4 има няколко последици
- На първо място, потребителите с древни браузъри като Internet Explorer за Windows XP ще използват алтернативата - 3DES. Triple-DES е по-безопасно, отколкото RC4, но е значително по-скъпа операция. Вашият сървър ще бъде платена от процесорното време за тези потребители.
- На второ място, RC4 омекотява BEAST. По този начин, RC4 забраните на TLS 1.0 прави уязвими участници в тази атака, движейки ги AES-ТГС (нормално "корекция" BEAST от страна на сървъра за по-голям приоритет RC4).
Смята се, че недостатъците в RC4 далеч надхвърлят рисковете, свързани с BEAST. В действителност, с намаляване от страна на клиента (който предоставя както на Chrome и Firefox), BEAST не е проблем. Но рискът от RC4 набира скорост: подробно криптоанализ поплавък на повърхността в близко бъдеще.
Factoring RSA-износ ключове [Факторинг RSA-износ Keys (FREAK)]
FREAK уязвимост е човек-в-средата [човек-в-средата (MITM)], група откриване криптографите INRIA, Microsoft Research и IMDEA. FREAK означава "фактор RSA-експортирате ключа"
Оказва се, че някои съвременни клиенти TLS - включително тези от Apple и SecureTransport на OpenSSL - съдържат грешка. Тази грешка ги кара да приемат RSA ключове износ класа, дори и ако клиентът не е поискала износ клас RSA. Последиците от тази грешка може да бъде доста катастрофални: тя позволява на атаката ", човекът в средата", в резултат, на активен нападател може да принуди по-ниско е качеството на връзката, при условие че клиентът е уязвима, а сървърът поддържа RSA износ.
Има два вида атаки, в които сървърът трябва да приеме "износ RSA класа".
MITM атака работи по следния начин:
- Съобщението Здравейте на клиента, той пита за стандартния набор от шифри "RSA.
- MITM нападател променя съобщението да поиска "износ RSA.
- Сървърът отговаря с 512-битово RSA ключ износ подписа на дългогодишната си ключ.
- Клиентът получава слабото ключът за OpenSSL / SecureTransport грешки.
- RSA Модулът на нападателя фактор, възстановява съответния ключ RSA декриптиране.
- Когато клиентът криптира "предварително майстор тайна" сървър, атакуващият вече може да го разшифровате да възстанови TLS "майстор тайна".
- От тази гледна точка, нападателя вижда прав текст и да въведете каквото си поиска.
Набор от шифри, предложени на тази страница не позволява използването на износ шифри клас. Уверете се, че OpenSSL обновен до най-новата версия на разположение и насърчава своите клиенти да използват актуализирания софтуер.
Жълт (HH износ) [буксуване (DH износ)]
Изследователи от различни университети и институти провеждат проучване, което показа, че проблемът в протокола TLS. В доклада, учените посочват две метод за атака.
Разрешаването на обмен ключ Дифи-Хелман [Diffie-Hellman], TLS се използва, за да се договорят за общ ключ и съвпадение са сигурни връзки чрез нормален текст връзка.
Втората заплаха е, че много сървъри и използват едни и същи основни числа за обмен на ключове на Diffie-Hellman, вместо да създавате свои собствени уникални параметри DH.
Групата смята, че академичната отбор може да се счупят на 768-битови простите числа, и че правителствените служби могат да се счупят 1024-битов председател номер. Нарушаването на единния 1024-битов просто число, то е възможно да се подслушва 18 процента от един милион топ HTTPS домейни. Нарушаването отворен второто число от 66 на сто от виртуални частни мрежи, и 26 на сто от сървъра на SSH.
По-късно в този урок ще създадем нашите собствени уникални параметри на DH и ние използваме метод за криптиране, която да забранява износа клас криптиране. Уверете се, че OpenSSL обновен до най-новата версия на разположение и насърчава своите клиенти да използват най-новия софтуер. Актуализиране на вашия браузър да откаже да приеме настройките по-долу DH 768/1024 малко след тази корекция.
На Cloudflare има подробни указания относно вида на атаки жълт (HH ИЗНОС) [буксуване (DH ИЗНОС)].
Chastotootbor (Heartbleed)
Резултатите от влизането на проверка са верни (поради липсата на граници проверка) в изпълнението на разширение chastotootbora DTLS (RFC6520), така наречената "бъг" идва от "chastotootbor" ( "пулс"). Уязвимостта е класифицирано като буфера за четене, ситуацията е способността да се чете повече данни, отколкото би трябвало да бъде разрешено.
Кои версии на OpenSSL страдат от Chastotootbor (Heartbleed)?
Статутът на различни версии:
- OpenSSL 1.0.1 на 1.0.1f (включително) уязвима
- OpenSSL 1.0.1g не уязвими
- OpenSSL 1.0.0 клон не е уязвима
- OpenSSL 0.9.8 клон не е уязвима
Когато получите ъпгрейд OpenSSL не са уязвими по отношение на тази грешка.
SSL компресия (ПРЕСТЪПНОСТ атака)
ПРЕСТЪПНОСТ атака използва SSL компресия да си вършат работата. SSL компресията по подразбиране е деактивирано в Nginx 1.1.6 + / 1.0.9 + (ако използвате OpenSSL 1.0.0+) и Nginx 1.3.2 + / 1.2.2 + (ако използвате по-стари версии на OpenSSL).
Ако използвате друг по-ранна версия на Nginx или OpenSSL и вашата дистрибуция не се пренесли тази опция, ще трябва да компилирате OpenSSL без подкрепа ZLIB. Това ще попречи на използването на метод за компресиране изпуснете OpenSSL. Ако направите това, можете да използвате редовен метод за компресиране на HTML опровергавам.
SSLv2 и SSLv3
SSL v2 не е безопасно, така че ние трябва да го изключите. Също така деактивираме SSLv3, както и TLS 1.0, страда от атака понижаване, която позволява на атакуващия да принуди връзката да се използва SSLv3, и през него, за да деактивирате защитена връзка.
Отново, редактирате конфигурационния файл:
Фалшифициране и TLS-АВАРИЙНА-SCSV
SSLv3 позволява фалшифициране на работа грешка (пудел). Това е още една от основните причини да деактивирате тази функция.
Google предлага на SSL / TLS разширение наречено TLSFALLBACKSCSV, която се стреми да предотврати принудително изключване SSL.
Тя се включва автоматично, когато се актуализира, за да OpenSSL версии на следното:
- OpenSSL 1.0.1 има в TLSFALLBACKSCSV 1.0.1j горе
- OpenSSL 1.0.0 има в TLSFALLBACKSCSV 1.0.0o горе
- OpenSSL 0.9.8 има в TLSFALLBACKSCSV 0.9.8zc горе
За допълнителна информация относно документация Nginx.
криптиране Suite
Принуждават Secrecy дава ключова целостта на сесията, ако ключът за дългосрочно е нарушена. PFS решава този проблем с помощта на нов ключ деривация за всяка сесия.
Това означава, че, когато един частен ключ някой проникне тя не може да се използва за дешифриране на записания SSL трафик.
От шифри, които осигуряват идеална Задължава Secrecy тези, които използват ефимерна форма на обмен на ключове Diffie-Hellman. Недостатъкът е, техните режийни разходи, които могат да бъдат подобрени чрез използването на елиптични криви опции.
Той препоръча на два от следните шифри, а някои от фондацията Mozilla.
Препоръчителна метод за криптиране:
Препоръчителен метод за криптиране обратна съвместимост (IE6 / WinXP):
Ако вашата версия на OpenSSL е остаряла, недостъпни шифри ще бъдат отхвърлени автоматично. Винаги използвайте пълен набор от методи за кодиране по-горе, и нека OpenSSL ще избере тези, които го поддържа.
Организирайте методи за кодиране е много важно, защото тя решава кои алгоритми ще бъде избран на базата на приоритет. Препоръчителна горе алгоритми са означени с приоритет осигурява добра степен на сигурност.
По-старите версии на OpenSSL не могат да се върнат пълен списък на алгоритми. AES-GCM и някои ECDHE са сравнително отскоро, а не присъстват в повечето версии на OpenSSL, доставена с Ubuntu или RHEL.
Логиката на приоритизиране
ECDHE + AESGCM шифри са избрани първия. Това се TLS 1.2 шифър. Никой от познатите до момента атаките не са насочени към тези шифри.
PFS shifrometody се предпочитат, с ECDHE и след това DHE.
AES 128 за предпочитане AES 256. Това беше много дискусии за това дали режийните на AES256 допълнителна сигурност на разходите не е очевиден резултат. В момента AES128 е за предпочитане, тъй като тя осигурява добра сигурност, много бързо, и изглежда да е по-устойчива на времето за атака.
За назад shifrometoda съвместимост, AES предпочитане 3DES. BEAST атака AES омекотена в TLS 1.1 и по-висока, което прави трудно да се постигне в TLS 1.0. На обратната страна е несъвместима shifrometode, не 3DES.
RC4 е напълно премахната. 3DES се използва за да се осигури съвместимост. Вижте дискусията в # RC4_weaknesses.
задължително освобождаване от отговорност
- aNULL не съдържа заверено обмен на ключове Diffie-Hellman удостоверяване, които са обект на атаки човек-в-средата [Man-In-средата (MITM)]
- eNULL съдържа шифри криптиране нула (отворената форма)
- ИЗНОС наследил слаби шифри, които са били маркирани като бъде изнесен, законите на САЩ
- RC4 съдържа шифри, които използват остаряла алгоритъм ARCFOUR
- Тя се състои от DES шифри, които използват остарял стандарт за шифроване на данни
- SSLv2 съдържа всички кодове, които са били идентифицирани в версия на стандарта SSL стария вече не се препоръчва
- MD5 съдържа всички кодове, които използват остаряла съобщение смилат 5 като хеш алгоритъм
допълнителни настройки
Уверете се, че вие също сте добавили тези редове:
Когато изберете шифър по време на ръкостискане SSLv3 или TLSv1, като правило, се използва предпочитания на клиентите. Ако тази директива е активирана, приоритет ще бъде използвана предпочитания сървър.
Принудително Поверителност и ефимерни Diffie Hellman параметри
тайна концепция принуда е проста: на клиента и сървъра се споразумеят за ключ, който никога не се включи на скорост и унищожават в края на сесията. Лично RSA от сървъра се използва за подписване на ключ Дифи-Хелман между клиента и сървъра. Предварителен мастър ключ, получен от ръкостискане (ръкостискане) Diffie-Hellman, а след това се използва за криптиране. От предварителния мастър ключ е специфичен за връзката между клиента и сървъра, и се използва само за ограничен период от време, се казва ефимерно.
С принудителна тайна, ако нападателят влезе във владение на частен ключ на сървъра, той не може да декриптира последните връзки. Частен (затворен) ключ се използва за подписване на DH ръкостискане, която не се разкриват пред-мастър ключ. Diffie-Hellman гарантира, че предварително майсторски клавишите никога не напускат клиента и сървъра, а не могат да бъдат засечени MITM.
Всички версии на Nginx след 1.4.4 OpenSSL въз основа на входните параметри за Diffie-Hellman (DH) [Diffie-Hellman (DH)]. За съжаление, това означава, че ефимерна Diffie-Hellman (DHE) ще използва OpenSSL подразбиране, които включват ключ за 1024-битов ключ за обмен. И така, как да използваме сертификат 2048-битов, клиентите DHE ™ ще използват по-слаба обмен на ключове, отколкото не ефимерни клиенти DH.
Трябва да се създаде по-стабилна DHE параметър:
И след това да го използвате, за Nginx DHE обмен на ключове:
Свързваща OCSP [OCSP телбод]
Когато се свържете към сървър, клиентите трябва да се проверява достоверността на сертификата на сървъра, използвайки или списък с анулирани сертификати (CRL) [списъка с анулирани сертификати (CRL)], или статус сертификат подкрепа протокол (ГРАО) [Online Certificate Status Protocol (OCSP)] рекорд. Проблемът е, че списъците на CRL са се увеличили до огромни размери, и не винаги са достъпни за изтегляне.
ГРАО е много по-лек, тъй като само един запис е отстранена в същото време. Но страничен ефект е, че исканията за OCSP следва да бъдат направени в третата част на отговор при OCSP при свързване към сървъра, към който се добавят към закъснения и евентуални повреди. В действителност, отговорили на OCSP използвани ТЗ (Калифорния), често толкова ненадеждни, че браузърът ще се провали с течение на времето, ако отговорът не е получил своевременно. Това намалява сигурността, което позволява на атакуващия да използват DoS на отговор при OCSP да забраните сканирането.
Решението е да се позволи на сървъра, за да изпратите кеширана рекорд OCSP по време на ръкостискане TLS, заобикаляйки по този начин OCSP отговор при. Този механизъм позволява да запишете на искания назад и напред между клиента и отговор при ГРАО, и призова Бонд OCSP [OCSP телбод].
Сървърът изпраща кеширана OCSP отговор, само ако по искане на клиента, като декларират подкрепа status_request TLS разширение в клиента по заявка HELLO.
Повечето сървъри ще кешират OCSP отговор до 48 часа. На редовни интервали от време, сървърът ще се свърже с ГРАО отговор СО (Сертифициращ орган) (Калифорния), за да получите нова рекордно ГРАО. Местоположение OCSP отговор е взета от областта на информационните разрешения за достъп [Достъп до информация] подписан сертификат.
HTTP Строга сигурност на транспорта
Когато е възможно, трябва да се даде възможност на HTTP Строга сигурност на транспорта (HSTS), който казва на браузъра, за да общуват с вашия сайт само през HTTPS.
HTTP Public Key Фиксирането Extension
Можете също така трябва да включва HTTP Public Key Фиксирането разширение.
Public Key Фиксирането означава, че веригата на сертификат трябва да включва публичен ключ от белия списък. Това гарантира, че само в белия списък на сертифициращите органи (CAS) [в списъка на разрешените сертифициращи органи (CA)] могат да се регистрират сертификати за * .example.com, а не някоя от ТЗ съхранява от него.
Ако сте приложили по-горе конфигуриране линия, трябва да рестартирате Nginx:
# Първо, проверете конфигурацията:
# След това рестартирайте:
Сега използвам тест SSL Labs, за да видите как можете да получите висок клас. И, разбира се, сигурност, увереност, постоянство и доказателство за SSL професионална конфигурация!
Свързани статии