Ну, что же; нам с вами ничего не остается, кроме как озаботиться приобретением сертификатов и включением HTTPS на своем сайте.
Но приобрести/купить/получить_на_халяву цифровые сертификаты (ах, чертовы китайцы! не хватило им чувства меры, а ведь так удобны были бесплатные SSL-серты от WoSign сроком на три года!) - это только полдела, необходимо ведь еще и грамотно настроить SSL/TLS на вашем веб-сервере. Вы, небось, думали, что достаточно прописать пути к трем или четырем файлам в конфиге, и это все? - ан нет, разочарую, это только начало... идем на ssllabs, запускаем тесты и воочию видим зияющие прорехи безопасности, которые необходимо как можно быстрее исправлять: правда, Google пока что обещает не обращать внимания на неправильно сконфигурированный HTTPS, но ведь не всегда так будет. Итак:
Вероятнее всего, в первую очередь вам придется исправить именно эти проблемы безопасности: отказаться от использования слабозащищенного потокового шифра RC4 (Rivest Cipher 4 или ARC4), и перекрыть уязвимость SSLv3 POODLE. Начнем с "пуделя": попросту отключите в ssl.conf третий (второй отключен уже по умолчанию) SSL:
SSLProtocol All -SSLv2 -SSLv3
И - двигаемся дальше.
В 2015 году специалист компании Imperva Ицхик Мантин (Itsik Mantin) опубликовал результаты исследования уязвимости, обнаруженной в протоколе шифрования данных SSL/TLS, позволяющей скомпрометировать конфиденциальную информацию. Решением для нас с вами здесь будет настройка Forward Secrecy, заключающаяся, по сути, в указании используемых шифров, из перечня которых исключены уязвимые: тот или иной шифронабор согласуется клиентом и сервером во время установки соединения, если согласование не удалось – TLS-соединение не установится:
Android 2.3.7 No SNI 2 Server sent fatal alert: handshake_failure
IE 6 / XP No FS 1 No SNI 2 Server closed connection
IE 6 / XP No FS 1 No SNI 2 Server closed connection
Java 6u45 No SNI 2 Server sent fatal alert: handshake_failure
Java 7u25 Server sent fatal alert: handshake_failure
Таким образом, директива SSLCipherSuite отсекает попытки коннекта, эксплуатирующие слабые (потенциально уязвимые) наборы шифров. For example, в контексте безопасного перечня криптографических наборов директивы SSLCipherSuite можно рекомендовать следующее (указываем эту строчку именно в vhosts.conf, а не в ssl.conf;):
SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
Вторая директива утверждает приоритет наборов шифров сервера перед клиентом:
SSLHonorCipherOrder On
, также не следует оставлять без внимания и
SSLCompression off
Следующая директива не является строго необходимой, но - весьма и весьма желательной: добавленное в HTTP-ответ поле HSTS (HTTP Strict Transport Security – требование “принудительной безопасности” для HTTP) предопределяет для браузера, один-единственный раз сумевшего обратиться к сайту по HTTPS - дальнейшее использование именно HyperText Transfer Protocol Secure, даже при переходах по HTTP-ссылкам. Strict-Transport-Secutiry — весьма полезный заголовок, указывающий браузеру на то, что сайт доступен только по https. Это предотвращает потенциальную возможность случайного перехода обратно на HTTP-версию для последующей атаки через незашифрованное соединение (includeSubDomains - опять-таки optional, необязательно):
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
Также нелишними будут и эти две директивы, подразумевающие защиту от атак типа Clickjacking и DDOS посредством iframe и security-баги IE, связанные с автоматическим определением типа содержимого:
Header always set X-Frame-Options DENY
Header always set X-Content-Type-Options nosniff
К слову сказать, похожего (но не 100% аналогичного) результата мы с вами могли бы добиться и без включения для апача ( /etc/httpd/conf/httpd.conf ) соответствующего модуля (без него не заработает):
LoadModule headers_module modules/mod_headers.so
, а попросту добавив несколько строчек в .htaccess. Повторяю, результаты похожи, но не аналогичны; тщательно тестируйте ваш сайт:
<IfModule mod_headers.c>
# Using DENY will block all iFrames including iFrames on your own website
# Header set X-Frame-Options DENY
# Recommended: SAMEORIGIN - iFrames from the same site are allowed - other sites are blocked
# Block other sites from displaying your website in iFrames
# Protects against Clickjacking
Header always append X-Frame-Options SAMEORIGIN
# Protects against Drive-by Download attacks
# Protects against MIME/Content/Data sniffing
Header set X-Content-Type-Options nosniff
</IfModule>
ну и так далее, в том же ключе:
Крайне не рекомендуется бездумное использование, если не понимаете, зачем, а погуглить лениво, следующие три строчки лучше пока пропустить. Заинтересовавшимся позволю себе порекомендовать для начала материал Iframe и clickjacking. Вариации на тему .
add_header X-XSS-Protection "1; mode=block;";
add_header X-Content-Security-Policy "allow 'self';";
add_header X-WebKit-CSP "allow 'self';";
Ну и напоследок не забываем включить OCSP Stapling (OCSP — протокол проверки статуса SSL сертификата):
Red Hat Enterprise Linux 7, CentOS 7, and Fedora 20
The global mod_ssl configuration is in the file /etc/httpd/conf.d/ssl.conf. The platform configurations use the directory /run/httpd for the location of cache and other run-time files, so the two minimal lines required to enable OCSP Stapling for this platform are
SSLUseStapling On
SSLStaplingCache shmcb:/run/httpd/ssl_stapling(32768)
These directives should be placed just before the following text:##
## SSL Virtual Host Context
##
<VirtualHost _default_:443>
Any other OCSP Stapling directives required globally would be placed here as well.In the event that the OCSP Stapling configuration should differ for some virtual hosts, the file to edit will likely differ based on site policy. The platform .conf file referred to above also defines a default SSL-enabled virtual host for port 443, so changes to that virtual host would be made there. Any other SSL-enabled virtual hosts would likely be defined in site-specific files within the /etc/httpd/conf.d directory.
Таким образом, навскидку у нас с вами получился примерно вот такой набор правил; open_bacedir показан в контексте Joomla (only!) и должен быть, очевидно, изменен для иных CMS; disable_functions и allow_url_fopen - также optional. Обратите внимание, директивы SSLUseStapling и SSLStaplingCache прописаны, как и было сказано выше, обязательно за пределами VirtualHost:
SSLUseStapling On
SSLStaplingCache shmcb:/run/httpd/ssl_stapling(32768)
<VirtualHost *:443>
ServerName vash_site.com
ServerAlias www.vash_site.com
DocumentRoot /var/www/vash_site.com
ErrorLog /var/www/logs/vash_site.com_ssl.error.log
CustomLog /var/www/logs/vash_site.com_ssl.access.log common
SSLEngine on
SSLCertificateFile /etc/pki/tls/certs/ca.crt
SSLCertificateKeyFile /etc/pki/tls/private/ca.key
SSLCertificateChainFile /etc/pki/tls/certs/1_root_bundle.crt
SSLCACertificateFile /etc/pki/tls/ca-certs.pem
SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
SSLHonorCipherOrder on
SSLCompression off
Header always set Strict-Transport-Security "max-age=31536000; preload"
<Directory /var/www/vash_site.com>
php_admin_value open_basedir '/var/www/vash_site.com:/tmp:/var/lib/php/session:/var/www/vash_site.com/tmp:/var/www/vash_site.com/log'
php_admin_value disable_functions 'show_source, system, shell_exec, passthru, exec, phpinfo, popen, proc_open'
php_admin_value allow_url_fopen off
Options FollowSymlinks
AllowOverride All
Require all granted
</Directory>
</VirtualHost>
Проверяем:
$ openssl s_client -connect vash_site.com:443 -status
и убеждаемся, что
OCSP Response Data:
OCSP Response Status: successful (0x0)
-----
P.S. Кстати, о WoSign; проблемы с включением OCSP легко решаются получением промежуточных сертификатов, как уже и было описано (далее цитата) на хабре; в приведенном выше примере путь SSLCACertificateFile уже прописан:
cd /path/to/your/ssl/
wget -O - https://www.startssl.com/certs/ca.pem | tee -a ca-certs.pem > /dev/null
wget -O - https://www.startssl.com/certs/sub.class1.server.ca.pem | tee -a ca-certs.pem > /dev/null
wget -O - http://aia.startssl.com/certs/ca.crt | openssl x509 -inform DER -outform PEM | tee -a ca-certs.pem > /dev/null
wget -O - http://aia1.wosign.com/ca1g2-server1-free.cer | openssl x509 -inform DER -outform PEM | tee -a ca-certs.pem > /dev/null
wget -O - http://aia6.wosign.com/ca6.server1.free.cer | openssl x509 -inform DER -outform PEM | tee -a ca-certs.pem > /dev/null
Комментарии в блоге