Комментарии 12
Разработчики веб-браузера Safari молниеносно отреагировали на эту проблему и выпустили обновление безопасности.
Yosemite, однако, уязвим.
В обновлении от 16 октября 2014 года для Yosemite есть исправление этой уязвимости http://support.apple.com/kb/HT6536
На практике, к сожалению, подтвердить не могу. На форуме Apple.com об этом так же есть обсуждение, на сколько мне стало понятно, все в порядке и с Yosemite https://discussions.apple.com/message/26835447#26835447
На практике, к сожалению, подтвердить не могу. На форуме Apple.com об этом так же есть обсуждение, на сколько мне стало понятно, все в порядке и с Yosemite https://discussions.apple.com/message/26835447#26835447
Ну, вот я тоже и удивился…
habrastorage.org/files/00f/1bf/da5/00f1bfda53774ec38a015ab58c364d9f.png
habrastorage.org/files/00f/1bf/da5/00f1bfda53774ec38a015ab58c364d9f.png
Спасибо за статью.
Я тут вспомнил, что в свое время для openfire покупал ssl сертификат.
Оказалось:
Порт 5222 текстовый / TLS.
Порт 5223 хоть и SSL, но при этом сам пакет OpenSSL не используется.
Вместо OpenSSL там используется bouncycastle.
Вот чего только не узнаешь.
Я тут вспомнил, что в свое время для openfire покупал ssl сертификат.
Оказалось:
Порт 5222 текстовый / TLS.
Порт 5223 хоть и SSL, но при этом сам пакет OpenSSL не используется.
Вместо OpenSSL там используется bouncycastle.
Вот чего только не узнаешь.
# service nginx restart
В большинстве случаев стоит делать service xxx reload, где это только возможно, чтобы не портить клиентам жизнь, а также не останавливать и не запускать всего демона целиком. По крайней мере, хотя бы если изменяется только конфигурация.
Команда service является, грубо говоря, оберткой для скриптов из /etc/init.d, где опция restart обычно отправляет демону SIGTERM, после чего заново стартует процесс. Это верно по крайней мере для Debian, где в init-скрипте nginx используется дефолтный сигнал для остановки, и Ubuntu, где сигнал явно указан. У nginx SIGTERM повлечет за собой quick shutdown, при котором все соединения будут разорваны, и демон будет всеми силами пытаться умереть как можно быстрее. Плюс, ничего особо не изменилось, кроме одной строчки в конфиге, так что это тот самый случай, когда лучше сделать reload, ибо старые воркеры будут потихоньку умирать по мере завершения обработки запросов, а новые начнут запускаться уже с новой конфигурацией.
Рецепт для dovecot работает только с версии 2.1 и выше, для версий ниже 2.1 придется лезть в исходники.
Для Courier IMAP/POP3 (ну, мало ли, есть любители вроде меня):
файлы /etc/courier/imapd-ssl и /etc/courier/pop3d-ssl:
файлы /etc/courier/imapd-ssl и /etc/courier/pop3d-ssl:
TLS_PROTOCOL="TLS1_1:TLS1:TLS1_2"
TLS_STARTTLS_PROTOCOL="TLS1_1:TLS1:TLS1_2"
TLS_CIPHER_LIST="!SSLv3:TLSv1:!SSLv2:HIGH:!LOW:!MEDIUM:!EXP:!NULL@STRENGTH"
Тут недавно открыл для себя рекомендации mozilla, для настройки SSL на серверах. В качестве сухой выдержки, максимальную защиту в ущерб некоторой совместимости дает следующий конфиг nginx:
Если им следовать для постфикса, то у меня получилось что-то типа:
server { listen 443; ssl on; # certs sent to the client in SERVER HELLO are concatenated in ssl_certificate ssl_certificate /path/to/signed_cert_plus_intermediates; ssl_certificate_key /path/to/private_key; ssl_session_timeout 5m; ssl_session_cache shared:SSL:50m; # Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits ssl_dhparam /path/to/dhparam.pem; # Intermediate configuration. tweak to your needs. ssl_protocols TLSv1 TLSv1.1 TLSv1.2; 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:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK'; ssl_prefer_server_ciphers on; ssl_ecdh_curve secp384r1; # Enable this if your want HSTS (recommended) # add_header Strict-Transport-Security max-age=15768000; # OCSP Stapling --- # fetch OCSP records from URL in ssl_certificate and cache them ssl_stapling on; ssl_stapling_verify on; ## verify chain of trust of OCSP response using Root CA and Intermediate certs ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates; resolver <IP DNS resolver>; .... }
Если им следовать для постфикса, то у меня получилось что-то типа:
smtpd_tls_security_level = may smtpd_tls_auth_only = yes smtpd_tls_mandatory_ciphers = high smtpd_tls_CApath = /etc/ssl/certs smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3 smtpd_tls_dh1024_param_file = /etc/postfix/dhparam.pem smtp_tls_security_level = may smtp_tls_note_starttls_offer = yes smtp_tls_loglevel = 1 smtp_tls_mandatory_ciphers = high smtp_tls_CApath = /etc/ssl/certs smtp_tls_mandatory_protocols=!SSLv2,!SSLv3 tls_high_cipherlist = ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-S HA256: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-SHA 384: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:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK
Еще бы кто-нибудь рассказал 1С-никам, как теперь дружить с нашим TLS-only веб-сервером
Могу порекомендовать сервис SSL Server Test от Qualys: www.ssllabs.com/ssltest. Возможно, узнаете много нового про хорошие практики в настройке SSL.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как защитить свой сервер от уязвимости POODLE SSLv3