Security basics, часть 3: HTTPS
Вернёмся к ситуации, которую затронули пару дней назад.
Пользователь открывает сайт и хочет ввести пароль, данные карты или другую важную информацию. Симметричное шифрование здесь не подходит — непонятно как безопасно доставить ключ пользователю.
Все механизмы безопасности складываются из простых кирпичиков, и HTTPS не исключение:
🔸 Браузер присылает свой публичный ключ
🔸 Сервер присылает свой публичный ключ
🔸 Сервер и браузер вычисляют Общий ключ (shared secret) на основе своих приватных ключей и полученных публичных
Так через ассиметричное шифрование легко переходим к симметричному. Последний пункт выглядит как магия, но это всё математика. Спасибо криптографии за чудесные алгоритмы ❤️
Процесс выше называется TLS Handshake.
Скорее всего вы часто видели аббревиатуру SSL. Этот протокол появился в 90е и давно устарел, а ему на смену пришёл TLS. Но многие по старинке говорят SSL, иногда ещё пишется SSL/TLS.
Давайте опишем тот же процесс, но чуть подробней:
1️⃣ Браузер шлёт:
▫️ Алгоритмы, которые знает браузер
▫️ Свои публичные ключи и соответствующие алгоритмы
▫️ Случайное число №1
2️⃣ Сервер
Выбирает из списка алгоритмов подходящий для дальнейшего общения и запоминает публичный ключ браузера для выбранного алгоритма. Обратно шлёт
▫️ Названия выбранных алгоритмов
▫️ Свой публичный ключ
▫️ Сертификат
▫️ Случайное число №2
3️⃣ Обе стороны вычисляют Общий ключ и продолжают общаться
Больше технических подробностей читайте в статье TLS (SSL) handshakes explained. Разберём несколько вопросов "Зачем":
❓ Зачем браузер и сервер переходят на симметричное шифрование? Почему бы не продолжить шифровать сообщения публичными ключами?
Общий ключ короче и вычисления гораздо проще. Поэтому симметричные алгоритмы выполняются в тысячи раз быстрее ассиметричных.
❓ Зачем в сообщениях случайные числа?
Чтобы избежать Replay attack. Злоумышленник может прослушать сообщение и отправить от своего имени. Или отправить сообщение несколько раз, чтобы запутать получателя. Получатель запоминает число и не принимает сообщения с тем же числом.
❓ Зачем нужен сертификат?
Доказать, что сайт не фишинговый. В сертификате прописан:
▫️ Домен
▫️ Публичный ключ
▫️ Срок действия сертификата
▫️ Цифровая подпись
Сертификат подписывает:
🔹 Сам сервер своим приватным ключом. Браузер распознаёт самоподписанные сертификаты и выдаёт предупреждение. Но для разработки и тестирования такой вариант подойдёт
🔹 Специальная организация — Certificate Authority. Список СА хранится в операционной системе и в некоторых браузерах
Следить за сертификатами — задача девопса. Если срок действия сертификата истёк, то пользователи увидят надпись на весь экран, что сайту нельзя доверять.
❓ Зачем мне эта информация?
Чем выше ваша позиция, тем шире круг задач и проблем, которые нужно решать. И здесь очень важен общий кругозор. Плюс, чем больше вы знаете, как устроен мир, тем больше фундамент для ваших собственных решений🙂
Вернёмся к ситуации, которую затронули пару дней назад.
Пользователь открывает сайт и хочет ввести пароль, данные карты или другую важную информацию. Симметричное шифрование здесь не подходит — непонятно как безопасно доставить ключ пользователю.
Все механизмы безопасности складываются из простых кирпичиков, и HTTPS не исключение:
🔸 Браузер присылает свой публичный ключ
🔸 Сервер присылает свой публичный ключ
🔸 Сервер и браузер вычисляют Общий ключ (shared secret) на основе своих приватных ключей и полученных публичных
Так через ассиметричное шифрование легко переходим к симметричному. Последний пункт выглядит как магия, но это всё математика. Спасибо криптографии за чудесные алгоритмы ❤️
Процесс выше называется TLS Handshake.
Скорее всего вы часто видели аббревиатуру SSL. Этот протокол появился в 90е и давно устарел, а ему на смену пришёл TLS. Но многие по старинке говорят SSL, иногда ещё пишется SSL/TLS.
Давайте опишем тот же процесс, но чуть подробней:
1️⃣ Браузер шлёт:
▫️ Алгоритмы, которые знает браузер
▫️ Свои публичные ключи и соответствующие алгоритмы
▫️ Случайное число №1
2️⃣ Сервер
Выбирает из списка алгоритмов подходящий для дальнейшего общения и запоминает публичный ключ браузера для выбранного алгоритма. Обратно шлёт
▫️ Названия выбранных алгоритмов
▫️ Свой публичный ключ
▫️ Сертификат
▫️ Случайное число №2
3️⃣ Обе стороны вычисляют Общий ключ и продолжают общаться
Больше технических подробностей читайте в статье TLS (SSL) handshakes explained. Разберём несколько вопросов "Зачем":
❓ Зачем браузер и сервер переходят на симметричное шифрование? Почему бы не продолжить шифровать сообщения публичными ключами?
Общий ключ короче и вычисления гораздо проще. Поэтому симметричные алгоритмы выполняются в тысячи раз быстрее ассиметричных.
❓ Зачем в сообщениях случайные числа?
Чтобы избежать Replay attack. Злоумышленник может прослушать сообщение и отправить от своего имени. Или отправить сообщение несколько раз, чтобы запутать получателя. Получатель запоминает число и не принимает сообщения с тем же числом.
❓ Зачем нужен сертификат?
Доказать, что сайт не фишинговый. В сертификате прописан:
▫️ Домен
▫️ Публичный ключ
▫️ Срок действия сертификата
▫️ Цифровая подпись
Сертификат подписывает:
🔹 Сам сервер своим приватным ключом. Браузер распознаёт самоподписанные сертификаты и выдаёт предупреждение. Но для разработки и тестирования такой вариант подойдёт
🔹 Специальная организация — Certificate Authority. Список СА хранится в операционной системе и в некоторых браузерах
Следить за сертификатами — задача девопса. Если срок действия сертификата истёк, то пользователи увидят надпись на весь экран, что сайту нельзя доверять.
❓ Зачем мне эта информация?
Чем выше ваша позиция, тем шире круг задач и проблем, которые нужно решать. И здесь очень важен общий кругозор. Плюс, чем больше вы знаете, как устроен мир, тем больше фундамент для ваших собственных решений🙂