-Поиск по дневнику

Поиск сообщений в rss_planet_mozilla

 -Подписка по e-mail

 

 -Постоянные читатели

 -Статистика

Статистика LiveInternet.ru: показано количество хитов и посетителей
Создан: 19.06.2007
Записей:
Комментариев:
Написано: 7


Soledad Penades: Securing your self-hosted website with Let’s Encrypt, part 4: hardening default setups and avoiding known vulnerabilities

Четверг, 07 Апреля 2016 г. 19:36 + в цитатник

In part 3, we looked at how to finally use Let’s Encrypt to issue and renew certificates for our domains. But I also finished with a terrifying cliffhanger: basic HTTPS setups can be vulnerable to attacks! Gasp…!

Let me start by clarifying that I am not a security expert and if someone breaks into your system I will take no responsibility whatsoever, lalalala…

What makes basic HTTPS setups vulnerable?

There are two main culprits:

  • using older protocols and ciphers
  • and using defaults at web app or browser level

Why is using older protocols a bad idea?

SSL, the initial protocol used for encryption, has been proved insecure (see: POODLE). It is recommended that people use the newer TLS protocol instead.

Servers such as nginx will offer SSL by default if the value is not explicitly set in the server configuration file. Also, many configuration samples you find around the internetssss will place the weaker versions of the protocol first!

Remember when we talked about negotiating the HTTPS connection and how browsers would try and choose the first protocol they supported from the list the server offered? If we put the weaker versions first in our offerings, then browsers will consider those first! Not the best idea…

So: use TLS, which is safer (and maybe faster), and also offer safer protocols first… or just don’t offer the insecure protocols at all.

For example, this would be a good change for your nginx configuration:

- ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2; # nginx default
+ ssl_protocols TLSv1.2 TLSv1.1 TLSv1;

See how we removed SSL, and then reversed the order of the TLS versions to offer the latest versions first.

There’s a caveat: older clients might not be able to access your site if they do not implement any of the protocols your server offers.

What about using older ciphers?

Likewise, the issue with offering older ciphers is that some of them have been broken, and if you offer encryption with those you might be making it easy for the communications to be deciphered. Not what you want!

But where there are just SSL and TLS and a few version numbers to choose from for protocols, there’s an incredibly LONG LIST of ciphers and combinations and sizes you can choose for your server. Should you use ECDHE-ECDSA-AES256-GCM-SHA384 or maybe ECDHE-RSA-AES256-GCM-SHA384? Or perhaps ECDHE-ECDSA-CHACHA20-POLY1305? (Chacha! Chachacha!

https://soledadpenades.com/2016/04/07/securing-your-self-hosted-website-with-lets-encrypt-part-4-hardening-default-setups-and-avoiding-known-vulnerabilities/


 

Добавить комментарий:
Текст комментария: смайлики

Проверка орфографии: (найти ошибки)

Прикрепить картинку:

 Переводить URL в ссылку
 Подписаться на комментарии
 Подписать картинку